Turso

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the SQLite setup I actually need instead of paying for Turso: replicas near my readers, a local read path, and a way back from a bad afternoon.

Read this first: what the fee buys is real — replicas in many regions kept in sync, embedded replicas so a read never crosses the network, branching, and point-in-time restore. Before replacing it, be honest about whether you need any of it. A single SQLite file on one machine, with a replication stream to object storage, serves an enormous number of applications and is what most of this prompt is about. Global read replicas are a different problem and are worth paying for if you actually have readers on three continents.

STACK
- SQLite through better-sqlite3, WAL mode
- Litestream for continuous replication to object storage. Do not write a replicator
- libSQL if you want the embedded-replica behaviour, which is the part that is genuinely hard to reproduce
- Node 20+ with Fastify for the application
- Caddy in front

THE SINGLE-MACHINE SETUP, WHICH IS PROBABLY ENOUGH
- WAL mode, a busy timeout, synchronous set to normal, and foreign keys on. Those four settings are most of the performance conversation
- One writer. SQLite serialises writes, and a write queue in the application is simpler and faster than fighting for the lock
- Reads are a local file read: microseconds, no network, no connection pool. That is the property people pay a hosted service to get back
- Prepared statements cached, and indexes chosen deliberately rather than added after a slow afternoon
- A modern disk will handle thousands of writes a second. Measure yours before assuming you have outgrown it

CONTINUOUS REPLICATION, WHICH REPLACES POINT-IN-TIME RESTORE
- Litestream streams the WAL to an S3-compatible bucket continuously, so the recovery point is seconds rather than a night
- Restore to any moment within the retention window, which is the point-in-time restore feature, free
- Snapshots on a schedule, WAL segments between them, retention configured
- A restore rehearsed onto a clean machine, with the time it took written down. An untested restore is not a restore, and this is the entire disaster-recovery story
- Verify the restored file: run an integrity check and a query that exercises the newest data

READ REPLICAS, HONESTLY
- A read replica is another machine restoring the same stream and following it. Reads there are local; writes still go to the primary
- The lag is seconds. If your application reads its own writes, either route those reads to the primary or accept the staleness deliberately — this is the trap in every read-replica design, and it must be a decision rather than a discovery
- Failover is manual unless you build it, and building automatic failover correctly is harder than it looks. Write down the manual procedure and rehearse it instead
- Embedded replicas, where the application holds a local copy and syncs in the background, are the genuinely clever part of the product being replaced. libSQL gives you that; reproducing it from scratch is a project of its own

BRANCHING
- Branching a database for a preview environment is a copy: `VACUUM INTO` a new file, point the preview at it, and delete it when the branch closes
- That is one command and a cleanup job, and it covers what branching is actually used for
- Never point a preview at production data without anonymising it first — write the anonymiser as part of the branch script, not as a separate thing somebody remembers

MIGRATIONS
- Numbered files, applied once, in order, recorded in a table
- Backwards-compatible in both directions across a deploy: add a column, deploy, use it, remove the old one in a later deploy. Never in the same one
- Run inside a transaction, and test each one against a restored copy of production before it goes near production

WHAT TO WATCH
- Database file size and growth rate
- WAL size, which growing without bound means a reader is holding an old snapshot
- Replication lag and the age of the last successful upload — a replication that has quietly stopped looks exactly like one that is working
- Slow queries logged with their plans
- Free disk, with an alert well before it matters

WHEN THIS STOPS BEING ENOUGH
- Write it down before you need it: many concurrent writers, a dataset larger than the disk, or genuine multi-region writes
- The exit is a client-server database with the same schema, and knowing that in advance is what makes the simple choice safe rather than reckless

WHAT MATTERS MOST
Replication and the restore rehearsal. Set up Litestream on day one and restore from it onto a clean machine before you trust the database with anything. Everything else here is configuration; that is the part that decides whether a bad afternoon is an inconvenience or the end.

Give me the configuration, the Litestream setup, the backup and restore scripts, the branch script with anonymisation, the migration runner, the monitoring checks, and a README that opens with the restore rehearsal.