SQLite di Produksi dengan Litestream: Replikasi Otomatis untuk Docker dan Kubernetes

SQLite sering dianggap database yang hanya cocok untuk proyek kecil, aplikasi lokal, atau sekadar penyimpanan sementara. Anggapan itu tidak sepenuhnya salah, tetapi mulai bergeser. Dengan hadirnya Litestream, database file-backed ini bisa dipakai di produksi dengan tingkat ketahanan yang jauh lebih baik: setiap perubahan direplikasi secara kontinu ke object storage, dan kalau volume server hilang, data bisa dikembalikan secara otomatis.

Artikel ini membahas bagaimana SQLite dan Litestream bekerja bersama, apa yang terjadi di balik layar, dan bagaimana cara menggunakannya di environment Docker, Podman, maupun Kubernetes. Fokus utamanya adalah platform open-source bernama OpenRun yang mengintegrasikan Litestream langsung ke dalam workflow deploy, sehingga aplikasi tetap memakai SQLite secara normal tanpa perlu mengubah image container sama sekali.

Kenapa SQLite Menarik untuk Produksi

SQLite adalah database relasional yang berjalan sebagai file. Tidak ada server terpisah, tidak ada port yang harus dibuka, tidak ada user database yang harus dikelola. Bagi aplikasi internal, MVP, atau tool yang dipakai tim kecil, ini adalah keuntungan besar: developer cukup membaca dan menulis file, dan seluruh data tersimpan rapi di satu tempat.

Kelebihan utamanya:

• Tidak ada proses server terpisah, sehingga tidak ada satu titik kegagalan tambahan yang harus dioperasikan.
• Read performance sangat cepat karena data dibaca langsung dari file, tanpa melewati jaringan.
• Setup sangat sederhana, cocok untuk aplikasi yang ingin fokus ke fitur daripada urusan infrastruktur.
• Backup bisa dilakukan dengan menyalin file, meskipun cara ini tidak aman untuk data yang sedang ditulis.

Masalah utamanya selama ini satu: ketahanan data. Kalau file database hilang karena disk rusak, container terhapus, atau node mati, datanya ikut hilang. Menyalin file secara manual bukan solusi yang aman karena database bisa sedang dalam keadaan setengah menulis. Di sinilah Litestream masuk.

Apa Itu Litestream

Litestream adalah tool open-source yang terus-menerus mereplikasi perubahan database SQLite ke object storage seperti AWS S3, Cloudflare R2, MinIO, atau SeaweedFS. Konsepnya sederhana: alih-alih menyalin file utuh secara berkala, Litestream membaca write-ahead log (WAL) SQLite dan mengirimkan perubahannya ke penyimpanan jarak jauh secara kontinu.

Hasilnya adalah replika yang hampir selalu terbarui. Kalau database asli hilang, replika bisa dipakai untuk memulihkan data, bahkan bisa sampai ke titik waktu tertentu (point-in-time recovery). Ini mengubah posisi SQLite dari database yang rawan kehilangan data menjadi database yang bisa diandalkan untuk produksi, terutama untuk workload internal dan aplikasi berskala kecil hingga menengah.

Sayangnya, mengintegrasikan Litestream secara manual tidak gratis. Developer harus menyiapkan konfigurasi replika, memasang Litestream di samping aplikasi, dan menulis logika restore yang berjalan saat aplikasi mulai. Untuk satu aplikasi, ini masih masuk akal. Untuk banyak aplikasi, overhead-nya mulai terasa. Platform seperti OpenRun mencoba menghilangkan pekerjaan manual itu.

OpenRun: Replikasi sebagai Bagian dari Platform

OpenRun adalah platform open-source yang bisa di-self-host untuk men-deploy aplikasi web dan internal tools ke Docker, Podman, atau Kubernetes. Platform ini menyediakan autentikasi, otorisasi, auditing, dan RBAC tanpa memaksa aplikasi berubah. Mulai versi terbarunya, OpenRun memiliki dukungan bawaan untuk Litestream.

Yang membuat pendekatan ini menarik: pengaturan Litestream cukup didefinisikan sekali di konfigurasi server. Platform yang mengelola proses replikasi dan restore, bukan aplikasi. Image container aplikasi tetap seperti apa adanya, dan aplikasi SQLite baru bisa langsung menikmati replikasi tanpa setup tambahan.

Konfigurasinya terlihat seperti ini:

# openrun.toml
[litestream.mainbackup]
bucket = "openrun-backups"
region = "us-east-1"
access_key_id = "..."
secret_access_key = "..."

Dengan konfigurasi ini, setiap aplikasi SQLite yang di-deploy melalui OpenRun otomatis mendapatkan replikasi ke bucket yang ditentukan. Developer tidak perlu memasang Litestream di dalam image, tidak perlu menyentuh Dockerfile, dan tidak perlu menulis script restore sendiri.

Bagaimana Restore Otomatis Bekerja

Bagian paling penting dari replikasi adalah kemampuan untuk pulih. OpenRun mendeteksi kapan volume aplikasi kosong atau sedang dibuat ulang, lalu memulihkan database dari replika sebelum aplikasi dijalankan. Proses ini berjalan di luar container aplikasi, sehingga aplikasi tidak pernah sadar bahwa dirinya baru saja dipulihkan dari backup.

Alurnya kurang lebih seperti ini:

• Aplikasi pertama kali dijalankan, volume database kosong.
• OpenRun menemukan replika Litestream yang tersimpan di object storage.
• Database dipulihkan dari replika ke volume sebelum container aplikasi start.
• Aplikasi berjalan normal dengan data yang sudah lengkap.

Ini menyelesaikan masalah klasik container: container itu ephemeral, tetapi datanya tidak boleh ikut hilang. Dengan restore otomatis, pengalaman developer menjadi seperti memakai volume biasa, padahal di belakang layar data selalu punya cadangan jarak jauh.

Single Node dan Kubernetes

Salah satu kelebihan pendekatan ini adalah bekerja di dua skenario yang berbeda: single node dan cluster Kubernetes.

Di single node dengan Docker atau Podman, setup-nya cukup sederhana. Volume database didefinisikan sekali, konfigurasi Litestream diletakkan di server, dan setiap aplikasi SQLite otomatis terlindungi. Kalau node mati atau disk rusak, data bisa dipulihkan dari object storage ke node baru.

Di Kubernetes, ceritanya sedikit lebih kompleks tetapi tetap terkelola. Volume PersistentVolumeClaim (PVC) bisa terhapus saat node gagal, dan StatefulSet harus memastikan identitas pod tetap stabil. Dengan Litestream di level platform, restore otomatis menutup celah ini: begitu PVC baru dibuat, database langsung ditarik dari replika.

Yang perlu diingat: replikasi Litestream bukan pengganti database terdistribusi. Kalau aplikasi membutuhkan banyak writer yang menulis secara bersamaan dari banyak node, SQLite tetap bukan pilihan yang tepat. Tetapi untuk mayoritas aplikasi internal, satu writer saja sudah cukup, dan SQLite plus Litestream adalah kombinasi yang sangat masuk akal.

Keuntungan Praktis untuk Tim Kecil

Bagi tim kecil, keuntungan terbesar adalah pengurangan beban operasional. Tidak ada database server yang harus dipantau, tidak ada cluster database yang harus diskalakan, dan tidak ada tim DBA yang harus disewa. Semua data hidup di dalam file, dan file itu selalu punya cadangan di object storage.

Biaya juga lebih rendah. Object storage seperti R2 atau S3 murah, dan untuk aplikasi internal dengan volume data kecil, biaya replikasi bisa dibilang hampir tidak terlihat. Bandingkan dengan biaya menjalankan database server terpisah yang harus selalu hidup, baik dipakai maupun tidak.

Selain itu, developer bisa memakai SQLite dengan cara yang sudah mereka kenal. Tidak perlu belajar bahasa query baru, tidak perlu memahami konsep connection pool yang rumit, dan tidak perlu mengelola migrasi skema dengan tool tambahan. SQLite tetap SQLite, hanya saja sekarang datanya lebih aman.

Kapan Sebaiknya Tidak Memakai Pendekatan Ini

Tidak ada solusi yang cocok untuk semua kasus. Pendekatan SQLite plus Litestream kurang tepat ketika:

• Aplikasi membutuhkan banyak writer dari banyak node sekaligus.
• Volume data sangat besar dan query membutuhkan pemrosesan paralel yang agresif.
• Terdapat kebutuhan multi-tenant dengan isolasi yang ketat di level database server.
• Tim sudah memiliki infrastruktur database terdistribusi yang berjalan baik.

Untuk kasus-kasus tersebut, Postgres atau database terdistribusi lain tetap menjadi pilihan yang lebih baik. Keputusan yang tepat selalu bergantung pada kebutuhan nyata, bukan pada tren.

Replikasi di Level Platform vs di Level Aplikasi

Ada dua cara umum untuk memasang Litestream: di dalam image aplikasi atau di level platform. Cara pertama, memasang Litestream di dalam container aplikasi, berarti setiap image harus menyertakan binary Litestream, konfigurasi replika, dan logika restore. Kalau tim mengelola sepuluh aplikasi, artinya ada sepuluh tempat yang harus dijaga konsisten, dan setiap kali ada pembaruan konfigurasi, semuanya harus di-deploy ulang.

Cara kedua, yang dipakai OpenRun, memindahkan tanggung jawab itu ke platform. Konfigurasi Litestream didefinisikan sekali di server, dan platform yang menjalankan proses replikasi serta restore di luar container aplikasi. Image aplikasi tidak berubah, dan aplikasi tidak pernah sadar bahwa datanya sedang direplikasi ke object storage. Ini mengurangi duplikasi konfigurasi dan membuat perilaku replikasi seragam di semua aplikasi.

Pendekatan platform juga memudahkan rotasi kredensial. Kalau access key object storage harus diganti, cukup perbarui satu konfigurasi server, bukan membangun ulang semua image. Untuk tim yang menjalankan banyak aplikasi internal, penghematan operasional ini terasa nyata dalam beberapa minggu pertama.

Tentu saja, ada trade-off. Mengandalkan platform berarti menambah satu lapisan yang harus dipercaya, dan kalau platform bermasalah, semua aplikasi yang bergantung padanya ikut terpengaruh. Karena itu, memilih platform open-source yang bisa diaudit, seperti OpenRun, menjadi penting: tim bisa memeriksa sendiri bagaimana replikasi dan restore diimplementasikan, tanpa harus percaya buta pada kode tertutup.

Kapan Migrasi ke Pendekatan Ini Masuk Akal

Migrasi ke SQLite plus Litestream paling masuk akal untuk aplikasi yang selama ini memakai database server hanya karena kebiasaan, padahal workload-nya tidak membutuhkannya. Banyak aplikasi internal memiliki satu writer, volume data kecil hingga menengah, dan kebutuhan utama hanya data tidak hilang. Untuk kasus seperti ini, database server terpisah sering kali merupakan kompleksitas yang tidak perlu.

Beberapa tanda bahwa pendekatan ini cocok untuk aplikasi Anda:

• Aplikasi berjalan sebagai container dan volume database-nya sederhana.
• Traffic didominasi operasi baca, dengan satu titik tulis.
• Tim lebih memilih menyederhanakan infrastruktur daripada menambah komponen.
• Biaya object storage jauh lebih rendah daripada biaya menjalankan database server 24 jam.

Sebaliknya, kalau aplikasi sudah berjalan baik dengan Postgres dan tim sudah terbiasa dengan alurnya, migrasi hanya demi tren bukan keputusan yang bijak. Evaluasi berdasarkan data: ukur workload, hitung biaya, dan baru putuskan.

Kesimpulan

SQLite bukan lagi database yang harus dihindari untuk produksi. Dengan Litestream, data yang tersimpan di file bisa direplikasi secara kontinu ke object storage, dan dengan integrasi platform seperti OpenRun, seluruh kerumitan replikasi dan restore bisa disembunyikan dari aplikasi.

Hasilnya adalah pengalaman yang menyenangkan bagi developer: aplikasi tetap sederhana, data tetap aman, dan operasional tetap ringan. Untuk aplikasi internal, MVP, dan produk tim kecil, kombinasi SQLite, Litestream, dan platform deploy seperti OpenRun layak dipertimbangkan dengan serius.

Kalau selama ini menahan diri memakai SQLite karena takut kehilangan data, sekarang tidak ada alasan untuk tidak mencobanya di proyek berikutnya. Mulai dari proyek kecil, ukur alurnya, dan rasakan sendiri perbedaan antara mengelola database server dan mengelola file yang aman di cloud.