What Giving Every AI Agent Its Own Database Branch Costs

Methodology: every rate below comes from Neon's and Xata's own pricing pages, read directly rather than from a comparison site. The cost model that follows states its assumptions in each row, so you can swap in your own numbers.

Bottom line, up front: Neon bills $1.50 per branch-month past your plan's included count, on top of compute and storage. Xata charges nothing per branch. It bills only for the compute and storage a branch actually uses. At agent-fleet volume, that difference is the entire story.

Key Takeaways

• Neon's Launch and Scale plans include 10 and 25 branches respectively. Every branch past that costs $1.50 per branch-month, prorated hourly, on top of $0.106/CU-hour (Launch) or $0.222/CU-hour (Scale) compute and $0.35/GB-month storage.
• Xata charges no per-branch fee on its managed Cloud plan. You pay only for the compute (from $0.012/hr) and storage ($0.28/GB-month) a branch actually consumes, with no stated cap on branch count.
• At fleet scale, compute rate is the bigger lever than the branch fee. Neon's Launch compute rate runs roughly 9x Xata's micro-instance rate, and that gap compounds across every branch created.

Why this question exists now

Database branching means giving each AI agent, or each agent task, its own isolated copy-on-write database branch to work in. An agent that writes bad data, runs a destructive migration, or just needs a scratch copy stays contained to its own branch. It never touches the shared database. This is also the most common fix proposed for a real, documented problem: AI agents that have run destructive commands against production because nothing isolated them first, including a widely reported incident where a Cursor agent wiped a production database in nine seconds.

Neon and Xata are the two Postgres providers pushing this pattern hardest for agents. They price it in genuinely different ways. Neither vendor publishes a worked example at agent-fleet scale. So we built one.

The two pricing models, read from the source

Neon: included branches, then a flat per-branch fee

Neon's current pricing page lists three plans. Free includes 10 branches per project, with no option to add more. An 11th branch creation is blocked outright. Launch and Scale, Neon's paid tiers, both allow up to 5,000 branches per project. But only the first 10 (Launch) or 25 (Scale) are included in the base price. Every branch beyond that costs $1.50 per branch-month, billed hourly. That fee applies regardless of how much compute or storage the branch actually uses.

Compute is billed separately, at $0.106/CU-hour on Launch and $0.222/CU-hour on Scale, per Neon's rate card. Storage is $0.35/GB-month on both paid plans. A branch that creates no new data and runs for ten minutes still accrues a slice of that $1.50 monthly fee. That's on top of whatever compute-seconds it used.

Xata: no per-branch fee, pay for what a branch uses

Xata's own published rate card prices its managed Cloud plan on compute and storage only. Compute starts at $0.012/hour for a micro instance (1GB RAM, up to 2 vCPU), per Xata's instance pricing table. It scales up to $1.536/hour for a 32-vCPU, 128GB-RAM instance. Storage is $0.28/GB/month, billed by the minute. The pricing page states you can "create as many [branches] as you need," with no per-branch charge and no stated branch cap on this plan.

Here's the practical difference, confirmed against Xata's own branching comparison. On Xata, a branch that exists for ten minutes and writes almost no new data costs close to nothing — there is no fixed per-branch fee to amortize. On Neon, that same short-lived branch always carries a slice of the $1.50/month charge, however briefly it lived.

The cost model

Three scenarios, same assumptions stated per row: each branch runs for 2 hours of active compute at the smallest reasonable instance size, writes negligible new storage (under 100MB), and the fleet runs these branches every day for a 30-day month.

Scenario	Branches/day	Neon monthly estimate	Xata monthly estimate
Small team, agent code review	10	Compute: 10 × 2hr × 30 × $0.106 ≈ $63.60. Branches: all 10 fit inside Launch's included count → $0 branch fee. Total ≈ $64	Compute: 10 × 2hr × 30 × $0.012 ≈ $7.20. No branch fee. Total ≈ $7
Mid-size fleet, CI-per-PR branches	100	Compute: 100 × 2hr × 30 × $0.106 ≈ $636. Branches: 90 over the included 10, each live ~2hrs/day ≈ 0.083 branch-months × $1.50 × 90 ≈ $11. Total ≈ $647	Compute: 100 × 2hr × 30 × $0.012 ≈ $72. No branch fee. Total ≈ $72
Large fleet, per-task agent branches	1,000	Compute: 1,000 × 2hr × 30 × $0.106 ≈ $6,360. Branches: 975 over the included 25 × 0.083 branch-months × $1.50 ≈ $121. Total ≈ $6,481	Compute: 1,000 × 2hr × 30 × $0.012 ≈ $720. No branch fee. Total ≈ $720

The branch fee itself stays a modest fraction of the bill in every scenario here. These branches live for only 2 hours a day, and the fee is prorated hourly, so short-lived branches barely accrue it. Compute rate is what actually separates the two vendors in this model. Neon's $0.106/CU-hour Launch rate is roughly 9x Xata's $0.012/hour micro-instance rate. That gap compounds across every branch at fleet scale.

This is not a claim that Neon is categorically more expensive. Xata's $0.012/hour micro instance (1GB RAM) is a smaller, cheaper tier than Neon's smallest Launch compute unit. So the comparison above is partly an artifact of instance sizing, not pure per-branch economics. Run this model with your own expected instance size on each platform, before trusting either vendor's marketing claim that branching is "cheap" at your volume.

What actually drives the bill at agent-fleet scale

Compute rate and instance sizing, not the per-branch fee, dominate the total in every scenario modeled here. The $1.50 Neon branch fee only matters at high branch counts with long-lived branches. A fleet creating thousands of branches that each live for days, not hours, would see that fee become a much larger share of the bill. If your agents spin up a branch and tear it down within minutes, the per-branch fee is close to irrelevant. If your agents keep branches alive for extended debugging or long-running tasks, model that specifically before committing to either platform.

Storage is the line item most worth watching separately. Consider, for example, a branch created from a 50GB production snapshot versus one that copies almost nothing. Both vendors' storage rates ($0.35/GB-month Neon, $0.28/GB-month Xata) are close enough that they rarely decide the outcome on their own. But consider a branch that copies a large production database wholesale, instead of relying on copy-on-write to skip unchanged data. That can turn a cheap-looking branching strategy into an expensive one, regardless of vendor.

FAQ

Does Neon charge per database branch?

Yes, past the included count. Neon's Free plan includes 10 branches per project, with no option to exceed that limit. The paid Launch and Scale plans include 10 and 25 branches respectively. Every additional branch costs $1.50 per branch-month, prorated hourly, separate from compute and storage charges.

Does Xata charge per database branch?

No. Xata's managed Cloud pricing has no per-branch fee. You pay only for the compute and storage a branch consumes. The pricing page states there is no cap on how many branches you can create on this plan.

Is Neon or Xata cheaper for AI agents that create many database branches?

It depends mainly on compute rate and branch lifetime, not the branch fee itself. In a model where 1,000 branches a day each run 2 hours of small-instance compute, Neon's Launch-plan compute rate ($0.106/CU-hour) produces a materially higher bill than Xata's micro-instance rate ($0.012/hour). That rate difference compounds across every branch. Neon's $1.50 per-branch fee adds only a small amount on top, for short-lived branches.

What is database branching and why do AI agents use it?

Database branching gives each agent, or each agent task, an isolated copy-on-write copy of a database to work in. A destructive query or bad migration then stays contained to that branch, instead of touching the shared or production database. It has become a common mitigation after multiple reported incidents of AI agents running destructive commands against production data, with no isolation in place.