Skip to content
LayerbaseLayerbase

Serverless Postgres: the options in 2026

8 min readPostgreSQLServerlessComparison

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

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 9 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 do not have

We do not have an HTTP driver for Postgres. If your code runs in a Cloudflare Worker or a Vercel Edge Function, which cannot open a TCP socket at all, pg against our connection string will not work, and there is no @layerbase/serverless package to swap in. That is a real gap against Neon, and if edge-runtime Postgres is your requirement, Neon's driver is the reason to pick them.

What we have instead is the HTTP query API: POST /v1/databases/:id/query with a Bearer key, a JSON body, and JSON back, which needs nothing but fetch and works from any edge runtime. It covers every cloud engine except TigerBeetle, which speaks a binary protocol. It is not a Postgres driver, so your ORM cannot sit on top of it, and for an edge function issuing a handful of queries that is frequently fine and occasionally a dealbreaker. Redis and Valkey additionally expose an Upstash-compatible REST endpoint, and MySQL and MariaDB expose a PlanetScale-compatible one, so the drop-in-driver story exists on our side for those engines and not for Postgres.

I would rather write that down than have you find it in the middle of a migration.

Picking one

Your Postgres has to answer from an edge runtime. Neon, for the driver. This is the clearest single-factor decision on the list.

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

Keep reading