Serverless Postgres: the options in 2026

Short version: "serverless Postgres" is five different products wearing one phrase, and the two questions that actually separate them are what happens when nobody is talking to your database, and how you reach it from a runtime that cannot hold a socket open. Neon re-architected storage and compute so compute scales to zero, and bills CU-hours. Aurora Serverless v2 resizes an ordinary Aurora cluster between a floor and a ceiling you set, and the floor is a floor on the bill too. Supabase pauses free projects after a week and does not scale paid compute to zero. PlanetScale Postgres is flat per cluster with no scale-to-zero at all. Ours is upstream Postgres on a disk that hibernates when idle and wakes on the next connection in roughly one to five seconds, reachable over pooled TCP or the @neondatabase/serverless HTTP driver.

Contents

• The options at a glance
• 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
• FAQ

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 options at a glance

Competitor rates verified 2026-08-25 from neon.com, supabase.com and planetscale.com. Aurora rates are per region and per engine, so read the AWS page for yours.

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 low database activity and stay restorable from Studio for up to a year, which is a pause you resume from a dashboard rather than a sleep your next connection wakes. Their docs add the caveat worth reading before you rely on that window: backups age out, and platform changes may not be backward compatible with an old one. 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, starting at $5 for a single-node PS-5 and $15 for the three-node HA version of the same size, with storage, backups, egress, and replicas billed separately (pricing). The catalog runs a long way up from there, past $5,599 for the largest EBS-backed HA cluster. 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 15 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.

FAQ

Is Postgres actually serverless, or is that marketing?

Both, depending on the vendor. Postgres itself is a long-running process with a shared buffer cache and no HTTP interface, so nothing makes it serverless at the engine layer. What each vendor sells is a lifecycle wrapped around that process: suspend it when idle, resize it under load, or put a request-shaped protocol in front of it. Neon changed the storage architecture to do it. We left the engine alone and changed what happens around it. Both are honest, they just move different parts.

Can I use Postgres from a Cloudflare Worker or a Vercel Edge Function?

Yes, on Neon and on Layerbase. Those runtimes cannot open a TCP socket, so you need an HTTP query path, and both answer the @neondatabase/serverless driver. On our side that works with your ordinary connection string, no separate hostname and nothing to enable, and @vercel/postgres, Drizzle's neon-http adapter and the Prisma and Kysely Neon adapters all sit on the same driver. The one gap is interactive transactions through the driver's WebSocket Pool mode, which only Neon implements today.

What is the difference between hibernating and pausing?

Whether a human is required. Hibernation and scale-to-zero come back on the next connection with nothing to click, so the cost is a slow first query. A pause is a state you resume from a dashboard, so an unattended staging environment stays down until somebody notices. Supabase free projects pause; Neon free computes suspend at 5 idle minutes; ours hibernate at 15 idle minutes on free and 6 hours on paid.

Do I need a separate direct connection string for migrations?

Not with us. The pooled string is transaction-mode PgBouncer, and Payload and Drizzle migrations are both verified end to end through it, which is a difference worth checking on any platform that hands you two strings and a footnote about which one runs DDL.

Why do my serverless functions hit a connection limit?

Because a fleet of concurrent function instances looks like one very impatient client. A database's direct port allows 20 new connections per 10 seconds per source IP, and serverless platforms egress through a small pool of shared NAT addresses, so a cold-start burst arrives from what appears to be a single machine. Use the pooled string, which routes over the shared endpoint and is not subject to that cap. The serverless and edge guide has the rest.

Which one should I pick if I only care about the bill not moving?

Ours or PlanetScale, for opposite reasons. PlanetScale is flat per cluster size with no scale-to-zero, so the number is stable until you outgrow a SKU and take a step up. We are flat per plan with hibernation, so the number is stable and the trade is a slow first query after idle. Everything else on this list will bill you for a query plan that changed.

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.