Best Serverless Databases in 2026 (Compared)

Picking a serverless database used to mean picking DynamoDB and living with it. In 2026 there are at least a dozen credible options, and they behave very differently once you push traffic through them. This is a working comparison of the leading serverless databases, sorted by what they are actually good at. For deeper background on the category, see our serverless and edge databases guide.

Every price and quota below changes often, so treat specifics as "verify current" against the vendor's pricing page before you commit.

Neon: serverless Postgres with real branching#

Best at: Postgres apps that spike and idle, plus preview environments.

Neon splits compute from storage, which is what makes its headline features work. Databases scale to zero when idle and resume on the next connection, so a staging environment costs almost nothing overnight. Branching is the standout: you copy a full database instantly using copy-on-write, run migrations or a load test against the branch, then throw it away. That maps cleanly onto a per-pull-request workflow.

SQL flavor: vanilla Postgres, extensions included. Scale-to-zero: yes, this is the default. Cold start: resume from idle is typically sub-second to a couple of seconds. Noticeable on the first request after idle, invisible after that. Pricing: compute-hours plus storage, with a usable free tier. Lock-in: low. It is standard Postgres, so pg_dump gets you out.

If you want the head-to-head, we wrote up Neon vs PlanetScale separately.

PlanetScale: MySQL and Vitess at serious scale#

Best at: high-throughput MySQL where you have outgrown a single primary.

PlanetScale runs on Vitess, the same sharding layer that carried YouTube. It does not scale to zero, so there is a real monthly floor, but in exchange you get horizontal scale most teams never hit a ceiling on. Its branching model predates Neon's and adds deploy requests: schema changes are reviewed and applied online without locking tables, which is a genuine relief on large MySQL tables.

SQL flavor: MySQL, with some Vitess constraints (foreign keys and cross-shard joins need care). Scale-to-zero: no, always-on. Cold start: none in the idle sense, since it stays warm. Pricing: row-reads, row-writes, and storage. Lock-in: moderate. It is MySQL underneath, but the branching and deploy-request workflow is sticky.

Supabase: Postgres plus a backend#

Best at: teams that want a database and the rest of the backend in one place.

Supabase is Postgres wrapped with auth, auto-generated REST and GraphQL APIs, row-level-security tooling, storage, and edge functions. You are buying a platform, not just a database. That is the fastest path from zero to a working app, especially for a small team without a dedicated backend engineer.

SQL flavor: full Postgres. Scale-to-zero: paused on the free tier after inactivity; paid instances generally stay on. Cold start: a paused free project takes a moment to wake. Pricing: tiered plans plus usage for compute, storage, and bandwidth. Lock-in: low on the database, higher if you lean on auth and the generated APIs.

Turso and Cloudflare D1: SQLite at the edge#

Best at: read-heavy, globally distributed apps where latency to the user matters.

Both put SQLite next to your users. Turso is built on libSQL, a SQLite fork, and replicates to many regions so reads are local. Cloudflare D1 is SQLite living inside the Workers platform, which is the obvious pick if your app already runs on Workers. Writes go to a primary, so these shine for read-dominated workloads, not write-heavy transactional ones.

SQL flavor: SQLite. Scale-to-zero: effectively yes, you pay for usage not idle capacity. Cold start: minimal, the engine is tiny. Pricing: rows read and written, storage, and replica count. Lock-in: low on SQL, moderate with D1 given its Workers coupling.

CockroachDB Serverless and Aurora Serverless v2: distributed SQL#

Best at: transactional workloads that need strong consistency and can grow without resharding.

CockroachDB Serverless speaks the Postgres wire protocol, distributes data across nodes automatically, and survives zone failures without manual failover. Aurora Serverless v2 is AWS's autoscaling flavor of Aurora and comes in Postgres and MySQL variants. Aurora v2 scales capacity units up and down smoothly but does not truly hit zero the way Neon does, so expect a baseline cost. Both are the answer when a single-primary database is a risk you cannot accept.

SQL flavor: Cockroach is Postgres-compatible; Aurora is Postgres or MySQL. Scale-to-zero: Cockroach can idle down; Aurora v2 keeps a minimum capacity floor. Cold start: Cockroach resume is quick; Aurora scaling is gradual rather than a hard cold start. Pricing: Cockroach bills request units and storage; Aurora bills capacity units and I/O. Lock-in: moderate for Cockroach, higher for Aurora given the AWS integration.

Fauna and DynamoDB: serverless NoSQL#

Best at: key-value and document access patterns at predictable single-digit-millisecond latency.

DynamoDB is the default serverless NoSQL store, on-demand capacity means you never manage servers, and it stays fast at any scale as long as you design keys around your access patterns. Fauna adds a document model with its own query language and native multi-region consistency. Neither is relational, so you trade ad-hoc JOINs for speed and operational simplicity.

SQL flavor: none. Key-value and document. Scale-to-zero: yes, on-demand billing charges per request. Cold start: none to speak of. Pricing: read and write units plus storage. Lock-in: high. The data model and query API do not port anywhere.

The trade-offs nobody escapes#

Cold starts: any database that scales to zero pays a wake penalty on the first request. Fine for staging, worth measuring for latency-sensitive production paths. Keeping one instance warm defeats the point of scale-to-zero.

Connections: serverless functions open a connection per invocation and can exhaust a Postgres server fast. Use the vendor's HTTP-based serverless driver or a pooler like PgBouncer. A Neon serverless-driver query over HTTP looks like this:

import { neon } from '@neondatabase/serverless';

const sql = neon(process.env.DATABASE_URL);

const users = await sql`
  SELECT id, email FROM users WHERE active = true LIMIT 20
`;

That call goes over HTTP, so there is no long-lived TCP socket to leak from a Lambda or an edge function.

Egress: data leaving the provider is often the line item that surprises you. Cross-region reads and heavy result sets add up. Keep compute and data in the same region where you can.

How to choose#

Match the workload, not the hype.

• Postgres with scale-to-zero and preview branches: Neon.
• MySQL that needs to scale past a single primary: PlanetScale.
• A full backend, fast, with a small team: Supabase.
• Edge and global reads with low latency: Turso or Cloudflare D1.
• Distributed SQL with strong consistency: CockroachDB, or Aurora Serverless v2 if you are AWS-native.
• Serverless NoSQL at scale: DynamoDB, or Fauna for a document model.

The call we'd make#

For most new applications in 2026, start with Neon. Standard Postgres keeps your options open, scale-to-zero keeps early costs near nothing, and branch-per-pull-request is a genuinely better dev workflow. If you already know you are MySQL-shaped and heading for real scale, start on PlanetScale instead and skip the migration later. Go edge-first with Turso or D1 only when read latency to a global audience is the actual product requirement, and reach for Cockroach or Aurora when losing a primary is unacceptable. Whatever you pick, confirm the current pricing and quotas yourself before you build the bill into your model.