Branching with any database

Short version: branching does not have to live inside the database engine. A running database is a directory of files, and modern filesystems can clone a directory copy-on-write without copying the bytes. Snapshot the data directory, clone it, boot the clone on a fresh port, and the engine never learns anything happened. That is why lbase branch <source> <name> is the same command whether the source is Postgres, Redis, ClickHouse, or a Qdrant collection, and why cloud branching covers 16 engines instead of one.

Neon branches Postgres. PlanetScale branches MySQL. Both turned "fork the database like you fork your code" into something developers now expect. Both also built it deep inside one specific engine.

So what happens when you want to branch Redis? Or ClickHouse? Or a Qdrant collection full of embeddings? Usually nothing, because nobody wired branching into those engines, and you are not going to do it yourself.

Layerbase takes a different route. We branch at the filesystem instead of inside the database, and that one decision makes branching work the same for every engine.

Why branching is usually locked to one engine

When Neon gives you instant Postgres branches, it is because they rebuilt Postgres storage on a custom copy-on-write layer. It is genuinely impressive engineering, and it is also the reason it only works for Postgres. PlanetScale did their own version for MySQL. Each of those is a per-engine project, which is why you have never seen "branch your Redis."

The thing is, a database on disk is just a directory of files. Postgres keeps its data in a data directory. So does MySQL, MongoDB, ClickHouse, Qdrant, and every other engine. If you can cheaply copy that directory, you can branch the database, and the engine never has to know.

Branch the files, not the engine

Modern filesystems can clone a directory without copying the bytes. They share the underlying disk blocks and only write new ones when the copy changes. That is copy-on-write, and it is what makes a branch instant and nearly free instead of a full duplicate.

• macOS APFS does it with clonefile.
• Linux does it with reflinks, on Btrfs, XFS, and other filesystems that support them.
• On filesystems that cannot (plain ext4, NTFS), you fall back to a normal copy: slower, but it still works.

The Layerbase CLI (formerly SpinDB) uses exactly this to branch any engine it runs. (What is the Layerbase CLI?) It stops the source just long enough to take a consistent snapshot of its data directory, clones it copy-on-write, and starts the clone on a fresh port. The engine sees a normal data directory and boots like nothing happened.

Every engine, on your machine

npm i -g layerbase
lbase create app -e postgresql --start
lbase branch app app-test

Swap postgresql for anything. The branch command does not change:

lbase branch cache cache-test      # Redis or Valkey
lbase branch events events-test    # ClickHouse
lbase branch vectors vectors-test  # Qdrant
lbase branch docs docs-test        # MongoDB or FerretDB

It works across the whole catalog: PostgreSQL, MySQL, MariaDB, CockroachDB, SQLite, DuckDB, ClickHouse, QuestDB, libSQL, SurrealDB, InfluxDB, TypeDB, Redis, Valkey, MongoDB, FerretDB, Qdrant, Meilisearch, CouchDB, and Weaviate. Same four words, lbase branch <source> <name>, regardless of what is running underneath.

Made a mess in a branch? Re-fork it from the source's current state:

lbase branch reset app-test

Move with your git branches

Branching by hand is useful, but the workflow that sticks is the one that happens on its own. Wire it into git once:

lbase branch init --base app

The Layerbase CLI drops a post-checkout hook in the repo. Now every git checkout -b feature/x forks the database for that branch, and the CLI keeps the active branch on a stable port so your app's connection string never changes. Switch branches, get that branch's data. Switch back, get the original. Delete branches whose git branch is gone with lbase branch prune.

Instant in the cloud

Locally the filesystem is whatever your laptop has. In Layerbase Cloud we run branchable databases on a customized operating system built for exactly this, so on branch-ready storage a branch is an instant copy-on-write clone on the server. Hit Branch in the dashboard, get an isolated copy of the data in seconds, and connect a preview or staging environment to it. Same idea as local, except the machine is tuned for it instead of inheriting whatever your laptop came with. (The first time you enable branching on a database, there is a quick one-time step to prepare it.)

Cloud branching is live on Postgres, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, DuckDB, TypeDB, ClickHouse, Meilisearch, Qdrant, QuestDB, InfluxDB, and Weaviate. That is every engine you can create in Layerbase Cloud except CouchDB and TigerBeetle, which keep their cluster identity inside the data itself and are excluded by design rather than pending.

Two of those categories deserve their own write-ups, because nobody else branches them at all: Branching time-series databases covers QuestDB and InfluxDB, and Branching vector databases covers Qdrant, Weaviate, and Meilisearch.

See it in a GUI

Layerbase Desktop puts the same branching in an app. Right-click a database, choose Branch, and it tells you up front whether the clone will be instant on your filesystem or a full copy. Then open the branch and query it: a SQL console for relational engines, a document view for MongoDB and FerretDB, a key-value browser for Redis and Valkey. Branch and inspect without leaving the window.

Commands

# Branch any engine
lbase branch <source> <name>

# Re-fork from the source's current state
lbase branch reset <name>

# See the branch tree
lbase branch list

# Tie branches to git
lbase branch init --base <source>
lbase branch prune

# Delete a branch
lbase branch delete <name>

FAQ

Does branching copy all my data?

Not on a filesystem that supports copy-on-write. APFS on macOS and reflink-capable Linux filesystems like Btrfs and XFS share the underlying disk blocks and only write new ones when the branch diverges, so the clone is close to instant no matter how large the source is. On plain ext4 or NTFS you fall back to a real copy, which still works and just takes proportionally longer.

Is the source database down while a branch is taken?

Only for the moment it takes to reach a consistent snapshot of the data directory. The CLI stops the source, clones, and brings both back up. In the cloud the same thing happens on the server, which is why a branch there lands in seconds rather than minutes.

Which engines can I branch in Layerbase Cloud?

16: Postgres, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, DuckDB, TypeDB, ClickHouse, Meilisearch, Qdrant, QuestDB, InfluxDB, and Weaviate. The two cloud engines left out are CouchDB and TigerBeetle, which store cluster identity inside their own data and would come back confused about who they are. That is a design exclusion, not a queue item.

How do branches follow my git branches?

lbase branch init --base app installs a post-checkout hook. After that, creating a git branch forks the database for it, and the CLI keeps whichever branch is active on a stable port, so your app's connection string is the same string all day. lbase branch prune cleans up databases whose git branch is gone.

Can I reset a branch that got messy?

lbase branch reset <name> re-forks it from the source's current state. This is the normal way to work: treat a branch as disposable, break it deliberately while testing a migration, and take a fresh one when you want a clean slate.

Branching stopped being a Postgres feature the moment we moved it down to the filesystem. Run the Layerbase CLI locally for every engine, host on Layerbase Cloud when you need it, and branch the database you actually have instead of the one Neon or PlanetScale decided to support.