Best Serverless Databases in 2026 (Compared)

Start with Neon unless you have a reason not to: it is standard Postgres, scales to zero when idle, and branches a full database per pull request. DynamoDB is the pick for key-value access at any scale, Turso or D1 for read-heavy edge apps, and Upstash for serverless Redis. Everything else is a specialist.

A serverless database is one you never size: it bills for requests, rows, or compute-seconds, scales capacity for you, and often drops to near-zero cost when idle. If you are still deciding whether you want one at all, read serverless vs traditional databases first.

The short list, side by side

Serverless SQL: Neon, PlanetScale, Supabase, Prisma Postgres

Neon splits compute from storage, which is what makes its headline features work. Compute suspends when idle and resumes on the next connection, so a staging environment costs almost nothing overnight. On the Scale plan the suspend window is configurable from 1 minute to always-on. Branching copies a full database instantly with copy-on-write: run migrations or a load test against the branch, then throw it away. Lock-in is low because pg_dump gets you out. The head-to-head is in Neon vs PlanetScale.

PlanetScale runs MySQL on Vitess, the sharding layer that carried YouTube, and now sells Postgres as well. It does not scale to zero and has no free tier, so there is a monthly floor: $5 for a single-node Postgres PS-5, $39 for the smallest three-node Vitess cluster, in AWS us-east-1. You get horizontal scale and online schema changes through deploy requests. Vitess constraints apply: cross-shard joins and foreign keys need care.

Supabase is Postgres wrapped with auth, generated REST and GraphQL APIs, row-level-security tooling, storage, and edge functions. You are buying a backend platform, which is the fastest path to a working app for a small team. Lock-in is low on the database and higher if you lean on auth and the generated APIs.

Prisma Postgres is managed Postgres 17 with PgBouncer built in: a pooled connection string for app traffic and a direct one for migrations and pg_dump. Any Postgres client works; Prisma ORM is optional. The real difference is the bill. Neon charges per CU-hour while compute is awake; Prisma Postgres charges per operation, where one query counts once whether it is a key lookup or a five-way join, and idle time costs nothing. That rewards heavy queries and quiet hours, and punishes chatty code: N+1 loops, SELECT 1 health checks, and interactive transactions, which count per query. We run this site on the Starter plan: in August 2026 over-eager page regeneration drove 5.96M operations and a $49.71 bill, where Pro's $49 would have included 10M. There is no copy-on-write branching (preview databases come with Prisma Compute deploys and start empty), no backups on Free, and six regions to choose from.

Disclosure: Prisma asked us to include Prisma Postgres, and in exchange I'm writing a guest post for the Prisma blog. Prisma did not review this entry. This site runs on Prisma Postgres and pays list price.

Tweet this ↗

Distributed SQL: Aurora Serverless v2 and CockroachDB

Aurora Serverless v2 can set minimum capacity to 0 ACUs and auto-pause on Aurora PostgreSQL 16.3, 15.7, 14.12, 13.15 or later, or Aurora MySQL 3.08.0 or later. The idle window runs from 300 seconds to 86,400 seconds. Turning it on for an existing cluster is one call:

aws rds modify-db-cluster --db-cluster-identifier my-dev-cluster \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=8,SecondsUntilAutoPause=600
aws rds describe-db-clusters --db-cluster-identifier my-dev-cluster \
    --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 8.0,
    "SecondsUntilAutoPause": 600
}

AWS documents a typical resume of about 15 seconds, and 30 seconds or more after a day paused, so this is for dev, test, and internal apps, not latency-sensitive paths.

CockroachDB Cloud speaks the Postgres wire protocol, distributes data across nodes, and survives zone failures without manual failover. As of October 2026 the Standard tier bills per vCPU-hour, so treat it as autoscaling, not scale-to-zero. Both are the answer when losing a single primary is unacceptable.

Edge SQLite, NoSQL, and Redis

Turso and Cloudflare D1 both put SQLite near your users and bill on rows read and written. Writes go to one primary, so they shine for read-dominated workloads; D1 is the natural pick inside Workers, and Turso's embedded replicas serve reads from a local file anywhere else. Watch D1's free write cap: 100,000 rows written per day.

DynamoDB is the default serverless NoSQL store: on-demand capacity, single-digit-millisecond reads at any scale, as long as you design keys around your access patterns. Lock-in is high; the data model and API don't port. Upstash fills the Redis slot with per-command billing, which suits caches and rate limiters called from serverless functions.

The trade-offs nobody escapes

Cold starts: anything that scales to zero pays a wake penalty on the first request. Fine for staging, worth measuring on production paths.

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

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

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

export const activeUsers = () => sql`
  SELECT id, email FROM users WHERE active = true LIMIT 20
`;

There is no long-lived TCP socket to leak from a Lambda or an edge function.

Egress: cross-region reads and heavy result sets add up. Neon's Scale plan charges $0.10/GB of public egress past 500 GB per project. Keep compute and data in the same region.

The failure modes, by error

• FATAL: sorry, too many clients already (any Postgres): functions opened more connections than the server allows. Switch to the HTTP driver or the pooled connection string.
• Connection timeouts right after idle (Aurora, Neon): the first request hit a paused instance. Raise client connect timeouts past 15 seconds for Aurora (30 if it sleeps more than a day) and add retry logic, which AWS recommends.
• Aurora never pauses: an open session, an RDS Proxy, logical or binlog replication, or a global database primary keeps the writer awake. Check DatabaseConnections in CloudWatch.
• pg_cron jobs silently skipped (Aurora): a paused instance does not wake for scheduled jobs; they are dropped, not queued.
• Pool errors on Prisma Postgres Free: the plan allows 10 pooled connections in total, so one instance on node-postgres's default max: 10 takes all of them. Lower max, and send session features (SET, LISTEN, advisory locks) to the direct host db.prisma.io, because the pooler runs in transaction mode.
• Connection errors after a quiet hour (Prisma Postgres): Prisma does not publish a wake time for an idle database, and the pooler closes idle connections after 60 minutes and stops queries after 10. Keep the client's idle timeout under an hour, handle the pool's error event, and run long jobs on the direct host.
• Every query rejected (Prisma Postgres Free): once the 200K included operations are used, the database stops accepting reads and writes until you upgrade or the allowance resets. There is a one-time 24-hour grace period per workspace, and the data is kept.
• ProvisionedThroughputExceededException or ThrottlingException (DynamoDB): a hot partition key. On-demand does not fix a bad key design.

Where this breaks

Scale-to-zero pricing only wins while a database is mostly idle. A production Postgres busy around the clock bills compute every hour, and a provisioned instance with a reserved discount can come out cheaper. Usage-billed engines also turn a bad query into a bad invoice: a full table scan on D1 or Turso is billed per row read. And none of these lists help with compliance needs like a specific region or private networking, which vary by plan; check that before price.

Questions people ask

What is a serverless database?

A serverless database is a managed database you never size or patch: the provider scales capacity with load and bills by usage, such as compute-hours, rows read, or requests, instead of a fixed instance. Many scale to zero when idle. Neon, Aurora Serverless v2, DynamoDB on-demand, Turso, Cloudflare D1, and Upstash all fit; PlanetScale is managed but bills by cluster size.

Does Aurora Serverless v2 scale to zero?

Yes, on supported engine versions. Set the cluster's minimum capacity to 0 ACUs and instances auto-pause after an idle window you choose, from 300 seconds to one day. You pay nothing for instance capacity while paused, though storage still bills. AWS says resume typically takes about 15 seconds, longer after 24 hours paused, so raise client connection timeouts accordingly.

How do I pick a reliable serverless database for production?

Match the engine to the access pattern first: Postgres for relational data, DynamoDB for key-value at scale. Then check three things: the cold-start time if it scales to zero, whether it has an HTTP driver or pooler for serverless functions, and whether you can export your data with standard tools. Neon and Aurora pass all three for Postgres.

The decision, concretely

Match the workload, not the hype; the broader framework across engines is in choosing the right database for your workload.

• Postgres with scale-to-zero and preview branches? Neon.
• MySQL that must scale past a single primary? PlanetScale.
• A full backend fast, with a small team? Supabase.
• Global reads with low latency? Turso, or D1 on Workers.
• Key-value at scale? DynamoDB. Serverless Redis? Upstash.
• Postgres billed per query, for spiky traffic and a query count you can estimate? Prisma Postgres; chatty apps do better on compute-hours.

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 better dev workflow. If you already know you are MySQL-shaped and heading for real scale, start on PlanetScale and skip the migration. Prisma Postgres is the easier bill to forecast when you can count your queries, so count them before choosing it. Go edge-first only when read latency to a global audience is the product requirement, and confirm current prices yourself before building the bill into your model.

Sources

• Neon pricing
• PlanetScale pricing
• Aurora Serverless v2 scaling to zero ACUs with auto-pause
• Amazon DynamoDB pricing
• Prisma Postgres
• Prisma pricing
• Prisma Postgres connection pooling
• Prisma Postgres FAQ: operations and plan limits
• Prisma: fixing too many connections
• Prisma: slow first request after idle