Add this to your agent's context
Give your agent the context it needs to understand Xata's scale-to-zero compute.
Traditional databases charge for provisioned compute 24/7, whether queries are running or not. Xata charges for actual usage. Every Postgres branch can independently scale its compute to zero when idle and restart automatically when a new connection arrives.
How scale-to-zero works
The lifecycle of a Xata branch follows four states. Understanding this cycle is key to understanding why scale-to-zero makes thousands of branches economically viable.
1. Branch created
A full Postgres instance spins up with copy-on-write storage. Ready to serve queries immediately. The branch has its own compute, its own connection string, and complete isolation from every other branch.
2. Queries stop
After a configurable idle period with no active connections, the compute process shuts down. Storage persists — data is not lost. The branch transitions from "active" to "idle" automatically with no manual intervention.
3. Idle at $0 compute
The branch exists in storage only. No CPU, no memory allocation, no cost. It can stay idle indefinitely. There is no time limit on how long a branch can remain scaled to zero.
4. Query arrives
A new connection triggers compute to spin back up. The branch resumes from persisted storage with all data intact. Cold start takes a few seconds, then the branch is fully operational again.
The economics of scale-to-zero
Pay only for active queries
Most branches in a development workflow sit idle 95%+ of the time. Scale-to-zero means you pay for the 5% that matters. A branch that runs tests for 3 minutes then sits idle for the rest of the day costs 3 minutes of compute, not 24 hours.
8,000 branches, near-zero cost
Run thousands of branches concurrently. Only a handful are active at any moment. The rest cost nothing in compute. This is what makes per-PR, per-agent, and per-engineer branches economically viable. The inactive majority subsidizes nothing.
Storage is shared via CoW
Branches share the source database's storage via copy-on-write. You pay for the base storage plus deltas, typically 60-90% less than full copies. Combined with zero-cost idle compute, the marginal cost of an additional branch approaches zero.
Where scale-to-zero matters most
Dev branches per engineer
Every engineer gets their own branch. Most sit idle between coding sessions. Compute runs only during active development. No shared state, no conflicts, no cost for the 90% of the day the branch is not in use.
CI/CD preview environments
Spin up a branch per pull request. Tests run, branch goes idle. Merge or close the PR, destroy the branch. The total cost is seconds of compute per test run, not hours of provisioned capacity waiting for the next push.
Agent sandboxes
AI agents get isolated databases for each execution. Branches spin up, agents run their queries and mutations, branches scale to zero. Per-agent-run cost approaches $0. This is what makes it practical to give every agent session its own database.
How it compares
| Xata | Neon | Traditional | |
|---|---|---|---|
| Idle compute cost | $0 | $0 (with cold start) | Full instance price |
| Cold start time | A few seconds | ~500ms-2s | N/A (always on) |
| Storage during idle | CoW shared storage | Neon storage | Full copy per instance |
| Per-branch pricing | No per-branch fees | Per-compute-hour | Per instance |
| BYOC deployment | Yes | No | Yes (self-managed) |
For a detailed breakdown of how Xata compares to Neon across branching, storage, and pricing, see the full Neon comparison.