When Scale-to-Zero Actually Saves You Money

Scale-to-zero is one of the headline features of some serverless databases, and the pitch is easy to like. When a database is idle for a set period, its compute stops and so do the associated compute charges. It can be a real cost lever, but how much it helps depends on how your database actually spends its time. Whether it actually pays off comes down to a few things:

• It pays off most when the database is idle long enough to suspend. Development environments, staging, and preview branches spun up per pull request often have long stretches of inactivity. A dev database could be idle for three-quarters of the week, so you stop paying for compute across most of the week.
• On steady production traffic, it often does nothing at all. If queries or persistent connections keep your database from hitting the platform's idle threshold, compute never suspends, so it never reaches zero. A production endpoint that's always busy never goes idle, so there's nothing for scale-to-zero to save.
• Cold starts add latency, not line items. When a database's compute has suspended, and a request or connection arrives, the compute has to wake before it can answer, and that wake adds latency that varies widely by platform and can reach tens of seconds. For a nightly batch job or a CI run, it's likely that nobody notices. For a user-facing request, that's the first real person after an idle window waiting on a page while the compute wakes, or seeing the request fail if the client times out first. Whether cold starts matter comes down to who's waiting on that first query, and whether your timeout and retry logic can absorb the delay.
• Not every platform scales all the way to zero. Both Postgres and MySQL-compatible serverless databases can scale all the way to zero, but whether they do depends on the provider's architecture, configuration, and supported engine version. Some platforms fully suspend compute, while others keep capacity warm and scale down to a low floor, so the cost math and cold-start behavior aren't identical. Either way, the question is the same: how long can compute actually stay suspended, and who pays the latency when it wakes?

So the test is how long your databases can actually stay suspended. Where they sit idle for long stretches and can tolerate a slower first request, scale-to-zero genuinely saves you money. Where traffic keeps them busy, scale-to-zero doesn't activate and there are no savings. And for the in-between case, intermittent but latency-sensitive, the savings tend to be small and rarely worth the cold starts, so keeping compute warm is usually the better call.

Scale-to-zero addresses idle capacity, not repeated work. For an always-on production database, the more useful question isn't how quickly you can turn compute off but how much repeated work can be diverted from the primary database.

🔍 What We're Watching in the Database Ecosystem

How we tracked down a 16-year-old SQLite bug

Tailscale hit 19 database corruption incidents over six months before they and the SQLite maintainers traced it to a data race between checkpointing and write transactions. Alex Chan's read is that aggressive manual checkpointing made them far more likely than most users to hit a bug that had been sitting there for at least 16 years.

The DISTINCT in your COUNT

Exact distinct counts are common in dashboards, but PostgreSQL cannot use partial aggregation when an aggregate contains DISTINCT. In Radim Marek's 10-million-row test, moving deduplication into a GROUP BY subquery restored parallel aggregation and reduced runtime from 1,211ms to 360ms, while avoiding a 115MB sort that spilled to disk.

MySQL July 2026 GA Releases Now Available

MySQL 26.7.0 is the first Innovation release on the new Year.Month.Patch calendar versioning. Two things to plan around: the Thread Pool plugin is now in Community Edition, and the default Group Replication communication stack moves from XCOM to MYSQL, which needs coordinated steps across every member of a group.

In Case You Missed It

Introducing Adaptive Cache for Dynamically Managing Freshness: Not every query needs the same freshness, so Adaptive Cache lets you set how current each cached result has to be, then manages the refresh work to hit that target on its own. It's a way to trade a little staleness for a lot less load where you can afford to, and keep things tight where you can't, without hand-tuning per query.

We're getting more social, catch the latest on Bluesky, X, dev.to, and Medium too.

Know a database aficionado who'd appreciate this? Forward it their way.