# Best Serverless Databases in 2026 (Compared)

URL: https://www.devopsness.com/blog/best-serverless-databases
Author: Kiril Urbonas
Published: 2026-08-06
Updated: 2026-10-31
Categories: Cloud
Tags: Database, Neon, Planetscale, Cloud, Serverless

Summary: A practitioner comparison of the leading serverless databases by use case, cold-start behavior, branching, pricing model, and lock-in.

---
# 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.

> [!VERIFIED]
> Neon, PlanetScale, Supabase, Aurora Serverless v2 (Aurora PostgreSQL 16.3+ / Aurora MySQL 3.08.0+ for auto-pause), CockroachDB Cloud, Turso, Cloudflare D1, DynamoDB and Upstash, against each vendor's official pricing pages and the AWS Aurora User Guide. Checked October 2026.

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](/blog/serverless-vs-traditional-database) first.

## The short list, side by side

| Database (as of October 2026) | Engine | Scales to zero | Free tier | Pricing unit |
|---|---|---|---|---|
| Neon | Postgres | Yes; Free suspends after 5 min idle | 100 CU-hours and 1 GB per project | $0.106/CU-hour + $0.35/GB-month (Launch) |
| PlanetScale | Postgres, or MySQL on Vitess | No | None | Postgres from $5/month; Vitess from $39/month |
| Supabase | Postgres plus auth, APIs, storage | Free projects pause after 1 week idle | 2 active projects, 500 MB database | Pro from $25/month |
| Aurora Serverless v2 | Postgres or MySQL | Yes, with 0-ACU auto-pause | No | ACU-hours plus storage |
| CockroachDB Cloud Standard | Postgres-compatible distributed SQL | No | 30-day trial, $400 credit | $0.092/vCPU-hour + storage |
| Turso | SQLite (libSQL) | Usage-billed | 5 GB, 500M rows read/month | Developer from $4.99/month, billed yearly |
| Cloudflare D1 | SQLite | Usage-billed | 5 GB, 5M rows read/day | $0.001/M rows read, $1.00/M rows written past included |
| DynamoDB | Key-value and document | On-demand, per request | 25 GB storage | $0.125/M reads, $0.625/M writes (us-east-1) |
| Upstash Redis | Redis | Per command | 250 MB, 500K commands/month | $0.20 per 100K commands |

## Serverless SQL: Neon, PlanetScale, Supabase

**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](/blog/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.

## 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:

```js
// lib/db.js
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.
- **`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](/blog/cloud-native-databases-choosing-right-database-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.

## 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. 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](https://neon.com/pricing)
- [PlanetScale pricing](https://planetscale.com/pricing)
- [Aurora Serverless v2 scaling to zero ACUs with auto-pause](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html)
- [Amazon DynamoDB pricing](https://aws.amazon.com/dynamodb/pricing/)