Most hosted Postgres pricing works like this:
- You pick an instance size
- The vendor assumes the instance will run for about 730 hours a month
- You pay for those hours
That model creates two kinds of compute waste. First, you're provisioning for peak demand, leaving capacity unused the rest of the time; second, the instance keeps "running" even when the database is not busy. That waste is harder to defend now. Compute in the era of agents is getting scarce - leaving it allocated on databases nobody is querying seems like a wasteful way to spend it.
Lakebase Postgres (the Neon database) addresses each compute waste problem separately. Autoscaling solves the first kind of waste by adjusting compute to the current load in real time; the second kind of waste is solved by scale to zero, which suspends compute after a few minutes of inactivity, then restarts it automatically.
The effect this last piece can have, scale to zero, is easy to dismiss if you only picture one busy production database. Your might first think, "my DB is active 24/7 and I wouldn't want it to suspend anyway" - but if you think twice, surely your deployment includes at least some databases that are idle most of the time (development, staging).
Perhaps more interestingly, many modern building patterns ask for thousands of sporadically-used databases. Keeping all of them running would make the architecture too expensive to operate. Scale to zero changes that.
When Postgres scales to zero
You don’t ration dev databases anymore
In a traditional workflow, developers couldn't deploy new instances mindlessly - costs and management accumulated too quickly. That hesitation disappears when your database behaves like an on-demand development resource, the way you open a PR or deploy a preview. Your agent can even do that now.
This is how working with Neon feels. Since branches scale to zero, your agent or CI can create a branch for each test run - every PR can get a preview environment with its own data - every developer on a team can work against a separate branch - every experiment and new idea can live on its branch… The list goes on and on. This is only viable because the compute suspends when the work stops, so these sort of ephemeral branches are extremely affordable.
“Our users were asking for preview environments that already had their data in place. Neon's branching was exactly what we needed: it lets us copy databases very quickly so teams can validate changes end to end immediately”
Marcus Kohlberg, Founder at Encore
Running free plans gets cheap
Scale to zero also changes the free tier economics. If you're running a platform that gives every free user a database, a thousand signups now means ten thousand databases. With an always-on model, every signup added another running instance to your infrastructure bill. With scale to zero, inactive databases stop consuming compute; you still pay for their storage, but the majority of these low-activity databases will have very little to no data on them. Hosting free plans becomes very doable for many platforms.
Our own Neon's Free plan is one proof point for this model. We're currently including 100 projects on it, each with 100 CU-hours of compute per month and 0.5 GB of storage - and yet our free plan is very affordable to run (we're far from having to "subsidize it" in any impactful way). There's many reasons behind this (our infra is very efficient), but scale to zero is the essential piece - a 100 projects do not mean 100 constantly running computes for us.
“Because Neon is usage-based and can scale down databases when they aren't being used, we're able to deploy thousands of new databases per day without costs getting out of hand”
Dominic Whyte, Co-founder at Zite
Coding agents provision backends by the thousands
We all know this by now - coding agents ship infrastructure at a huge rate, and this is only increasing. Your agent will deploy a database for every app it builds, and many branches for development and checkpoints along the way. Scale to zero combined with branching allows for such an intuitive workflow for an agent:
- Create a backend for the app
- Branch it before a risky change
- Restore or discard the branch if the change fails
- Leave inactive database compute suspended without deleting the app's state
“Soon, agents will do most of the coding, and perhaps 1000x more database instances will be needed. Neon's platform and pricing strategy feel aligned with that future”
Nilesh Trivedi, co-founder and CTO at QwikBuild
Your agent won't stop at Postgres
Neon is a now complete set of cloud backend primitives. A single neon.ts file can also declare Managed Better Auth, Object Storage, Functions, and AI Gateway, all with scale to zero built in.
Deploying hosted databases is as routine as creating a repo
Who keeps count on how many repositories they have? That ubiquity is a consequence of GitHub's tech and pricing. A repo costs nothing while nobody touches it, so nobody ever made you justify one. A Postgres instance could feel exactly the same - actually, this is what we're aiming for at Neon. That's why our Free Plan carries 100 projects instead of two, and why we keep raising this limit. This wouldn't be possible without scale to zero.
“I'm always surprised by how easy it is to just create a ton of databases”
Iman Radjavi, Co-founder at Specific
“Once we automated the setup, Neon just became part of how we ship”
Gabriel Tumlos, Founder of Daisy
Vector search stops requiring an always-on database
For years, search mostly meant a search bar: a human typing a query, with load you could forecast and QPS you could plan around. That's changing. Search is increasingly a tool exposed in an agent harness, one way to connect data to agents. Teams index more data than they used to, and those indexes may sit idle between agent calls.
The default Postgres setup for vector search is pgvector with an HNSW index, and this is designed for a traditional server - it's a long-lived process that keeps the whole graph pinned in RAM between queries. Every search walks that graph through many small random reads. Lakebase Search lets you invert the design and take advantage of scale to zero even when running semantic search.
Read this blog post for the full picture on how this works - but the TL;DR is that Lakebase search keeps their indexes durable on object storage instead of in compute memory, and the index keeps existing when the compute shuts down. The compute on top is a cache that rebuilds from object storage on demand, so a search database can suspend and wake without re-indexing anything.
“Using Lakebase Search, we clocked around 18.6ms warm, versus around 19.5 seconds on our old cold-start GIN approach. That's a 1,000x improvement”
Srijit Ghosh, Co-founder and CTO at CommSync
Realtime becomes an option for every database (coming soon)
Sync and scale to zero have always been hard to combine. A Postgres sync engine typically follows the logical replication stream, which holds a replication connection open and keeps compute active. Electric joined the Neon team at Databricks, and we're building sync on Neon in a way that doesn't hold the logical replication connection open and so doesn't prevent scale to zero. More soon.
Scale to zero is not for prod, but there's still waste there. That's why autoscaling exists
The patterns above rely on databases that spend meaningful time doing nothing. A production branch serving requests 24/7 has the opposite shape - its compute is always active, but its demand changes throughout the day.
For that workload, turn scale to zero off. The waste comes from something else: provisioning for the peak. Neon also solves for that - autoscaling adjusts compute between a minimum and maximum you set, based on live load, without restarts. You size the range for the workload instead of keeping peak capacity allocated all day. Compute usage then follows the average resources consumed over the hours the database is running.
Get the deep dive
This blog post walks you through how our autoscaling works in detail.
Stop wasting compute. Let it scale to zero
Scale to zero looks like a minor feature if you just picture a busy production branch, but its actually one of Neon's most impactful capabilities. It shines everywhere else but prod - development, staging, all the test DBs your agent deploys - and it enables architectures that deploy databases en masse, which are only getting more popular in the era of agents.
Compute is becoming an increasingly sought-after resource. Scale to zero simply makes sense: if a database isn't doing work, its compute shouldn't be sitting there. Try it on the Neon Free plan, or ask your coding agent to add it to the next app it builds.
