Database branching

Database branching is the developer workflow where every PR / feature branch gets its own isolated database (copy-on-write of prod schema + sample data) — Neon, PlanetScale, Supabase, Turso ship branching as a flagship feature in 2026.

Pre-branching, dev databases were either shared (concurrent dev work clobbers data) or per-dev seed scripts (drift from prod schema). Branching solves it: each PR opens a database branch (copy-on-write snapshot of prod schema, sometimes anonymized data sample), runs migrations + tests + manual QA against it, and discards on merge. Implementations: Neon (storage-level branching, sub-second branch creation), PlanetScale (keyspace branching + deploy requests), Supabase (preview branches), Turso (libSQL branches). Production patterns: PR opens → branch created → preview app deploys against it → reviewer hits live URL → merge closes branch. The unlock: catching migration footguns + dev environment fidelity without paying for N prod-sized DBs.

When to use database branching

• PR-based development workflows.
• Migration-heavy projects.

Common mistakes

• Branching with non-anonymized prod data — PII exposure on dev instances.
• Not deleting branches — branches accumulate storage costs.

FAQ

Related terms

• Serverless database — A serverless database scales compute and storage independently and bills based on actual use — no fixed instance provisioning — typical of Neon, PlanetScale, Supabase, Convex in 2026.
• Shadow deployment (LLM) — Shadow deployment runs a new model or prompt alongside the production one — receiving the same traffic but never showing output to users — to measure quality, latency, and cost before flipping live.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/database-branching.md.