What Makes a Database Serverless?

The label serverless database appears on products with very different architectures.

Some suspend compute when idle. Some expose an HTTP API. Some scale storage automatically. Others are managed databases with excellent connection pooling.

So the useful question is not, “Is this product truly serverless?”

It is: which operational problems does this database remove, and which trade-offs remain yours?

Managed does not automatically mean serverless

A managed database provider can provision hardware, install the database, apply patches, create backups, and replace failed machines.

That removes substantial operational work. But the database may still run on a fixed instance size that you select and pay for continuously.

A serverless database usually goes further. It adapts some resources to demand and exposes a usage-oriented operating model.

There is no universal checklist, but common properties include:

Automatic capacity changes
Independent compute and storage scaling
Suspension or scale-to-zero behavior
Fast provisioning
Connection handling for bursty clients
Usage-based billing for at least some resources

A product can provide some of these without providing all of them.

Treat managed and serverless as overlapping descriptions, not synonyms.

Scaling compute independently

Database load is not constant. A development database may be quiet all night, while a production database may receive a sudden burst after a product launch.

In a fixed deployment, you choose enough CPU and memory for expected peak load. The unused capacity still exists during quiet periods.

A serverless design can change database compute as demand changes. Some systems resize an active compute. Others add read capacity or route work across a distributed data layer.

This elasticity is harder than scaling stateless functions.

A function instance can disappear after a request because durable state lives elsewhere. A database compute must preserve transactions, coordinate concurrent writes, and recover its working data safely.

That is why “autoscaling” needs precise questions:

What resource scales: CPU, memory, replicas, shards, or all four?
Does scaling interrupt connections?
How quickly does it react?
Is there a configured minimum and maximum?
Does the write path scale differently from reads?

The word alone does not describe the behavior your application will experience.

Separating compute from storage

On a traditional database server, the database process and its files often live close together.

The CPU executes queries. Memory caches frequently used pages. Local or attached storage holds the database files and write-ahead log.

This coupling is simple and fast, but capacity choices become linked. Replacing compute may involve moving storage, while adding storage may require resizing the whole machine.

A separated architecture gives query processing and durable storage different lifecycles.

Compute can start, stop, or resize without becoming the only durable owner of the data. Storage can grow independently and survive the replacement of a compute node.

A coupled database compared with an architecture that separates compute and durable storage.

Neon is a concrete example. Postgres runs in compute endpoints, while a separate storage system preserves database pages and write-ahead log data.

The compute still uses local memory and storage as a cache. When data is missing locally, it retrieves the required pages from the storage layer.

This design enables independent scaling and replacement. It also creates a cache-warming problem: a newly started compute may need to fetch pages before its working set becomes hot.

Separation is therefore not “remote storage with no consequences.” It exchanges tight coupling for elasticity, durability options, and new network paths.

Scaling to zero and waking up

If durable data does not depend on one running compute, the platform can suspend compute after inactivity.

Storage remains. The active query processor goes away.

When a new query arrives, the platform starts or resumes compute and reconnects it to the stored data. The application sees extra latency while that happens.

This is the database equivalent of a cold start.

Scale to zero is valuable for preview environments, development projects, tenant databases, and applications with long idle periods.

It may be a poor fit for latency-sensitive workloads that must respond consistently at all hours. Some providers let you keep a minimum compute active for that reason.

Do not ask only whether a database scales to zero. Ask:

How long before it suspends?
What wakes it?
How long does wake-up usually take?
What happens to existing connections?
Can production workloads disable suspension?

Those answers determine whether the feature helps your workload.

HTTP, WebSocket, and TCP access

Postgres and MySQL clients traditionally use long-lived connections over TCP. That works naturally in a persistent application server.

Short-lived and highly concurrent functions can create too many connections. Some runtimes also limit which networking APIs are available.

Database providers address this with connection poolers, proxies, and drivers that carry queries over HTTP or WebSockets.

HTTP is useful for one-shot queries and non-interactive transactions. WebSockets can support a longer conversation when session-like behavior or interactive transactions are required.

TCP remains entirely valid where the runtime supports it. Cloudflare Workers, for example, provides outbound TCP sockets, so “edge code cannot use TCP” is no longer a universal rule.

The protocol is only the application-facing path. Behind an HTTP endpoint, the provider still has to route queries, manage database connections, and preserve database semantics.

An HTTP driver does not by itself make the underlying database serverless. It makes the database easier to reach from serverless runtimes.

Data locality still controls latency

Moving compute near every user does not move a single-region database near every user.

If a function in Mumbai queries a database in Virginia, every dependent query crosses that distance. Three sequential queries can pay the network round trip three times.

Connection setup optimizations help, but they cannot remove the propagation time required by an uncached query.

You can respond by:

Running application compute near the primary database
Reducing sequential database round trips
Using read replicas where stale reads are acceptable
Caching safe read results near users
Choosing a distributed database when the domain requires it

“Edge database” can also mean several things: an API available from edge compute, read copies near users, or a genuinely distributed storage and coordination model.

Always identify where reads execute, where writes commit, and what consistency the system promises.

Provider examples as implementation patterns

The products below illustrate different answers. They should not be treated as interchangeable members of one architecture.

Neon: separated Postgres compute and storage

Neon separates Postgres compute from its storage layer. Compute can autoscale and suspend when idle, while durable data remains in storage.

Its JavaScript driver supports HTTP for one-shot operations and WebSockets for connection-oriented use cases.

This pattern is useful when you want Postgres semantics with elastic compute and short-lived application clients.

Supabase: managed Postgres with serverless-friendly access

Each Supabase project includes a full Postgres database plus services around it.

Supabase offers a Data API and Supavisor connection pooling. Its transaction-pooler mode is designed for temporary clients such as serverless and edge functions.

This is an important distinction: serverless-friendly connectivity can be added around a more conventional managed database.

PlanetScale: managed relational platforms and HTTP drivers

PlanetScale offers managed Vitess and Postgres products with different architectures.

Its Vitess JavaScript driver sends queries over HTTP. PlanetScale Postgres can also be reached from serverless environments through HTTP or WebSocket driver modes.

The access method improves compatibility with short-lived runtimes. It does not mean every PlanetScale product scales to zero or separates compute and storage in the same way as Neon.

Cloudflare D1: a database integrated with Workers

D1 is Cloudflare's managed serverless database with SQLite semantics. Workers access it through a binding, and an HTTP API is also available.

It is useful when tight integration with the Workers platform and SQLite's model fit the application.

That does not make D1 a drop-in replacement for every Postgres or MySQL workload. SQL dialect, limits, consistency, data model, and migration needs still matter.

Hyperdrive: a bridge to an existing database

Hyperdrive is not a new database engine. It sits between Workers and an existing Postgres or MySQL database.

It performs connection setup near the Worker, pools connections near the origin database, and can cache eligible read queries.

This pattern lets global compute use a centralized database more efficiently without first replacing that database.

Database connection strategies available to short-lived serverless functions.

A practical selection checklist

Start with database correctness, not the serverless label.

Model: Do you need Postgres, MySQL, SQLite, or another data model?
Consistency: Which reads may be stale, and where must writes commit?
Transactions: Do you need interactive transactions or session state?
Location: Where are users, application compute, and primary data?
Traffic: Is load steady, bursty, seasonal, or mostly idle?
Connections: Will clients be persistent processes or short-lived functions?
Recovery: What backup, restore, and point-in-time recovery guarantees exist?
Portability: Which proprietary APIs would be difficult to replace?
Limits: What are the caps on storage, queries, connections, and execution time?
Cost: What happens at idle, normal load, and peak load?

The best choice may be an elastic database, a managed fixed-size database with a pooler, or a traditional database operated by your team.

Serverless is an operating model. It does not override the workload.

Key takeaways

Managed and serverless describe different properties.
Serverless databases commonly automate capacity, connectivity, and lifecycle management.
Separating compute from storage can make independent scaling and suspension possible.
Scale to zero saves idle compute but introduces wake-up latency.
HTTP and WebSocket drivers help short-lived runtimes, but they are not proof of a serverless architecture.
Data locality and sequential queries still determine much of application latency.
Vendor products represent different patterns, so compare guarantees rather than labels.

What comes next

The database is only one half of a data-driven web application.

The next article moves up the stack and asks how Next.js decides which UI work can happen ahead of time, which results can be cached, and which components must wait for a request.