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.

Serverless databases replace provisioned instances with usage-billed compute and storage. The win: scale to zero during idle periods, scale up automatically under load, pay only for what you use. The trade-off: cold-start latency on first request after idle, less predictable cost at very high scale. By 2026 serverless Postgres (Neon, Supabase, Xata) and serverless MySQL (PlanetScale) dominate new web app deployments. Best practice: pick serverless for variable / spiky workloads; provisioned still wins for steady high-throughput production.

When to use serverless database

• Variable / spiky workloads.
• Multi-tenant apps where many tenants are idle most of the time.
• Cost-sensitive dev / staging environments.

Common mistakes

• Using serverless for steady high-throughput — predictable provisioned is often cheaper.
• Ignoring cold-start in latency budgets.

FAQ

Related terms

• 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.
• Vector database — A vector database stores embeddings and performs approximate nearest-neighbor search at scale, the persistence layer behind RAG and semantic search.

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