SQLite di Production Itu Boleh, Tapi Jangan Polos

SQLite sering diremehkan karena kelihatan “database kecil”. Padahal yang bikin bahaya bukan SQLite-nya, tapi developer yang deploy tanpa mental model operasional.

Artikel ini membahas kapan SQLite masuk akal dipakai di production, apa saja jebakan yang sering muncul, dan checklist praktis sebelum lu taruh data user di sana. Jawaban singkatnya: SQLite bisa sangat cocok buat website kecil, tools internal, app lokal, prototype berbayar, sampai produk yang traffic-nya belum butuh database server terpisah. Tapi “simple” bukan berarti “tanpa operasi”. Lu tetap perlu paham query planner, WAL, backup, concurrency, deployment topology, dan observability.

Kenapa topik SQLite production ramai lagi?

Julia Evans baru menulis pengalaman belajar menjalankan SQLite untuk website Django. Ceritanya menarik karena bukan debat abstrak “SQLite vs Postgres”, tapi catatan real dari orang yang benar-benar menjalankan database itu untuk website beneran.

Salah satu bagian yang paling ngena: query full-text search di tabel sekitar 4.000 baris sempat makan waktu 5 detik. Untuk ukuran data sekecil itu, 5 detik terasa aneh. Setelah menjalankan ANALYZE, query yang sama langsung turun drastis. Pelajarannya sederhana: SQLite memang ringan, tapi dia tetap punya query planner yang butuh statistik agar bisa memilih rencana eksekusi yang benar.

Gua suka angle ini karena sering banget developer memperlakukan SQLite seperti file konfigurasi yang kebetulan bisa di-query. Padahal begitu file itu menyimpan data user, invoice, draft tulisan, session, atau event penting, dia sudah masuk wilayah operasional.

Definisi singkat: SQLite itu apa?

SQLite adalah database SQL embedded. Artinya, lu nggak menjalankan service database terpisah seperti Postgres atau MySQL. Aplikasi lu membaca dan menulis langsung ke file database SQLite lewat library. Tidak ada server database yang harus di-maintain, tidak ada koneksi TCP ke database, dan setup awalnya sangat cepat.

Itu kekuatan sekaligus batasnya. SQLite cocok saat lu butuh database yang portable, simpel, dan dekat dengan aplikasi. Tapi karena database-nya berupa file, deployment topology jadi penting. Single server? Biasanya lebih aman. Banyak instance app menulis ke file yang sama lewat network filesystem? Nah, itu mulai masuk area rawan.

SQLite boleh production, tapi jangan dipakai buat semua masalah

Menurut gua, pertanyaan yang lebih sehat bukan “SQLite production-ready nggak?”, tapi “production lu bentuknya kayak apa?”. Production untuk blog personal, dashboard internal, atau SaaS kecil beda jauh dengan marketplace besar, payment system, atau chat app yang write-heavy.

SQLite masuk akal kalau:

  • traffic masih kecil sampai menengah, terutama read-heavy;
  • aplikasi jalan di satu mesin utama;
  • data bisa dibackup sebagai file dengan prosedur yang jelas;
  • tim lu ingin mengurangi kompleksitas infra di fase awal;
  • lu paham batas concurrency dan siap pindah kalau workload berubah.

SQLite mulai kurang cocok kalau:

  • banyak worker atau instance app perlu menulis intensif bersamaan;
  • lu butuh replikasi built-in, role user kompleks, atau akses database lintas service;
  • database file ditaruh di network filesystem yang perilakunya belum lu pahami;
  • tim sudah butuh observability dan operasional database yang lebih matang;
  • domain bisnis punya kebutuhan audit, access control, dan migration workflow yang ketat.

Pelajaran #1: jalankan ANALYZE, jangan nebak-nebak performa

ANALYZE di SQLite dipakai untuk mengumpulkan statistik tentang tabel dan index. Statistik ini membantu query planner memilih strategi query yang lebih efisien. Tanpa statistik yang cukup, planner bisa memilih jalur yang secara teori valid, tapi secara praktik lambat.

Ini bukan detail akademis. Contoh Julia Evans menunjukkan query di tabel 4.000 baris bisa terasa lambat karena planner belum punya informasi yang cukup. Setelah ANALYZE, performa berubah besar.

Checklist praktisnya:

  • jalankan PRAGMA optimize; secara berkala sesuai rekomendasi SQLite modern;
  • pakai EXPLAIN QUERY PLAN untuk query yang mulai lambat;
  • jangan menambah index asal-asalan tanpa melihat query nyata;
  • ukur query dari data production-like, bukan cuma data dummy 20 baris.

Bagian ini penting buat developer yang sering merasa “datanya kecil, harusnya cepat”. Data kecil pun bisa lambat kalau aksesnya salah.

Pelajaran #2: WAL mode membantu, tapi bukan tombol ajaib

Write-Ahead Logging atau WAL adalah mode SQLite yang biasanya disarankan untuk aplikasi web karena bisa meningkatkan pola concurrency tertentu. Dalam mode WAL, perubahan ditulis ke file log terpisah sebelum masuk ke database utama. Ini membantu reader dan writer bekerja lebih nyaman dibanding mode rollback journal tradisional.

Tapi WAL bukan mantra yang menyelesaikan semua masalah. Lu tetap perlu paham checkpointing, ukuran file WAL, backup, dan bagaimana proses app lu membaca/menulis. Kalau aplikasi lu write-heavy dan banyak proses menulis bersamaan, WAL tetap punya batas.

Checklist cepat:

  • aktifkan WAL hanya setelah lu paham konsekuensinya;
  • monitor ukuran file -wal dan proses checkpoint;
  • jangan taruh database WAL di storage yang locking-nya meragukan;
  • test behavior saat app restart, deploy, dan crash.

Pelajaran #3: backup file database tetap butuh prosedur yang benar

Karena SQLite berbasis file, banyak orang tergoda backup dengan copy file biasa. Masalahnya, kalau file sedang ditulis, copy mentah bisa menghasilkan backup yang tidak konsisten. SQLite punya Online Backup API dan dokumentasi resmi untuk backup yang aman saat database sedang aktif.

Untuk project kecil, backup SQLite bisa sangat enak: satu file, gampang dipindah, gampang disimpan. Tapi enak bukan berarti boleh asal. Backup yang belum pernah lu restore itu belum tentu backup. Itu cuma ritual.

Minimal, lu perlu punya:

  • jadwal backup otomatis;
  • lokasi backup terpisah dari server utama;
  • prosedur restore yang pernah dites;
  • catatan versi schema/migration;
  • alert kalau backup gagal atau file backup ukurannya aneh.

Pelajaran #4: deployment topology lebih penting dari opini internet

SQLite bisa sangat stabil kalau aplikasi lu jalan di satu host dengan storage lokal yang jelas. Banyak masalah muncul saat orang memaksa SQLite masuk ke deployment yang sebenarnya didesain untuk database server: banyak instance stateless, autoscaling agresif, shared volume, dan worker paralel yang menulis terus-menerus.

Kalau lu deploy di satu VPS, SQLite bisa jadi pilihan yang waras untuk blog, internal tool, atau app kecil. Kalau lu deploy di platform yang menyalakan banyak instance otomatis, cek dulu apakah file database lu benar-benar punya satu sumber kebenaran yang aman. Jangan sampai scaling layer lu diam-diam bikin database file jadi bottleneck atau risiko korupsi.

Checklist sebelum pakai SQLite di production

Kalau lu mau pakai SQLite buat production kecil, gua bakal mulai dari checklist ini:

  1. Workload jelas: read-heavy atau write-heavy? Single user, small team, atau public app?
  2. Topology jelas: satu proses, banyak proses, satu host, atau banyak host?
  3. WAL dipahami: mode, checkpoint, file -wal, dan behavior saat restart.
  4. Query dicek: index, ANALYZE, PRAGMA optimize;, dan query plan.
  5. Backup dites: bukan cuma dibuat, tapi juga pernah direstore.
  6. Migration rapi: schema berubah lewat proses yang bisa diulang.
  7. Observability ada: log query lambat, ukuran database, error lock, durasi request.
  8. Exit plan ada: kapan pindah ke Postgres atau database server lain?

Takeaway buat developer

SQLite bukan mainan. SQLite juga bukan jawaban untuk semua workload. Dia alat yang sangat bagus kalau problem lu cocok dan lu operasikan dengan benar.

Gua lebih percaya developer yang bilang “gua pakai SQLite karena workload gua single-host, read-heavy, backup sudah dites, dan ada exit plan” daripada developer yang bilang “SQLite itu production-ready kok” tanpa konteks. Kalimat kedua terdengar percaya diri, tapi kurang operasional.

Pelajaran besarnya bukan cuma soal SQLite. Banyak tools yang terlihat simple tetap punya failure mode. AI coding tools, Ghost CMS, Cloudflare Tunnel, SQLite, semuanya sama: gampang dipakai bukan berarti bebas dipahami.

FAQ singkat

Apakah SQLite aman untuk production?

Aman untuk banyak production kecil dan menengah kalau workload, storage, backup, dan deployment topology-nya cocok. Jangan jadikan “production-ready” sebagai izin pakai tanpa checklist.

Kapan harus pilih Postgres daripada SQLite?

Pilih Postgres kalau lu butuh banyak koneksi writer, multi-service access, role dan permission kompleks, replikasi, extension tertentu, atau operasional database server yang lebih matang.

Apakah WAL wajib untuk SQLite di web app?

Tidak selalu wajib, tapi sering berguna. Yang penting, jangan cuma menyalakan WAL karena ikut blog post. Pahami checkpoint, concurrency, dan backup behavior-nya.

Apa langkah pertama kalau query SQLite lambat?

Cek query plan, index, statistik, dan jalankan optimasi yang direkomendasikan seperti PRAGMA optimize;. Jangan langsung pindah database sebelum tahu bottleneck-nya.

Referensi / Bacaan Lanjut

Tags:
#Software Development#Backend#Database#Developer Productivity