Simple, Fast, Multi-writer, Convergent, Replicated SQLite with 800 LOC only
npm install replic-sqlite> β οΈ WIP Notice: This project is still under active development. Do NOT use in production yet.
replic-sqlite is a lightweight Node.js / Bun.js module that adds multi-writer, Conflict-Free replication to SQLite β without performance compromises.
- π§© Tiny & Transparent β ~800 LOC, no hidden magic.
- π Performance First β avoids expensive ops (like excessive JSON parsing).
- π True Multi-Writer β no master, no leader bottlenecks.
- π CRDT at the Core β each row is replicated conflict-free.
- π‘οΈ No Single Point of Failure β designed for resilience.
- π Eventual Consistency β replicas may diverge temporarily, but always converge.
- π€ Read-Your-Own-Writes (optional) β via session token or reverse proxy.
- π Protocol Agnostic β WebSocket, TCP, HTTP, UDP, Pub/Sub β your choice.
- πΈοΈ Flexible Topologies β hub-and-spoke, mesh, hybrid.
- π¦ Dependency-Light β only depends on SQLite itself.
- π§ Rolling Upgrades β live DB migration system for upgrades/downgrades.
- πΈ Alien-Compatible β handles heterogeneous DB schemas across the cluster, making rolling upgrades transparent
- π€ Crash-Safe β survives stop/restart with automatic recovery.
- πͺ Self-Healing β handles packet loss, reordering, clock drift.
- βοΈ Embedded-Friendly β drop it directly into your app.
- π Open Metrics β built-in observability.
- π― Selective Replication β only tables with _patches tables are synced.
- π©οΈ Serverless-Friendly β automatic snapshot/backup/recovery to external object storage.
A better alternative to libSQL, Turso, Bedrockdb, cr-sqlite, dqlite, rqlite, and litestream if you use embedded SQLite with Node.js or Bun.sh.
More information coming soon.
- Tables are patched independently, so constraints between tables cannot be used.
This issue can be addressed later using a "group patch" feature.
- Direct Insert/Delete/Update request are forbidden in synchronized tables, unless you know what you do
1) Every table in your database must have:
- A primary key
- A separate table to store temporary patches, with three reserved and mandatory columns:
- _patchedAt : 53bits number (Unix timestamp in millisecond)
- _sequenceId : 64bits Consecutive sequence number of change per peer
- _peerId : 32bits globally unique, Source of change
``sql
/ Your table /
CREATE TABLE myTable (
id INTEGER NOT NULL,
tenantId INTEGER NOT NULL,
name TEXT,
deletedAt INTEGER,
PRIMARY KEY (id, tenantId)
) STRICT;
/ YOU MUST CREATE THE CORRESPONDING TABLE IN YOUR MIGRATIONS /
CREATE TABLE myTable_patches (
_patchedAt INTEGER NOT NULL,
_sequenceId INTEGER NOT NULL,
_peerId INTEGER NOT NULL,
id INTEGER NOT NULL,
tenantId INTEGER NOT NULL,
name TEXT,
deletedAt INTEGER
) STRICT;
`
2) Direct DELETE is forbidden. The nature of CRDTs requires that a deletion must be a patch with deletedAt`.
Additional documentation, examples, and usage guides are on the way. Stay tuned!
This is an early-stage project β feedback, ideas, and contributions are very welcome!
Apache-2.0