What Does “Scale to Zero” Mean in YugabyteDB AMP?

Jim Knicely

While manning the YugabyteDB display booth at the Postgres Summit in New York City this week, someone stopped by and asked a simple but great question:

  • “What exactly does scale to zero mean?”

I gave them an explanation, but it occurred to me that others may have the same question. “Scale to zero” is one of those serverless terms that gets used frequently, but its meaning, and why it matters for agentic workloads, may not be immediately obvious.

So, naturally, I figured it deserved its own YugabyteDB Tip! 😃

Serverless databases often promise the ability to “scale to zero.” But what exactly does that mean?

With YugabyteDB AMP (Agentic Multitenant Postgres), scale to zero is designed for a workload pattern that is becoming increasingly common with AI agents: lots of databases, but only a fraction of them actively doing work at any given moment.

An agent might wake up, perform some work against its PostgreSQL database, and then remain idle for minutes, hours, or even days.

Traditional database infrastructure can still consume provisioned compute capacity while that database is idle.

With scale-to-zero economics, the model is different:

💡 The basic idea
When an agent’s database is idle, its compute consumption can effectively drop to zero. The database and its persistent data still exist… you’re not deleting or recreating the database.
When the agent becomes active again, compute resources are automatically made available to service its workload.

Think About the Agent Workload

Imagine an application with 1,000 AI agents, with each agent having its own PostgreSQL database.

At any particular moment, perhaps only 25 agents are actually doing something.

A traditional deployment model can look conceptually like this:

🗄️
1,000 Agent Databases
↓
⚙️
Compute Capacity Provisioned
Resources are allocated for the databases
↓
💤
Most Agents Are Idle
↓
⚠️
Resources Are Still Allocated
Idle databases can still consume provisioned capacity

A scale-to-zero serverless model changes the equation:

🗄️
1,000 Agent Databases
↓
🤖
25 Agents Currently Active
Only a small portion of the agents are doing work
↓
⚡
Compute Consumed by Active Workloads
Compute follows actual activity
↓
✓
Idle Agents Consume No Active Database Compute
Persistent databases remain available while idle compute scales to zero

The important distinction is:

💡 Scale to zero does not mean your data scales to zero.
It means idle compute can scale to zero.

Your database still exists. Your schema still exists. Your tables and data are still persistent.

What disappears when the workload becomes idle is the need to keep compute active just in case that particular agent decides to do something.

Why This Matters for AI Agents

AI agents tend to be bursty.

An agent may wake up, retrieve some context, perform a task, store the results, and then become idle again.

Here’s what that lifecycle might look like:

🤖
Agent Wakes Up
↓
📖
Read Some Context
↓
⚙️
Execute a Task
↓
✍️
Write Results
↓
💤
Go Idle
Compute consumption can effectively drop to zero

The agent doesn’t necessarily need database compute continuously between those periods of activity.

Multiply that behavior across hundreds or thousands of agents and permanently provisioning compute for every agent becomes inefficient.

This is where the combination of serverless multitenancy and scale-to-zero economics becomes particularly interesting.

But Does Every Agent Still Get a Real PostgreSQL Database?

Yes… and that’s an important part of the architecture.

The goal isn’t to put every agent’s tables into one enormous shared PostgreSQL database and require the application to implement tenant isolation itself.

Instead, each agent can have its own PostgreSQL database, while the underlying YugabyteDB infrastructure is shared efficiently.

Conceptually:

🤖 Agent A
→
🐘 PostgreSQL Database A
🤖 Agent B
→
🐘 PostgreSQL Database B
🤖 Agent C
→
🐘 PostgreSQL Database C
•••
🤖 Agent N
→
🐘 PostgreSQL Database N
↓
🌐
Shared YugabyteDB Infrastructure
Many isolated PostgreSQL databases efficiently share the underlying distributed infrastructure

That gives the application a useful combination:

  • database-per-agent isolation without requiring dedicated infrastructure per agent.

How Does AMP Make This Practical?

This model becomes especially powerful when combined with Enhanced Colocation and Serverless Multitenancy.

Instead of treating every small agent database as if it requires its own dedicated set of infrastructure, YugabyteDB can efficiently consolidate large numbers of small databases onto shared distributed infrastructure.

That means an application can maintain database-level separation between agents while avoiding the infrastructure overhead traditionally associated with running hundreds or thousands of individual databases.

💡 Database-per-agent without infrastructure-per-agent
Each agent can have its own PostgreSQL database while YugabyteDB efficiently shares the underlying distributed infrastructure across those databases.
Combine that with scale-to-zero economics and idle agents don’t need to continuously consume active database compute.

Scale to Zero Does Not Mean “Delete the Database”

This distinction is worth emphasizing because the phrase scale to zero can sound more dramatic than it actually is.

⚠️ Don’t confuse scale to zero with shutting down or deleting the database
The database isn’t dropped when the agent becomes idle, and its persistent data doesn’t disappear.
Think of scale to zero as eliminating idle compute consumption while preserving the database state needed when the agent becomes active again.

The next time the agent needs its database, compute resources can be made available again and the agent continues working with the same persistent database state.

Final Takeaway

For agentic applications, the interesting part of scale to zero isn’t simply that a database can become idle.

It’s the economics of doing that across potentially huge numbers of independent agent databases.

🚀 The takeaway
1,000 agent databases do not necessarily mean 1,000 databases continuously consuming compute.
With YugabyteDB AMP, agents can retain their own persistent PostgreSQL databases while idle workloads can effectively consume no active database compute, and automatically regain compute when they become active again.

That’s the idea behind scale to zero: keep the database and the data, but don’t keep paying for idle compute.

Have Fun!

YugabyteDB is proud to be a Gold Sponsor! 🏆
Come meet the team, see what we’ve been showcasing at the conference, and chat with us about distributed PostgreSQL, scalability, resilience, and all things YugabyteDB.

👉 Today, Oct. 2, 2026, is the final day of Postgres Summit US 2026 in NYC – be sure to stop by the YugabyteDB display before it’s too late! 😄