What is a serverless database and how does it work?

Takeaways

What is a serverless database?

A serverless database separates the database from the servers that run it. The provider owns capacity planning, scaling, patching, failover, and backups. You own the schema and the queries.

Three characteristics define the category:

Managed scaling. Compute and storage grow and shrink with demand. Most modern implementations separate the two layers so they can scale independently, which is what makes scale-to-zero possible.

Usage-based billing. You pay per request, per row read, per capacity unit-second, or per GB stored. You do not pay for a provisioned instance size.

No infrastructure management. No instance types, no read replica provisioning, no manual failover, no operating system patching.

The line between "serverless" and "managed" is blurrier than the marketing suggests. A managed database like Amazon RDS still asks you to pick an instance class and pay for it around the clock. A serverless database removes that decision. The practical test is simple: if you have to choose a size, it is managed. If you have to choose a maximum, it is serverless.

Note that "serverless" is a billing and operations model, not a performance guarantee. It says nothing about where the database runs.

How serverless databases work

Under the hood, most serverless databases share the same architectural move: decouple storage from compute.

Separated storage and compute. Data lives in a durable, replicated storage layer, usually backed by object storage or a distributed log. Compute nodes are stateless processes that attach to that storage on demand. Because compute holds no permanent state, it can be scaled, killed, and restarted freely.

Autoscaling. When request volume rises, the platform adds compute. When it falls, the platform removes it. Amazon's implementation measures capacity in Aurora Capacity Units billed per second, and as of November 2024, Aurora Serverless v2 can scale all the way down to zero ACUs, pausing compute charges entirely while continuing to bill for storage.

Request-based billing. Instead of instance-hours, you are billed on the work performed. Azure Cosmos DB bills in Request Units consumed per operation, with no minimum charge on its serverless account type. Cloudflare D1 bills on rows read and rows written. The unit differs by vendor, but the principle is the same.

Cold starts. Scale-to-zero has a cost. When a paused database receives its first request, it has to resume before it can answer. Resume times range from tens of milliseconds to several seconds depending on the provider and the state of the compute pool. For a background job this is irrelevant. For a user-facing API, it is the difference between a good p99 and a bad one.

Connection handling. Serverless compute and traditional database connections do not get along. Postgres allocates a process per connection, and a function platform that spawns thousands of concurrent invocations will exhaust the connection limit quickly. Serverless Postgres vendors solve this with built-in pooling or an HTTP query interface that avoids long-lived TCP connections altogether. If you are running serverless functions against a Postgres database, pooling is not optional.

Types of serverless databases

The category splits along the same line databases always have.

Serverless SQL databases

Amazon Aurora Serverless v2 runs Postgres-compatible and MySQL-compatible engines with per-second capacity scaling and scale-to-zero. Strong choice for teams already inside AWS. Regional by design.

Neon rebuilt the Postgres storage layer to support instant copy-on-write branching, autoscaling, and true scale-to-zero. The free plan includes 0.5 GB of storage and 100 CU-hours per project, with paid storage at $0.35 per GB-month. Databricks announced its acquisition of Neon in May 2025. Regional, not edge-distributed.

Supabase wraps managed Postgres in a full backend: auth, object storage, realtime subscriptions, and pgvector. The free plan includes a 500 MB database and the Pro plan starts at $25 per month. Single primary region with optional read replicas.

Cloudflare D1 is SQLite running on Cloudflare's network, accessed through Workers bindings. Global read replication, currently in beta, serves reads closer to the user, but every write still routes to a single primary. Each database is capped at 10 GB, a limit Cloudflare states cannot be increased, and is single-threaded, processing queries one at a time.

Turso offers libSQL, an open-contribution SQLite fork, with embedded replicas that place a copy of the database inside your application process. Its free tier covers 100 databases and 5 GB of storage, with paid plans from $4.99 per month.

PlanetScale is worth a correction, because it is frequently miscategorized. It runs MySQL on Vitess and added managed Postgres in 2025, and its schema migration workflow is widely regarded as best-in-class. But it has no free tier and prices by provisioned cluster size, starting at $5 per month for a single Postgres node, with storage and egress metered on top. Resource-based pricing puts it closer to managed than serverless today.

Telnyx SQLDB is a standalone SQLite database that runs on Telnyx Edge Compute rather than in a cloud region. You create it once, bind it by id, and query it as env.DB from any function that binds it, with no connection string and no credentials in your code. It is also reachable from the CLI and a REST endpoint. One primary per database means strong consistency and no replica lag. The published limits are 1 GiB per database and roughly 4 MiB per result set, with a warm simple statement measured at about 10 ms round trip. More on the placement advantage below.

Note what every engine on this list has in common: Postgres or SQLite. SQLite is direct in its own guidance about where its design envelope ends, and the constraints are real: no stored procedures, limited ALTER TABLE support, and a smaller type system than Postgres.

Serverless NoSQL databases

Amazon DynamoDB in on-demand mode is the most widely deployed serverless database in production. Single-digit millisecond reads at any scale, provided you model your access patterns up front. Change your query patterns later and you will be rewriting tables.

Azure Cosmos DB offers a serverless account type billed purely on Request Units and storage, plus multi-model APIs and turnkey global distribution on the provisioned tier.

Fauna belongs in this section as a caution rather than an option. Fauna was the reference serverless NoSQL database for years, and it shut down its service on May 30, 2025, deleting accounts and data after that date. Vendor risk in this category is real, and a proprietary query language makes it worse. Weight portability accordingly.

Benefits of serverless databases

No capacity planning. You set a ceiling instead of a size. Nobody has to forecast peak QPS six months out.

Automatic scaling. Traffic spikes are absorbed by the platform. A launch, a viral post, or a batch job does not require a maintenance window.

Pay for what you use. Bursty and intermittent workloads are dramatically cheaper. A dev database that runs 40 hours a month costs roughly 40 hours, not 730.

Lower operational overhead. Patching, failover, and backup scheduling move to the provider. Small teams get database reliability without a database team.

Faster development cycles. Branching, instant provisioning, and per-preview databases make ephemeral environments practical. It is also why AI coding agents provision serverless databases so heavily: they can be created through an API in seconds and cost nothing when idle.

Why most serverless databases are still centralized

Here is the part the category glosses over.

Serverless solved the cost problem. It did not solve the placement problem. Your database still lives in us-east-1, or eu-central-1, or wherever you clicked at setup time. If your compute runs at the edge and your data does not, every query crosses a continent and back.

That cost is not a vendor limitation. It is physics. Light in fiber travels at roughly two-thirds of its speed in a vacuum, which sets a hard floor on round-trip time between any two points. High Performance Browser Networking works the numbers for a New York to London link: about 56 ms round trip at the theoretical fiber minimum, and closer to 70 ms in practice on real routes. No amount of autoscaling changes that.

Now multiply it. A single request that makes four sequential database round trips from an edge function to a centralized primary spends roughly 280 ms waiting on the network before your code does anything useful. Add a cold start on top and the p99 gets ugly.

Read replicas help, and D1's global read replication is a real improvement for read-heavy applications. But replicas only address reads. Writes go to the primary, and any workload that writes on the request path still pays full freight.

This is why edge functions so often disappoint in production. Teams move compute to the edge, keep the database in one region, and discover the bottleneck simply moved. Compute placement without data placement is a partial solution, and it is the reason stateful edge functions have become the more interesting architectural question.

Telnyx approaches this by treating state as a property of the compute primitive rather than a service you connect to. Telnyx Edge Compute runs functions and Stateful Actors on the same private global network that carries Telnyx voice, messaging, and GPU inference, across sites in North America, Europe, APAC, and MENA on infrastructure Telnyx owns rather than rented CDN capacity.

There are two storage surfaces, and they solve different problems. SQLDB is a shared SQLite database bound to as many functions as need it, for application data an operator also has to query. Per-actor SQL embeds a private SQLite database inside each Stateful Actor, reached synchronously at ctx.storage.sql, so a single entity such as a call leg, a cart, or an agent session owns its own state with the actor instance acting as the lock. Neither surface requires a connection string, because bindings are resolved by the runtime at deploy time.

The tradeoffs are published rather than implied. A SQLDB database holds 1 GiB, is served by one primary, and runs statements one at a time, which is the same single-writer constraint D1 carries. What changes is the distance. Telnyx measures a warm simple statement at about 10 ms round trip and a 5,000-row read at about 160 ms.

The broader point stands regardless of vendor: if your application answers phone calls, runs agents, or processes device events, ask where that traffic lands and whether your data lives there too.

Serverless database comparison

The table below covers the architectural facts that determine performance. Pricing reflects each vendor's published rates as of August 2026 and should be confirmed before you commit.

Engine and data placement

Scaling and billing

Two things stand out. First, only three options in this set place data anywhere other than a single region by default. Second, the billing units are not comparable, which means cost modeling requires your actual query shapes and not a spreadsheet of list prices. If you are evaluating specifically against Cloudflare, we go deeper in our breakdown of Cloudflare D1 alternatives.

Limitations of serverless databases

Cold starts. Scale-to-zero means the first request after idle pays a resume penalty. Providers publish very different numbers here, and most publish none at all. Measure it yourself against your own workload.

Connection limits. Postgres-based options need pooling in front of high-concurrency serverless compute. Pooling adds a hop and, in transaction mode, removes support for session-level features like prepared statements and advisory locks.

Cost unpredictability at sustained load. Usage-based billing wins for bursty traffic and loses for steady traffic. A database at consistent high throughput will often cost more serverless than the equivalent reserved instance. Run the math at your real duty cycle, not your peak.

Vendor lock-in. Proprietary query languages, non-standard connection models, and platform-specific bindings all raise migration cost. Fauna's shutdown is the cautionary case. Engine-compatible options such as Postgres and SQLite are meaningfully easier to leave, since a standard dump moves to any compatible target.

Feature gaps. Scale-to-zero architectures frequently restrict extensions, background workers, custom index types, and long-running transactions. Check your specific dependencies before migrating.

When to choose a serverless database

Choose serverless when:

• Traffic is variable, bursty, or unpredictable
• The workload is intermittent, such as internal tools, batch jobs, or scheduled reporting
• You are building preview environments or per-branch development databases
• The team has no dedicated database operations capacity
• Your application runs at the edge and your data needs to follow it

Choose a traditional managed database when:

• Throughput is high and steady, where reserved capacity is cheaper
• You depend on extensions, custom indexes, or long-running transactions that serverless tiers restrict
• Latency requirements are tight enough that cold starts are disqualifying and your provider cannot guarantee a warm path
• Regulatory requirements demand specific, fixed data residency that your serverless vendor cannot commit to

The decision criteria in order: data placement relative to compute, billing model against your real duty cycle, engine compatibility for exit cost, cold start behavior on your p99 path, and feature coverage for your existing schema.

Serverless database use cases

Stateful edge functions. Session data, feature flags, rate limit counters, and personalization state read on every request. These are exactly the workloads that break when data sits a continent away.

Real-time applications. Collaborative editing, live dashboards, presence, and multiplayer state, where per-entity isolation matters more than a single shared database.

IoT and device telemetry. High-volume, write-heavy ingestion with unpredictable bursts. Usage-based billing fits the traffic shape, and edge placement cuts the ingestion path.

AI inference at the edge. Agents need memory: conversation history, retrieved context, and tool state, loaded on every turn. That is the data-placement problem again, in the workload least able to absorb it, because the fetch sits in front of inference that is already latency sensitive. When state and inference run on the same network, you remove a round trip from a budget that has none to spare.

Multi-region applications. Global user bases where a single primary region means someone always gets the slow experience.

FAQ

Build where your traffic lands

Serverless billing solved the cost problem. It did not solve the latency problem. If your compute runs at the edge and your database runs in one region, you are paying for elasticity you get and speed you do not.