Turso dan libSQL: SQLite Edge dengan Embedded Replica

SQLite adalah database yang paling saya percaya namun paling jarang saya pakai di produksi, dan alasannya selalu sama: ia hidup di satu proses, di satu disk. Ia luar biasa cepat untuk baca lokal, tetapi begitu Anda butuh dua server berbagi data yang sama, atau sebuah fungsi serverless yang menyala tanpa file lokal, SQLite biasa kehabisan ruang. Bertahun-tahun jawabannya adalah beralih ke Postgres dan menerima biaya round trip jaringan di setiap query.

Turso dan libSQL adalah upaya mempertahankan kecepatan local-first SQLite sekaligus menghilangkan batas itu. Di tulisan ini saya membahas apa itu libSQL sebenarnya, bagaimana embedded replica memberi Anda baca lokal dengan primary remote yang tersinkron, mengapa protokol remote penting untuk serverless dan edge, dan bagaimana penulisan ulang Turso Database yang lebih baru mengubah gambarannya. Setiap klaim di sini diperiksa terhadap dokumentasi dan repositori resmi, ditautkan di akhir.

Apa itu libSQL sebenarnya

libSQL adalah fork SQLite yang open source dan terbuka untuk kontribusi, dibuat dan dikelola oleh Turso. Ia ada untuk alasan yang spesifik: SQLite bersifat open source tetapi terkenal tidak menerima kontributor eksternal. libSQL di-fork agar komunitas dapat menambahkan fitur di atas mesin yang sudah teruji itu. Ia menjaga kompatibilitas mundur penuh — dokumentasinya berkomitmen membaca dan menulis format file SQLite yang sama serta kompatibilitas 100 persen dengan API SQLite, sambil membolehkan API tambahan di atasnya.

Di atas fondasi itu libSQL menambahkan dua hal yang tidak dimiliki SQLite biasa. Pertama, akses remote: sebuah server libSQL mengekspos database lewat jaringan, sehingga klien dapat berbicara dengannya seperti ke Postgres atau MySQL, bukan hanya membuka file di mesin yang sama. Kedua, embedded replica, fitur yang membuat seluruh desainnya menarik. libSQL juga mewarisi batasan inti SQLite, termasuk model single-writer — hanya satu transaksi tulis berjalan pada satu waktu.

Embedded replica: baca lokal, tulis remote

Sebuah embedded replica adalah salinan lokal penuh dari database remote, hidup sebagai file SQLite nyata di dalam aplikasi Anda. Baca selalu dilayani dari file lokal itu, jadi berjalan dalam mikrodetik tanpa hop jaringan. Tulis mengambil jalur berbeda: secara default ia dikirim ke primary remote, bukan ditulis ke file lokal lebih dulu, dan setelah primary menerimanya salinan lokal diperbarui otomatis. Anda mendapat latensi baca lokal tanpa mengorbankan satu sumber kebenaran.

import { createClient } from "@libsql/client";

// Embedded replica: a local SQLite file for reads,
// a Turso Cloud primary for writes.
const db = createClient({
  url: "file:local.db",               // reads served locally, in microseconds
  syncUrl: "libsql://my-db.turso.io", // writes forwarded to the cloud primary
  authToken: process.env.TURSO_AUTH_TOKEN,
  syncInterval: 60,                   // pull remote changes every 60 seconds
});

// Reads never leave the machine.
const users = await db.execute("SELECT * FROM users WHERE active = 1");

// Writes go to the primary; the local file is then updated automatically.
await db.execute({
  sql: "INSERT INTO users (email, active) VALUES (?, ?)",
  args: ["[email protected]", 1],
});

// Pull the latest remote state on demand.
await db.sync();

Konfigurasi klien adalah tempat ini menjadi nyata. Anda mengarahkan url ke file lokal untuk baca dan syncUrl ke primary di cloud untuk tulis, lalu mengatur syncInterval agar replica menarik perubahan remote secara terjadwal. Jaminan read-your-writes penting di sini: setelah sebuah tulis berhasil, replica yang mengeluarkannya selalu langsung melihat data baru itu, bahkan sebelum sinkron berikutnya. Replica lain baru melihatnya setelah memanggil sync atau mencapai intervalnya.

Protokol remote untuk serverless dan edge

Embedded replica mengasumsikan disk lokal yang durable, yang sering tidak dimiliki runtime serverless dan edge — sebuah fungsi bisa menyala dingin tanpa filesystem untuk menampung replica. Untuk kasus itu libSQL berbicara lewat protokol remote di atas HTTP dan WebSocket alih-alih mensyaratkan file lokal permanen. Klien menerima URL libsql, http, https, ws, dan wss, sehingga API yang sama yang membuka file lokal dapat langsung mengirim query ke database remote lewat koneksi stateless.

Inilah yang membuat SQLite layak dipakai di platform yang tidak memungkinkan file mentah sama sekali. Protokol berbasis HTTP jauh lebih cocok untuk pemanggilan singkat dan stateless dibanding koneksi database TCP tradisional yang mengharapkan sesi berumur panjang dan connection pooling. Anda mendapat semantik SQLite dari sebuah fungsi Vercel, edge worker ala Cloudflare, atau lingkungan apa pun yang bisa membuat permintaan HTTPS, tanpa mengirim dan memasang file database bersama kode Anda.

Database-per-tenant di skala besar

Karena sebuah database SQLite hanyalah file, membuat banyak file jadi murah — dan Turso benar-benar memanfaatkan ini. Alih-alih satu database bersama yang besar dengan kolom tenant_id di setiap tabel, Anda bisa memberi setiap pengguna, tenant, atau agen AI database tersendiri. Database yang menganggur hanya berbiaya penyimpanannya, karena tidak ada proses berjalan ketika tak ada yang query, sehingga Turso Cloud dirancang menampung jutaan bahkan miliaran database kecil. Isolasi, backup per-tenant, dan keamanan noisy-neighbor hampir didapat gratis.

libSQL versus Turso Database: gambaran 2025

Ada nuansa penamaan yang perlu diluruskan. libSQL dan Turso Database adalah dua proyek berbeda dari tim yang sama. libSQL adalah fork SQLite yang dijelaskan di atas — ditulis dalam C, siap produksi, dan fondasi Turso Cloud saat ini. Turso Database adalah penulisan ulang SQLite dari nol dalam Rust yang lebih baru, dimaksudkan sebagai pengganti drop-in, yang melampaui sekadar fork: ia menambahkan tulis konkuren via BEGIN CONCURRENT dengan multi-version concurrency control, model I/O async-first untuk serverless dan edge, serta dukungan native untuk model database-per-tenant.

Untuk proyek baru tim kini merekomendasikan Turso Database, sementara libSQL tetap pilihan tepat untuk beban kerja mission-critical yang butuh fondasi teruji hari ini. Aturan saya sendiri lebih sederhana: jika saya ingin kecepatan SQLite di satu mesin dengan backup tersinkron opsional, libSQL dan embedded replica sudah sangat baik. Jika saya merancang untuk edge, untuk banyak tenant terisolasi, atau untuk konkurensi tulis yang tak pernah dimiliki SQLite, penulisan ulang Rust adalah arah yang patut dipertaruhkan.