A practitioner's guide to choosing between serverless and provisioned databases based on cost, latency, connections, and load shape.
Pick the wrong database model and you either overpay for idle capacity or get paged at 2am because a cold start blew your latency budget. The serverless-versus-traditional question is not about which technology is newer. It is about matching the billing and scaling model to how your workload actually behaves.
Traditional (provisioned): You choose an instance size, say a db.r6g.xlarge running Postgres on RDS, or a self-managed Postgres box, and you pay for it 24/7 whether it serves one query or ten thousand. You size for peak, you patch it, and you plan capacity ahead of growth.
Serverless: Compute scales with demand and often scales to zero when idle. You are billed per use, roughly by compute-seconds and storage. Neon, Aurora Serverless v2, and PlanetScale all fit here. Nobody hands you an instance size to guess at; the platform allocates and releases capacity for you.
The storage layer is usually decoupled from compute in serverless offerings, which is what makes scale-to-zero and fast branching possible. That decoupling is also the source of the tradeoffs below.
This is the big one, and it is where most bad decisions get made. Serverless wins when load is bursty or spiky, and when a resource sits idle a lot. Provisioned wins when load is steady and high, especially with a reserved or committed-use discount.
Walk the math on a dev database. Say it is queried during working hours only, roughly 40 hours a week out of 168. A small provisioned instance at $60/month bills the full month regardless. A serverless equivalent that scales to zero overnight and on weekends might run compute for 40 hours and bill closer to $12. That is a 5x gap, and it comes entirely from not paying for idle.
Now flip it. A production OLTP database pinned near 70% CPU around the clock is the opposite case. Serverless per-second pricing on continuously active compute usually lands above the equivalent provisioned instance, and once you add a one- or three-year reservation the provisioned box can be 40-60% cheaper. Constant high utilization is where serverless stops saving money.
It is not. Serverless is cheaper at low or uneven utilization. The pricing model trades a low floor for a higher per-unit rate. If your utilization curve is flat and high, you are paying that premium every second with nothing to reclaim. Reserved provisioned capacity is often the cheaper answer for steady heavy load. Run your own numbers against your utilization curve before you assume otherwise.
Provisioned instances are always warm. The first query of the day is as fast as the last. Serverless that scales to zero pays a cold start when traffic resumes, and that can be anywhere from tens of milliseconds to a few seconds depending on the platform. For a background job that is noise. For a user-facing request on the critical path, a two-second cold start is a bad first impression. Some platforms let you keep a minimum capacity warm, which softens this but also erodes the scale-to-zero savings.
Postgres connections are expensive, and this bites serverless architectures hard. A classic provisioned setup uses a fixed connection pool sized to the instance. But serverless application tiers, think Lambda or edge functions, can spin up hundreds of concurrent instances, each wanting its own connection, and blow past Postgres limits fast.
Serverless database platforms answer this with a built-in pooler and an HTTP or WebSocket driver so functions can query over a stateless connection instead of holding a raw TCP socket. If you go serverless on the compute tier, route through the pooled endpoint, not the direct one. If you are on a traditional stack with long-lived app servers, a normal pool is simpler and works fine.
Serverless removes capacity planning, patching, and most scaling decisions. There is no instance to right-size, no maintenance window to schedule, no failover to wire up yourself. For a small team without a dedicated DBA, that reclaimed time is often worth more than the raw compute bill. Provisioned gives you more knobs, which is exactly what you want when you have someone whose job is to turn them.
Provisioned instances have a hard ceiling: the biggest box you can rent. Serverless scales more elastically but can hit platform limits on connections, per-query resources, or extension support. Check feature parity too. Some serverless Postgres offerings lag on specific extensions, logical replication, or strict consistency guarantees. If you depend on a particular extension or a specific isolation level, verify it before you commit.
- Startup MVP with spiky traffic: Serverless. You cannot forecast load, and scale-to-zero means your idle nights cost almost nothing.
- Dev, staging, and preview environments: Serverless, every time. These sit idle most of the day and scale-to-zero plus instant branching is a genuine productivity win.
- Steady high-throughput OLTP: Provisioned, ideally reserved. Constant load is where the flat-rate box beats per-second billing.
- Latency-critical, tight tail budget: Provisioned kept warm, or an edge-distributed database. You cannot afford a cold start on the critical path.
- Is your load bursty, or steady and high? Bursty leans serverless; steady-high leans provisioned.
- What fraction of the day is the database actually idle? High idle strongly favors scale-to-zero.
- Can your latency budget absorb an occasional cold start?
- Is your app tier serverless too? If so, you need pooling regardless of the database choice.
- Do you have someone to own capacity planning and patching? If not, serverless buys that back.
- Do you depend on a specific extension, replication mode, or consistency guarantee? Verify support first.
- Have you priced provisioned with a reservation against serverless at your real utilization?
Default to serverless for anything with uneven or unpredictable load, and for all non-production environments. The scale-to-zero savings and the removed operational burden are real, and most workloads are spikier than their owners think. Move to provisioned, with a reservation, once a production workload settles into steady high utilization and the per-second premium starts to cost more than a right-sized reserved instance. For latency-critical paths, stay warm or go to the edge.
Whatever you pick, decide it against your actual utilization curve rather than a headline price. For the wider landscape, see our serverless and edge databases guide, and if you have already decided on serverless, compare the options in best serverless databases.
