- Banyak developer menganggap bahwa menggunakan SQLite di server hanya cocok untuk aplikasi skala kecil
- Alasannya antara lain sebagai berikut:
- Biaya infrastruktur rendah: tidak memerlukan server database terpisah (berjalan sebagai satu file)
- Mudah untuk pengembangan dan pengujian: file DB yang sama bisa digunakan di client dan server
- Beban pengelolaan minimal: tidak perlu konfigurasi rumit atau mengelola daemon
- Keandalan tinggi: SQLite adalah DB yang paling banyak didistribusikan di dunia dan memiliki durabilitas yang kuat
- Alat seperti LiteFS, Litestream, rqlite, Dqlite, Bedrock menambahkan replikasi (replication) dan high availability (HA) ke SQLite sehingga cocok untuk deployment skala kecil
Namun, tulisan ini membahas potensi SQLite yang cocok bukan untuk skala kecil, melainkan untuk aplikasi hyper-scale
Masalah perluasan database besar yang ada saat ini
- Aplikasi besar biasanya sulit mempertahankan PostgreSQL atau MySQL sebagai satu DB tunggal, sehingga menggunakan database yang di-sharding
- Contoh: Cassandra, ScyllaDB, DynamoDB, Vitess (MySQL yang di-sharding), Citus (Postgres yang di-sharding)
- DB yang di-sharding memiliki keunggulan berikut:
- Optimasi batch read melalui partisi data
- Mendukung skalabilitas horizontal (scalability)
- Memberikan performa tulis yang tinggi
Namun, solusi partisi saat ini memiliki kelemahan berikut
- Skema kaku (rigid schemas): tidak mendukung query yang fleksibel seperti MySQL atau Postgres
- Sulit mengubah skema: menambah indeks atau mengubah relasi memberi beban operasional yang besar
- Operasi lintas partisi yang kompleks: sulit mempertahankan transaksi ACID, dan memerlukan teknik rumit seperti two-phase commit (2PC)
- Masalah inkonsistensi data: sulit menerapkan constraint data yang kuat antarpartisi, sehingga kemungkinan integritas data rusak lebih tinggi
Potensi database hyper-scale berbasis SQLite
- Cloudflare Durable Objects dan Turso menunjukkan cara merancang aplikasi hyper-scale berbasis SQLite
- Sistem-sistem ini menawarkan keunggulan berikut:
- Dynamic scaling: membuat database per entity untuk mengurangi kompleksitas infrastruktur
- Database murah tanpa batas: tidak memaksa partisi data seperti sharding tradisional, dan bisa membuat instance SQLite baru kapan pun dibutuhkan
- Distribusi global (global distribution): menempatkan database dekat dengan pengguna untuk meningkatkan performa
- Replikasi dan durabilitas bawaan (built-in replication & durability): tidak seperti SQLite tradisional, data direplikasi lintas banyak region untuk menjaga high availability
- Pendekatan pengganti sharding dengan SQLite (menggunakan Cloudflare Durable Objects & Turso)
- Pada pendekatan sharding tradisional, banyak log chat disimpan dalam satu partisi database
- Dengan SQLite, database SQLite terpisah dapat dibuat untuk setiap channel, sehingga penggunaan skema menjadi lebih fleksibel
- Struktur contoh
- Sharding tradisional: tabel log chat + partition key
- Berbasis SQLite: DB SQLite terpisah per channel (mencakup log chat, peserta, dan informasi reaksi)
- Keunggulan pendekatan ini dengan SQLite adalah sebagai berikut:
- Mempertahankan transaksi ACID lokal: transaksi dapat dijalankan di dalam masing-masing DB tanpa masalah lintas partisi
- I/O berperforma tinggi: karena SQLite adalah DB satu file, performa baca dan tulisnya sangat baik
- Dapat memanfaatkan fitur ekstensi SQL:
- FTS5 (Full-Text Search): meningkatkan performa pencarian
- JSON1: mendukung penyimpanan dan query data JSON
- R*Tree, SpatiaLite: dapat digunakan untuk data spasial
- Mendukung migrasi SQL: kompatibel dengan alat migrasi yang sudah ada seperti Prisma dan Drizzle
- Mendukung migrasi skema lambat (lazy):
- Migrasi tidak harus dijalankan segera, dan dimungkinkan memakai pendekatan migrasi ringan saat instance SQLite dibuka
Keterbatasan saat menggunakan SQLite di server
- Kurangnya solusi open source dan self-hosted
- Query lintas database tidak didukung → untuk analitik, diperlukan data lake terpisah
- Tooling database yang terbatas (SQL browser, pipeline ETL, monitoring, backup)
- StarbaseDB sedang menangani masalah ini berbasis Cloudflare Durable Objects + SQLite
- Kurangnya protokol standar yang terintegrasi
- PostgreSQL, MySQL, dan Cassandra menggunakan protokol standar, tetapi server SQLite masih kekurangan protokol jaringan standar
- Masih sedikit contoh kasus skala besar yang menggunakan SQLite di hyper-scale
- Studi kasus seperti Cassandra atau DynamoDB masih minim, tetapi hal ini bisa berubah seiring waktu
Kesimpulan: SQLite bukan sekadar DB lokal sederhana, tetapi juga opsi kuat untuk aplikasi hyper-scale
- SQLite bukan hanya DB untuk proyek kecil yang sederhana, tetapi alat yang kuat yang dapat menggantikan pendekatan sharding tradisional bahkan pada aplikasi hyper-scale
- Dengan Cloudflare Durable Objects & Turso, database dapat dipecah pada tingkat entity sambil tetap mempertahankan kemampuan kuat SQL dan transaksi ACID saat melakukan scale-out
- Kemungkinan besar ini akan menjadi alternatif yang lebih fleksibel dan lebih mudah dikelola dibanding database sharded tradisional
2 komentar
Adakah orang seberani itu yang rela memakai sqlite untuk skala hyper-scale yang harus menangani begitu banyak permintaan...
Opini Hacker News
Seorang pengguna sedang mempertimbangkan mengganti database kustom dengan SQL
Seorang pengguna sedang mengembangkan web app local-first dan merasa SQLite cocok
Membahas manfaat SQLite-Per-Partition
Dalam lingkungan multi-pengguna, SQLite mengalami kesulitan karena kurangnya MVCC
Dukungan SQLite diperluas dalam rilis 8.0 Ruby on Rails
Pengguna yang tidak familiar dengan Vitess atau Citus merasa sulit memahami isi artikel
Seorang pengguna tidak ingin memakai hosting VPS, sehingga membuat halaman web dengan SQLite
Pengguna yang kesulitan menyiapkan controller Ubiquiti menyarankan penggunaan SQLite
Apple pada 2022 mengoperasikan sekitar 300.000 instance Cassandra/ScyllaDB
TDLib (library database Telegram) menggunakan SQLite