Serverless Postgres: the options in 2026

Postgres is not a serverless database. It is a process that expects to be running, holding a connection pool and a shared buffer cache, and it has never had an HTTP interface. Everything sold as "serverless Postgres" is a set of engineering decisions made around that fact, and the decisions differ enough that the same phrase describes genuinely different products.

The two questions that separate them: what happens to your database when nobody is talking to it, and how you reach it from a runtime that cannot hold a connection open. Every option below answers both, differently.

Contents

• Neon: storage and compute pulled apart
• Aurora Serverless v2: the same cluster, resized for you
• Supabase: a platform with a pooler in front
• PlanetScale Postgres: flat per cluster
• Layerbase: plain Postgres that sleeps
• The part we did not have, until now
• Picking one

Neon: storage and compute pulled apart

Neon is the option that changed the architecture rather than working around it. Storage lives in a separate service, compute is a Postgres process that can be started and stopped independently of the data, and copy-on-write branching falls out of that split almost for free.

The practical results are the ones people cite: compute scales to zero when idle, branches are cheap because they share storage pages, and there is a first-party serverless driver that "replaces TCP with HTTP or WebSockets" so a Cloudflare Worker can issue a query without a socket. Branching is 10 branches per project on the free plan and $1.50 per branch-month beyond it, and compute is metered in CU-hours (plans). Their site is at Neon.

The trade is the one that comes with any re-architecture: you are running Postgres on a storage layer that is not the one Postgres was written against. That has been in production for years and works, and it is still a different set of failure modes than a Postgres on a disk. The metering is the other consideration, and I broke down what a CU-hour bill is actually a function of in serverless database pricing compared.

Aurora Serverless v2: the same cluster, resized for you

Aurora Serverless v2 keeps ordinary Aurora underneath and makes the capacity elastic. You set a minimum and a maximum in Aurora Capacity Units, the cluster moves between them as load changes, and you are billed per ACU-hour at the rate on the Aurora pricing page for your region.

This is serverless in the "I do not want to pick an instance type" sense, and it is the strongest option on the list if your database already belongs to an AWS account: same VPC, same IAM, same backup and failover story, same support contract. It is the weakest option if what you wanted was a URL five minutes after signing up. Your minimum capacity setting is also a floor on the bill, so the idle cost is a number you choose rather than zero by default.

Supabase: a platform with a pooler in front

Supabase is a Postgres plus the services around it, and its serverless story is mostly about access rather than about compute shrinking. You get PostgREST, which exposes an auto-generated REST API over your schema at /rest/v1/, and that is what makes Supabase reachable from an edge runtime. A pooler sits in front for the connection-count problem.

At idle, the behavior splits by plan. Free projects pause after one week of inactivity and are restorable for 90 days, which is a pause you resume from a dashboard rather than a sleep your next connection wakes. Paid projects do not scale compute to zero; the paid plan is a flat $25 a month plus metered compute, storage, egress, and monthly active users (pricing).

If you want the whole platform, that is a coherent product and the REST layer is genuinely good. If you wanted a Postgres, you are also adopting Auth, Storage, and Realtime whether or not you use them. Neon vs Supabase has that comparison at length.

PlanetScale Postgres: flat per cluster

PlanetScale added Postgres alongside its Vitess offering, so it belongs on this list now. It is not scale-to-zero: you buy a cluster size and pay for it monthly, from $5 to $5,599 on Postgres, with storage, backups, egress, and replicas billed separately (pricing). There is no free plan; Hobby retired in 2024 and their docs say so directly.

What earns it a spot in a serverless conversation is the edge story: PlanetScale Postgres supports the Neon serverless driver's HTTP mode (changelog), so the fetch-based access pattern works there too. Predictable pricing with no meter on queries, at a starting price that assumes you are past the side-project stage.

Layerbase: plain Postgres that sleeps

Our answer is deliberately boring at the engine layer: it is upstream PostgreSQL, on a disk, with no storage-layer rewrite and no proprietary driver. The serverless part is the lifecycle around it.

At idle, it hibernates. A free database after 60 idle minutes, a paid one after 6 hours. Hibernation keeps the hostname, the port, and the volume, so waking is not a restore: the next connection brings it back in roughly 1 to 5 seconds and your query then runs. For the Postgres-wire engines the wake happens on the shared 5432 endpoint using the TLS SNI hostname your client already sends, which is why there is no button to press and no keep-alive job to write. Left alone for 14 days a free database is archived and needs an explicit Restore, about 10 to 30 seconds; paid databases are never auto-archived.

You connect with the driver you already have. pg, postgres.js, psycopg, JDBC, Prisma, Drizzle, TypeORM, Payload. There is no Layerbase driver to install and no dialect to select, because the thing on the other end is Postgres speaking the Postgres wire protocol. The pooled connection string is transaction-mode PgBouncer, and unlike some platforms you do not need a second direct string for migrations: Payload and Drizzle migrations are both verified end to end through the pooler.

From Node-based serverless, use the pooled string. Vercel Functions, Lambda, Cloud Run, and Netlify Functions can open TCP sockets, so a normal connection works, but a fleet of concurrent instances should not each hold a real backend. There is a second reason that is easy to miss: a database's direct port enforces a limit of 20 new connections per 10 seconds per source IP, and serverless platforms egress through a small pool of shared NAT addresses, so a burst arrives looking like one very impatient client. The pooled string for Postgres routes over the shared endpoint, which is not subject to that cap. The serverless and edge guide has the details.

mTLS is available on Pro. Client certificates rather than only a password, which none of the vendors above offer on their connection-security pages. Deno and Supabase Edge Functions can open a TLS socket, so they can present one through the @layerbase/deno-mtls adapter. The full setup is in Postgres mTLS client certificates.

Branching is included. Fork a writable copy before a risky migration and throw it away if it goes badly. It works on 16 engines, Postgres among them, and it is not billed per branch-month.

And Postgres is one of 18 engines on Layerbase Cloud, so when this app grows a cache or a vector store, that lands in the same account and the same bill rather than in a fourth vendor's dashboard.

The part we did not have, until now

When this post was first published, this section conceded a real gap: there was no HTTP driver for Postgres on Layerbase, so a Cloudflare Worker or Vercel Edge Function, which cannot open a TCP socket at all, could not reach a Layerbase Postgres with an ORM, and Neon's driver was the honest reason to pick Neon for that case.

That is closed. Layerbase Postgres now speaks the HTTP query protocol used by @neondatabase/serverless, and it does so with your normal Layerbase connection string:

import { neon } from '@neondatabase/serverless'

const sql = neon(process.env.DATABASE_URL) // a Layerbase connection string
const rows = await sql`select * from users where id = ${id}`

Nothing to enable, no separate hostname: the driver derives its endpoint from the hostname in the connection string, and Layerbase answers at that endpoint. @vercel/postgres, Drizzle's neon-http adapter, and the Prisma and Kysely Neon adapters sit on the same driver and work the same way. Each request runs through the database's connection pooler, so a burst of cold-started functions does not exhaust connections, and a hibernated database wakes on the first request. The write-up is Postgres over HTTP for Vercel, Workers, and Lambda.

Two limits, stated plainly. Interactive transactions through the driver's WebSocket Pool mode are not implemented; sql.transaction([...]) batches are, and they run as one BEGIN ... COMMIT. And a database with client-certificate (mTLS) enforcement refuses the HTTP path, because HTTP cannot present the certificate, which is the point of mTLS.

The HTTP query API is still there too: POST /v1/databases/:id/query with a Bearer key covers every cloud engine except TigerBeetle, and Redis and Valkey expose an Upstash-compatible REST endpoint while MySQL and MariaDB expose a PlanetScale-compatible one. The drop-in-driver story now exists on our side for Postgres as well.

Picking one

Your Postgres has to answer from an edge runtime. Neon or Layerbase; both speak the same serverless driver, so the decision moves to price, idle behavior, and whether you need interactive transactions over WebSocket, which only Neon has today.

Your Postgres lives in AWS with everything else. Aurora Serverless v2. The integration is the product, and nothing on this list competes with same-VPC.

You want the platform, not just the database. Supabase, with the pausing behavior of the free plan understood up front.

You want a flat bill and a database that sleeps when nobody needs it. Ours. Plain Postgres, pooled TCP or the Neon serverless driver over HTTP from your serverless functions, wake-on-connect measured in seconds, mTLS if you need it, and a monthly price that does not move because a query scanned more rows than you expected. The plan numbers are on the pricing page and the architecture behind serverless databases is written up there.

You are still prototyping. Run it locally first. The Layerbase CLI starts a real Postgres on your machine with no Docker, and moving that to a hosted one later is a dump and a restore, which is the same path I walked through in PGlite to production Postgres.

Create a Postgres database and time the first connection after an idle hour. That number is the only part of a serverless claim you cannot check from a pricing page.