Keep real SQLite as your app grows: replication, failover, offline device sync, and a database for every user and every AI agent. Sirannon embeds in Node.js, Bun, the browser, and React Native, or answers HTTP and WebSocket behind its own server, all from a single package.
Parameterised queries and typed results behave the same on an embedded file as on a replicated cluster, so the code that you start with can be the code that you deploy.
One driver API covers Node.js, Bun, the browser, and React Native, which is how the same database opens in all four. The bundled server answers your clients over HTTP and WebSocket, while the nodes of a cluster replicate to each other over gRPC.
Read the getting started guideimport { Sirannon } from '@delali/sirannon-db'
import { betterSqlite3 } from '@delali/sirannon-db/driver/better-sqlite3'
const driver = betterSqlite3()
const sirannon = new Sirannon({ driver })
const db = await sirannon.open('app', './data/app.db')
await db.execute(
'CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT, email TEXT)'
)
await db.execute('INSERT INTO users (name, email) VALUES (?, ?)', [
'Ada',
'ada@example.com',
])
const users = await db.query<{ id: number; name: string }>('SELECT * FROM users')Sirannon can open your database as a file on your laptop, serve that same file over HTTP and WebSocket from its own server, or replicate it across a cluster of nodes that fails over through a coordinator. The query code that you write on the first day can stay unchanged when you move to a cluster, because you change only the configuration as your product grows.
The line that opens a database is identical in every one of the three deployments.
Laptop
one file on disk
Server
HTTP and WebSocket
Cluster
three nodes with failover
Sirannon copies the whole database on the first backup, after which it sends only the write-ahead log frames that SQLite wrote since the previous backup. When you name the moment that you want back, Sirannon rebuilds the database from the full copy and every piece of change that it captured up to that moment. During a restore, Sirannon fetches one piece and applies it before it requests the next, so it holds only one piece in memory however large the database is.
A resolver maps any identifier to a file path, so Sirannon opens a database for a new customer or a new AI agent the first time that your code requests it, with no provisioning call. The lifecycle manager closes idle handles and evicts the least recently used one once the open count reaches your cap, which lets the number of files on disk grow while the number of open handles stays where you set it. Sirannon applies your migrations to each database as it opens the file, so the database of a tenant that you add long after the last schema change still opens on the current schema.
brightwood-legal
data/tenants/brightwood-legal.db
drafting-agent-04
data/ai-agents/drafting-agent-04.db
patel-associates
data/tenants/patel-associates.db
volta-tours
data/tenants/volta-tours.db
Over 10M rows, with both engines writing every commit to disk, Sirannon holds 32,000 operations a second on a read-heavy workload, against 1,000 for PostgreSQL. The benchmark harness drives each engine through its own client on one machine, with each engine on dedicated cores under the same memory limit. Each figure below is the median of five runs.
32×
PostgreSQL's rate
32,000operations a second
On a workload of 95 per cent reads and 5 per cent updates, Sirannon holds 32,000 operations a second.
Each rate is the fastest at which the engine completes 99 per cent of requests within 25 ms.
You install the drivers, migrations, backups, change capture, the network server, device sync, and replication together as one package.
Sirannon is free and open source under the Apache 2.0 licence.