What this is

You get a SQLite database with an HTTPS endpoint. You send SQL, you get rows back. There is no server to run, no connection to pool, no replica to fail over, and no volume to resize.

What makes it different from a SQLite file on a disk is where the durable copy lives: object storage is the only durability boundary. Nothing is acknowledged to you until the bytes covering it are in S3. The machine serving your queries holds a local copy for speed, and that copy is disposable — if the process dies uncleanly, the local file is thrown away and the database is rebuilt from object storage before it serves another request.

The four properties everything else follows from

P1	Object storage is the only durability boundary. A write is acknowledged only after the bytes covering it are in object storage.
P2	Every stored object is immutable, checksummed, and named by the transaction range it contains. Nothing is ever overwritten.
P3	Exactly one worker owns a database at a time, and ownership moves only by a compare-and-swap. Each ownership generation writes under its own epoch.
P4	Local state is disposable and is never reused after an unclean shutdown.

You do not have to remember these. They are here because every surprising thing in this API is a consequence of one of them, and it is faster to read four lines than to be surprised four times:

• P1 is why a write costs ~120 ms and a read costs ~0 ms.
• P2 is why storage grows and nothing is ever silently rewritten under you.
• P3 is why there is one writer, why X-Database-Epoch exists, and why a fenced error is a normal thing to retry rather than an incident.
• P4 is why an unclean restart takes ~40 s and loses nothing.

What a database is

A database is a db_-prefixed id, a name you chose, and an amount of SQL. It is created by an API call, lives until you delete it, and is billed by what it stores and how much it writes.

Databases are completely isolated from each other. A credential scoped to one database cannot see another, and a credential belonging to another organization gets a 404 for yours — not a 403, because a 403 would confirm the database exists. That distinction is deliberate and it is tested as a release gate.

What is not here yet

Stated plainly, because discovering a missing feature in production is worse than reading about it now:

Not available	What to do instead
Interactive transactions	Use a batch. One batch is one atomic transaction.
More than one writer	Not a roadmap item. One owner per database is the correctness core, not a scaling limitation.
Point-in-time restore	Every segment is immutable, so the history exists; the tooling to replay it to a timestamp does not.
Branching or forking	Copy the data out with SELECT and write it into a new database.
A web dashboard	Everything is the API. An operator provisions your organization and hands you a token.
Self-service signup	Ask us. Yes, really — see Authentication.
Metering and usage reporting	Not exposed yet. Nothing is metered against you that you cannot see, because nothing is metered.

Storage is also never reclaimed today: no compaction, no garbage collection. A database that has been written to a million times keeps every segment it ever produced. This is a deliberate trade — nothing deletes an object, so nothing can delete the wrong one — and it means storage cost grows with total writes rather than with current size.