Skip to content

carboneio/replic-sqlite

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

33 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

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.

✨ Philosophy & Core Features

  • 🧩 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.

πŸš€ Why Replic-sqlite?

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.

Known Limits

  • 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

Prerequisites

  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
  /* 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;
  1. Direct DELETE is forbidden. The nature of CRDTs requires that a deletion must be a patch with deletedAt.

πŸ“… Roadmap

Additional documentation, examples, and usage guides are on the way. Stay tuned!

❀️ Contributing

This is an early-stage project β€” feedback, ideas, and contributions are very welcome!

πŸ“œ License

Apache-2.0

About

Fast Conflict-free Replication for SQLite

Resources

License

Stars

Watchers

Forks

Packages

No packages published