What Is a Serverless Database?
The category called "serverless database" currently contains Aurora Serverless, Neon, Cloudflare D1, Upstash, Firestore, and us. Those products do not resemble each other. One is a Postgres cluster inside a VPC that resizes itself, one is a key-value store you talk to over HTTPS, one has no wire protocol at all. When a word has to stretch that far, it is usually describing a promise rather than an architecture, and it helps to know which promise.
Contents
- Where the word came from
- What it is supposed to promise
- What it does not mean
- Two camps: meter the usage, or shrink the idle
- Resume time is the tax you actually pay
- Where Layerbase sits
- When the serverless frame is the wrong one
Where the word came from
"Serverless" arrived with AWS Lambda in 2014 and it meant something specific: you upload a function, you never think about the machine it runs on, and when nothing calls it you are not paying for it. The name was always slightly silly, because there is obviously a server. What it named was the disappearance of the machine from your mental model and from your invoice.
AWS attached the word to a database in 2017 with the first version of Aurora Serverless, and every managed-database vendor since has had to decide whether the label applies to them. Most decided it did.
What it is supposed to promise
Strip the marketing off and the same three properties show up every time.
No capacity to manage. You do not choose "small, medium, or large", you do not read a sizing guide, and you do not schedule downtime to change your mind. A traffic spike is handled by the platform rather than by you at 2am.
Scale to zero. A database nobody is using stops consuming the resources it is not using. This is the property people mean when they say serverless in casual conversation, and it is the one that separates the real thing from a rebrand of an autoscaling group.
Instant resume. Zero has to come back. If waking up means a dashboard button, a support ticket, or a restore, then the database did not scale to zero, it went away. The distance between a two-second reconnect and a manual restore is the difference between a feature and an incident.
Everything else in the pitch (backups, TLS, connection pooling) is table stakes for a managed database and is not particular to serverless at all.
What it does not mean
It does not mean there is no server. Your data is on a disk attached to a machine in a building. Serverless means you are not the one who names it, patches it, or gets paged about it.
It does not mean cheap. This is the one that bites people. Scale to zero cuts the floor of your bill, not the slope. A metered database that costs nothing when idle can cost a great deal when busy, and the amount is a function of query patterns rather than of a plan you chose. Cloudflare D1 bills rows read and rows written, where rows read "measure how many rows a query reads (scans), regardless of the size of each row". That is a reasonable design. It also means a WHERE clause on an unindexed column is now a billing event, and a missing index shows up on the invoice before it shows up in a latency graph.
It does not mean infinitely scalable. Serverless is about who manages capacity, not about how much capacity exists. Every product in the category has a ceiling. The good ones publish it.
It does not mean stateless. The word came from stateless compute, and databases are the opposite of that. Every hard part of serverless databases (cold starts, connection limits, pooling) exists because state has to live somewhere while the compute in front of it comes and goes.
Two camps: meter the usage, or shrink the idle
Under the shared vocabulary there are two genuinely different business models, and picking between them matters more than picking between vendors.
Camp one meters what you use. Neon prices compute in CU-hours, storage per GB-month, and egress per GB, with no minimum. Aurora Serverless v2 sizes itself in Aurora Capacity Units and bills per ACU-hour between a floor and a ceiling you configure. Upstash counts commands. Turso counts rows read. In this camp scale-to-zero is what makes the model fair: if the meter never stops, an idle database is a subscription you forgot about, so the vendor has a strong incentive to make idle genuinely free.
The trade is that your bill is a formula rather than a number. That is fine when your traffic is small and predictable, and it is a real planning problem when it is neither. I walked through what each vendor's meter actually counts in serverless database pricing compared.
Camp two makes idle cheap enough to stop charging for it. Same architecture, opposite conclusion. If a sleeping database holds no RAM and no CPU, then carrying a fleet of mostly-idle databases costs close to storage, and storage is cheap. So instead of metering precisely, you charge a flat monthly price and use scale-to-zero to make that price sustainable. This is where we sit, and it is the only reason a free tier survives contact with a few hundred thousand abandoned side projects. The full economics are in the free tier that stays.
Neither camp is a trick. They are answers to the same cost problem aimed at different customers. Camp one is optimized for workloads whose usage varies by orders of magnitude. Camp two is optimized for people who want to know what August costs in July.
Resume time is the tax you actually pay
Whatever the billing model, scale to zero means something has to start again, and vendors are unevenly forthcoming about what that costs.
The number to ask for is time from first connection to first row, on a cold database, measured rather than estimated. It varies by engine more than by vendor: a key-value store that keeps its dataset in memory and an analytics engine that has to open a large on-disk structure do not resume on the same timescale.
The second question is what happens on a longer absence. Sleeping for an hour and sleeping for a month are frequently different code paths, and the second one may involve releasing your hostname, archiving the volume, or (on some platforms) deleting the database entirely once a documented window elapses. Vendors describe the first path in their product docs and the second one in their terms of service. Read both.
Where Layerbase sits
We are camp two, and the mechanics are worth stating plainly because they are the whole product.
A free database hibernates after 60 idle minutes, a paid one after 6 hours. Hibernation keeps the hostname, the port, and the data volume, so there is nothing to restore: the next connection wakes the database in roughly 1 to 5 seconds and your query then runs normally. No dashboard button, no keep-alive cron job, and running one would only defeat the purpose.
If a free database stays idle for 14 days, it is archived: the address is released and getting it back takes an explicit Restore, which runs in about 10 to 30 seconds. Data and backups survive that, the most recent backup is never pruned, and paid databases are never auto-archived at all. That ladder is the honest cost of a flat price, and I would rather write it down than have you find it in month three.
The pricing is a monthly number with no meter attached to it: no per-query charge and no compute-second charge. What you get on it is 18 engines on Layerbase Cloud, so a Postgres and a cache and a vector store sit in one account rather than three. The current plan numbers live on the pricing page, and the architecture behind them is written up on serverless databases.
When the serverless frame is the wrong one
If your database is busy every minute of every day, scale to zero is worth nothing to you and you should be comparing on price per unit of steady-state capacity instead. A dedicated instance frequently wins that comparison, which is why we sell those too.
If you need sub-millisecond reads from three continents, the constraint is geography rather than capacity management, and no amount of serverless solves it.
And if what you actually want is a database on your laptop that starts instantly and costs nothing because it is on your laptop, that is not a serverless database, that is a local one. The Layerbase CLI runs 21 engines that way with no Docker, and it is frequently the right answer for the first two weeks of a project.
Otherwise, the question to carry into any vendor comparison is short: what does idle cost, how long does waking take, and is the bill a number or a formula. Create a database and time the wake yourself if you want the third answer from us in under a minute.
Keep reading
- Serverless database pricing compared: what each meter actually countsNeon counts compute units. Aurora counts ACU-hours. Cloudflare D1 counts rows scanned. Upstash counts commands. Turso counts rows read. Every serverless database bill is a formula, and the variable is always something your code controls without telling you. Here is each meter, and what a flat price costs instead.
- Every Free Database Tier That Sleeps, Pauses, or Expires - and What Staying Awake Actually CostsA database that scale-to-zeros after five minutes, a project that pauses after a week and needs a human to click Resume, and a database that gets deleted 44 days after you created it are three different products. Here is which vendor does which, and what the cheapest always-on version costs.
- The Free Tier That StaysPlanetScale killed Hobby. Supabase free projects pause weekly. Redis Cloud free is 30 MB. Free tiers die because idle databases cost vendors real money. Ours does not, and that is the whole reason it can stay.
- Your web app became a distributed system and nobody told youYou added an instance, a webhook, a cache, a second server. Each was a normal Tuesday. Somewhere in there your app became several programs that disagree with each other. Here are the four failures that follow, and what each one looks like in your logs.