Compute / storage separation
Compute / storage separation is the cloud-database architecture where compute (queries) and storage (data) scale independently — letting compute scale to zero while storage stays durable. Neon, Aurora Serverless, Snowflake, BigQuery pioneered this in 2026.
Traditional databases bundle compute + storage on the same machine; scaling means resizing both. Separation flips this: storage lives in a durable shared layer (S3 / EFS / proprietary), compute is ephemeral and stateless, multiple compute instances can read the same storage, compute can scale to zero while data persists. The unlocks: cheap idle databases (Neon scale-to-zero), per-query elastic compute (Snowflake warehouses), read replicas without storage duplication, instant database branching ([[database-branching]] uses storage CoW). Trade-offs: compute cold-start when scaling from zero (typically 100ms-3s in 2026), network latency between compute and storage requires careful caching. The architecture behind most modern serverless databases.
When to use compute / storage separation
- Spiky workloads (dev DBs, batch analytics).
- Apps that need cheap idle states.
Common mistakes
- Latency-critical apps may hit cold-start delays — pre-warm or pin compute.
FAQ
What is compute / storage separation?
Compute / storage separation is the cloud-database architecture where compute (queries) and storage (data) scale independently — letting compute scale to zero while storage stays durable. Neon, Aurora Serverless, Snowflake, BigQuery pioneered this in 2026.
When should I use compute / storage separation?
Spiky workloads (dev DBs, batch analytics). Apps that need cheap idle states.
What are the most common mistakes with compute / storage separation?
Latency-critical apps may hit cold-start delays — pre-warm or pin compute.
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.
- 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.
- Cold start (inference) — Cold start is the delay incurred when a serverless inference function loads its model into GPU memory for the first time after being idle — typically 5-60 seconds for large LLMs.
Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/compute-storage-separation.md.