What Sirannon promises for the life of your product
You start with SQLite because it is the simplest option that works. Sirannon is what lets you keep it once the product outgrows simple.
You never have to migrate off it
Sirannon opens the same database as a file on your laptop, serves that file behind an HTTP and WebSocket server, and replicates it across a cluster of nodes that fails over through a coordinator. The query code you write on the first day is the code the cluster serves later. What changes as you grow is the configuration, never the application.
Read the getting started guideLaptop
one file on disk
Server
HTTP and WebSocket
Cluster
three nodes with failover
You can restore a terabyte to any moment you name
Sirannon copies the whole database once, then on every run after that it sends only the write-ahead log frames written since the previous one. Every backup after the first therefore moves only the writes since the last one, never the terabyte again. You name the moment you want back, and Sirannon rebuilds the database from the full copy plus every change piece captured up to it. The restore fetches one piece and applies it before it asks for the next, which keeps the memory it holds at one piece however large the database it rebuilds.
Read the restore guideEvery customer and every AI agent can have their own database
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 your code asks for 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. Migrations apply to each database as it opens, which means a tenant added long after the last schema change still opens on the current schema.
Read the lifecycle guidebrightwood-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
An AI agent or a browser reaches only the operations you registered
A Sirannon server refuses SQL from the network by default. A caller sends the name of a statement you registered along with its arguments, and it reaches only the tables and columns behind that name. The argument list is closed, which means a request carrying an argument you never declared fails with ARGUMENT_NOT_ALLOWED before it reaches SQLite. Every tenant identifier comes from the authenticated identity, and no caller can claim another tenant's rows by changing what it sends. Trusted service code on a private network can turn statements back on with acceptSql.
Read the registered operations guideYour application keeps working with no network
A device holds its own database file and writes to it whether or not it can reach the server. When the connection returns, the device pushes its own writes and pulls everyone else's over a WebSocket. Both sides apply the same conflict resolvers that replication uses between servers. That lets an application treat time offline as an ordinary state and keep one data store for online and offline alike.
Read the device sync guideYou see every change as it commits
Triggers record every insert, update, and delete as it commits, which is what clients subscribe to over a WebSocket. Activity feeds, live dashboards, and cache invalidation then come from the database itself. After a reconnect, the client SDK restores every subscription automatically.
Read the change data capture guideSirannon sustains four times PostgreSQL's read rate
A recorded run drove both engines through their own clients on one machine, at ten million rows, with every commit fsynced. Sirannon held 64.0K point-selects per second against PostgreSQL on 16.0K, and on the YCSB-A mix of half reads and half updates it held 16.0K against 1.0K. Every figure is the highest rate that engine sustained while holding p99 latency under 25 ms.
Read the full benchmark resultsTry Sirannon on your own data
The documentation covers everything above in depth, starting with the getting started guide.