Branching with any database

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 ZFS, Btrfs, and XFS do it with reflinks.
• On filesystems that cannot (plain ext4, NTFS), you fall back to a normal copy: slower, but it still works.

SpinDB uses exactly this to branch any engine it runs. (What is SpinDB?) 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 spindb
spindb create app -e postgresql --start
spindb branch app app-test

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

spindb branch cache cache-test      # Redis or Valkey
spindb branch events events-test    # ClickHouse
spindb branch vectors vectors-test  # Qdrant
spindb 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, spindb branch <source> <name>, regardless of what is running underneath.

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

spindb 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:

spindb branch init --base app

SpinDB drops a post-checkout hook in the repo. Now every git checkout -b feature/x forks the database for that branch, and SpinDB 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 spindb branch prune.

Instant in the cloud

Locally the filesystem is whatever your laptop has. In Layerbase Cloud we run branchable databases on ZFS, so 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, with the storage layer chosen for us instead of inherited from your machine. (The first time you enable branching on a database, we move it onto that storage, a quick one-time step.)

Cloud branching is live on Postgres, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, and DuckDB today, with more engines moving onto the same storage as the rollout continues. The method is engine-agnostic, so the list only grows.

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
spindb branch <source> <name>

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

# See the branch tree
spindb branch list

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

# Delete a branch
spindb branch delete <name>

Branching stopped being a Postgres feature the moment we moved it down to the filesystem. Run SpinDB 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.