Sirannon turns a local SQLite database into a distributed data layer: local ACID queries, trigger-based change data capture, real-time subscriptions, primary-replica replication, coordinator-backed failover, repair-time conflict resolution, and client access over HTTP or WebSocket. The documentation site walks through every feature, and the source lives on GitHub.
The production path is explicit. One authorised primary accepts writes, replicas serve reads and can forward writes, and coordinator mode uses primary terms, in-sync sets, and fail-closed promotion rules to keep write authority clear during failures.
What you get
- 1
Connection pooling and WAL mode
One write connection and N read connections (default 4) with WAL mode enabled for concurrent reads during writes.
- 2
Real-time change data capture
Tracks INSERT, UPDATE, and DELETE events through triggers and polling. Clients can subscribe to table changes over WebSocket.
- 3
Primary-replica replication
Replicates HLC-stamped change batches from one primary to read replicas over pluggable transports, including gRPC with TLS.
- 4
Coordinator-backed failover
Uses etcd authority, primary terms, in-sync sets, and majority write concern. Partitions fail closed for writes when Sirannon can't prove a safe primary.
- 5
Repair-time conflict resolution
Resolves divergent rows during explicit repair with LWW, PrimaryWins, or FieldMerge. Normal writes are serialised through the primary.
- 6
Migrations and scheduled backups
File-based and programmatic migrations with rollback support. Snapshot backups with scheduled rotation to prevent data loss.
- 7
Multi-tenant lifecycle management
Manage multiple database instances with idle timeouts and LRU eviction. Each tenant gets isolated resources with clean provisioning and teardown.
Runs across runtimes
Pluggable drivers cover better-sqlite3, Node.js 22+ built-in SQLite, wa-sqlite (browser via IndexedDB), Bun, and Expo. The server layer uses uWebSockets.js with authentication hooks for network access.
What this means
- Replication is HLC-stamped change-batch replication, not shared-file SQLite over a network file system.
- Conflict resolution is for explicit repair and disaster recovery. Normal writes go through one primary.
- Coordinator mode fails closed under unsafe partitions and promotes only a proven in-sync replica.
- Safe DDL replication uses an allowlist, and SQLite constraints still apply on every node.
Where this is going
SQLite is the most deployed database engine on the planet, but the ecosystem usually treats it as a local-only tool. Sirannon's current production shape is a distributed primary-replica database layer. Write to SQLite through the current primary, replicate to read replicas, route clients through topology-aware HTTP/WebSocket paths, and fail closed when the cluster can't prove write authority.
The longer-term direction is broader offline reconciliation: local-first applications that sync when connectivity returns, edge nodes that serve reads close to users, and mobile apps that keep working offline. The conflict-resolution layer already has explicit repair semantics. Extending that into offline writes requires clear guarantees about causality, constraints, and operator control.
