Database Branching Without a Control Plane: What Neon and Turso Actually Sell — and What Litestream Gives You for Free

Three products now sell you the same trick: "get a full, independent copy of your production database in under a second." Neon does it with copy-on-write Postgres. Turso does it with a managed libSQL API. And a self-hosted SQLite file, replicated with Litestream to the object storage a platform already runs for backups, can do a version of it too — for the cost of one restore command.

They are not the same trick underneath, and they don't cost the same thing. Neon's answer is a distributed storage engine that took years to build and still isn't something you'd stand up yourself. Turso's answer is a proprietary control plane sitting on top of an open-source database — the openness applies to the database, not the branching. And the self-hosted answer is the cheapest of the three in dollars, but only because it quietly redraws what "branch" means.

How Litestream Actually Works​

Litestream is the piece that makes the self-hosted answer possible, so start there. It's a Go binary that runs as a sidecar next to a SQLite database, tailing SQLite's write-ahead log and streaming each new WAL frame to an external replica — Amazon S3, Google Cloud Storage, Azure Blob Storage, SFTP, or a local path. It isn't a network database server; SQLite still writes to a local file, and Litestream's only job is to make sure every committed transaction has already left the machine by the time anyone asks.

Two properties matter for what comes next:

• Point-in-time restore. litestream restore rebuilds a database file from the replica, and can target either "latest" or a specific timestamp, as long as that timestamp falls inside the retained WAL history. That's the primitive a "branch" gets built from.
• Single-writer assumption. Litestream assumes one process holds the write lock. If a second writer shows up — a botched failover, a stray process — it detects the conflict optimistically (the sync aborts if the remote transaction ID moved unexpectedly) rather than resolving it for you. The application has to handle that.

Nothing here talks to Postgres, computes a diff, or manages a control plane. It streams bytes to storage you already have, and it can rebuild a file from any point in that history. That's the entire self-hosted budget.

What Neon's Branch Actually Costs​

Neon's version of "instant copy" is real engineering, and it's worth being precise about what it buys. Neon separates Postgres compute from a distributed, versioned storage layer, and every write lands as a new copy-on-write version rather than an overwrite. Creating a branch is a metadata operation — point a new compute process at the same storage layer files the parent branch already has, and let new writes diverge from there. That's why branch creation is O(1): a multi-terabyte database branches in under a second because nothing terabyte-sized actually moves.

That's also why it isn't a Saturday side project. Building a system where "create a branch" is a pointer swap into a shared, versioned storage substrate — not a pg_dump/pg_restore loop — is the kind of infrastructure a self-hosted platform that deliberately doesn't manage tenant databases has no reason to rebuild.

Priced out, on Neon's Launch plan in 2026: storage runs a flat $0.35/GB-month, compute runs $0.106/CU-hour, and the first 10 simultaneous branches per project are included — additional branches bill at roughly $0.002/branch-hour, about $1.50/branch-month. A team running 20 preview branches beyond the included 10 is looking at roughly $15/month in branch overage alone, before compute or storage for any of them. That's a genuinely fair price for what it buys — full Postgres semantics, real concurrent writers, arbitrary query complexity, all inherited by every branch. It's also not a price a self-hosted platform can undercut by copying Neon's architecture; it can only decide not to need it for every workload.

What Turso's Branching Really Is — and Isn't, If You Self-Host​

Turso's branching looks deceptively similar from the CLI: turso db create my-app-dev --from-db my-app clones a database, available on every plan including the free tier, and --from-db combined with --timestamp clones from a specific point in the source's history — Turso's own version of point-in-time branching. Pair that with embedded replicas — a local libSQL file that syncs reads from a cloud primary in microseconds and forwards writes back to it — and the pitch is a SQLite-flavored version of what Neon does for Postgres.

Here's the part that matters for self-hosting: libSQL itself is genuinely open source (tursodatabase/libsql on GitHub), and you can run its server component, sqld, on any VM. But sqld ships no --from-db equivalent, no managed point-in-time branch command, and no hosted embedded-replica sync service. Branching is a feature of Turso's cloud control plane, built on top of the open-source database — not a capability that comes with self-hosting libSQL. Running sqld yourself gets you a network-accessible SQLite server; it doesn't get you Turso's branch command for free, any more than running Postgres yourself gets you Neon's copy-on-write storage engine for free.

That distinction shows up in Turso's pricing, too, though not in the way it first appears. Since branch creation itself is available even on the free plan, the $4.99/month Developer, $24.92/month Scaler, and $416.58/month Pro tiers aren't the price of the branching feature specifically — they're the price of the row-reads, storage, and point-in-time-retention window that usage against those branches actually consumes (the Scaler plan's 100 billion included row reads and 30-day PITR are what a team running several long-lived branches against real traffic will actually hit the ceiling on). The command is free; running it against a workload big enough to need Turso at all generally isn't.

The Self-Hosted Recipe: A Branch Command Using Storage You Already Pay For​

This is the piece a self-hosted platform can actually build, because it doesn't require inventing a storage engine or a control plane — it reuses the object storage bucket a platform already needs for backups.

The topology: each tenant's SQLite file replicates continuously via Litestream to a per-tenant path in that bucket —

s3://backups/tenants/<tenant-id>/db

That's not a new piece of infrastructure. It's the same bucket, and the same replication stream, the platform is already running so tenants have disaster recovery.

"Branching" a tenant's database for a preview deploy or a migration test is then one command:

litestream restore \
  -o preview.db \
  -timestamp 2026-07-09T18:00:00Z \
  s3://backups/tenants/acme-corp/db

That produces an independent SQLite file — preview.db — reconstructed from the WAL history up to the requested timestamp, ready to mount into a preview app with zero effect on the production file it came from. Run it without -timestamp and it restores the latest state instead; run it with a timestamp and you get exactly the point-in-time branch Neon and Turso both charge for.

The cost is whatever that bucket already costs — no per-branch-hour meter, no row-read counter, no separate SKU. A team running ten preview branches a month pays for the storage those ten files occupy on disk, and nothing else, because the "branch" operation is a file copy from a system already on the books.

Where This Breaks​

None of that makes SQLite-via-Litestream a Postgres replacement, and the honest boundary is worth stating as plainly as the recipe above:

• Single-writer only. Litestream's conflict detection assumes one writer. A workload with genuinely concurrent writers — multiple app instances writing to the same tenant database — needs either external write serialization or a database built for it, not this recipe.
• No native multi-node write scaling. SQLite's file-based model doesn't distribute writes across nodes. A preview.db branch is a full, independent copy for a preview environment; it isn't a scaling strategy for a database under sustained write load.
• No substitute for the multi-tenant HA case. A tenant that needs failover, connection pooling across replicas, and complex multi-table queries at scale is squarely CNPG-or-managed-Postgres territory — SQLite was never trying to compete there, and pretending otherwise is how a self-hosted default becomes an outage.

Picking the Default, Not the Religion​

Put next to each other, the three answers to "how does a tenant get a branch" aren't competing for the same workload:

A marketing site's CMS, a small SaaS's config store, a per-tenant settings database that one process writes to at a time — that's the workload where a litestream restore command is a complete answer, and paying for a distributed storage engine or a managed control plane would be solving a problem the workload doesn't have. A workload with real concurrent writers and complex queries is exactly the reverse: that's what CNPG-backed Postgres is already the documented default for.

Neither default is a compromise. Documenting both — explicitly, by workload shape, rather than picking one database story and hoping every tenant fits it — is what "the platform doesn't manage your database" should mean in practice, not an excuse to leave every tenant to figure it out alone.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Managed databases were never the pitch; a tenant's SQLite file replicating to the object storage the platform already runs is. Star the repo on GitHub or deploy your first app today.