Introduction
In Part 1 we dissected how each platform branches a Postgres database under the hood. This post zooms in on pricing. We’ll explore how Xata, Neon, and Supabase pricing strategies stack up when you require:
- CI preview databases for a five engineer team
- HA deployment with two read replicas + always-on staging
- Per-tenant isolation for SaaS offerings
- Data-science sandboxes for model training
- Autonomous agents with high branch churn
Pricing
One of the first questions any team asks when evaluating platforms that are critical to their infrastructure is “how much is this actually going to cost us?” Since each service has a different pricing model, this won't be an exact apples-to-apples comparison. I’ll break down the pricing for Xata, Neon, and Supabase, then provide some scenario-based comparisons to illustrate the differences.
Neon vs. Supabase vs. Xata
Focusing on branching, here’s a quick breakdown of the pricing plans.
Pay-as-you-go | Unlimited branches, pay for vCPU-hrs & GB-months only | Example: xata.small (2 vCPU / 2 GB) → $0.024 hr xata.xlarge (4 vCPU / 16 GB) → $0.192 hr | Storage $0.30 GB / mo |
Launch $19 / mo | Launch: 300 CPU-hrs & 10 GB | Compute charged in CPU-hrs | CPU overage $0.16 per CPU-hr |
Pro $25 / mo | $10 compute credit | Add-on instances: | Instance add-ons charged by the month |
Xata
We aimed for simple, transparent pricing. Xata’s pay-as-you-go model charges for compute instance hours and storage GB months, period. There are predefined instance sizes with a certain vCPU and RAM combination and an hourly rate for each. For example, a small dev instance (2 vCPUs, 2 GB RAM) is $0.024 per hour (~$18/month if running 24/7). Storage is $0.30 per GB per month, charged only on actual data usage since we don’t pre-allocate disk. All the additional features are included at no extra cost. We don’t charge separately for number of branches or anything like that. You can create unlimited branches and you’ll just pay for the storage difference they incur and any compute hours if those branches are spun up and running.
Neon
Neon uses a tiered plan model with a mix of free quotas and pay-as-you-go for overages. For instance, Neon’s Launch plan is $19/month which includes 300 hours of compute and 10 GB of storage. The Scale plan is $69/month and includes 750 compute hours and 50 GB storage. If you exceed the included hours or storage, you pay overage fees. Neon measures compute in “compute hours” which are basically CPU-hours; e.g., running a 2 CPU instance for 1 hour consumes 2 compute hours. Overage compute hours are billed at $0.16 per CPU-hour beyond the included amount. Storage overages are around $1.50–$1.75 per GB-month depending on tier.
Supabase
Supabase’s pricing has two components: the base plan fee and usage add-ons. Their Pro plan is $25/month base, which includes certain limits (like 8 GB database space, 100GB file storage, etc.) and importantly includes $10 of compute credits. Those credits cover a certain amount of database instance time. Supabase essentially offers fixed-size instance add-ons: a micro instance (roughly 2 CPU, 1GB RAM on ARM) costs $10/month, Small is $15, Medium $60, Large $110, etc. The $10 credit in the base plan means you can run one micro instance included. If you upgrade your database to a larger size or add more branches, you incur additional instance charges. Each branch environment is treated like an additional instance in terms of billing, and you’re only charged for the hours it’s actually running. The base $25 plan’s $10 credit does not apply to branch instances, it only covers the main project instance. So if you spin up branches, those consume compute credits separately (about $0.32 per day on a micro instance).
Cost scenarios
To make the analysis concrete, let’s compare costs in a few different theoretical scenarios. Please note that all scenarios are estimates, actual bills will vary. These scenarios assume certain architectural decisions and also do not take into account enterprise level discounts provided at certain scales for each offering.
Scenario 1: CI preview databases for a five engineer team
In this scenario, you have a production Postgres (~10 GB data) and a dev workflow where 5 developers frequently create isolated databases for feature work. Each dev branch is used ~3 hours per weekday for active development or running CI tests, then torn down. Additionally, you maintain a long-lived staging environment that is refreshed with production data nightly for final QA. Let’s compare monthly costs for enabling this on each platform.
TL;DR
~$21. xata.small (2 vCPU / 2 GB) 24×7 ($18) + 10 GB storage ($3). | ~$180. Persistent 2 vCPU staging instance; exceeds 750 CPU-hr quota, so ~$113 overage on top of the $69 base. | ~$25 - 30. $25 Pro plan covers one always-on Micro instance for staging; add +$5 if you upsize staging to a Small ($15/mo, first $10 covered by plan credits). |
~$4. 330h on micro instances ($0.012 / h). | ~$5. 330 CPU-h of overage at ~$0.016 / CPU-h. | ~$4.50. 330h on Micro branches ($0.0135 / h). |
N/A | N/A | ~$35. 5 branches × $0.32 / day × 22 weekdays |
$25 - 30 | $180 - 185 | $64 - 70 |
Xata
Staging on xata.small runs $18 in compute plus $3 storage. Ephemeral dev branches add about $4 (minute-billed at $0.012 / h) and negligible storage, keeping the bill around $25 – 30/mo. Copy-on-write means you never pay to duplicate the 10 GB dataset. Granular billing also lets you leave a branch up for an unusually long CI run without being penalized by hourly rounding.
Neon
The Scale plan’s 750 compute-hour quota is mostly eaten by the always-on staging node (1,460 CPU-h), so 710h spill into overage at $0.16 / h. Add the $69 subscription and you arrive at about $183/mo. The short-lived dev branches fit inside what’s left of the allowance. Any spike in staging load or an extra CPU added for performance pushes more hours into overage, so monthly spend can fluctuate noticeably.
Supabase
The Pro plan’s $25 base buys you one always-on Micro instance, which is perfect for staging. Dev branch compute is only about $4.50 (330h × $0.01344/h). Supabase also enforces a $0.32/day “preview branch” fee for every branch that exists, even if it’s just for a few hours. Five branches spun up every weekday add $35/month (5 × $0.32 × 22 work days). With that surcharge, monthly spend climbs to about $64–70. Keeping branch counts low or recycling a single shared preview databases are some ways to avoid this steady drip.
Scenario 2: HA deployment with two read replicas + always-on staging
To meet strict uptime and guarantee zero-downtime fail-over with realistic testing environments you’ll want to run one primary writer and two read replicas (three AZs total) with an always-on staging branch. This is a pretty common production setup. In our scenario, every node is an 8 vCPU / 32 GB instance holding the same 100 GB dataset. All four nodes will stay online 24×7.
TL;DR
~$1,121. xata.2xlarge $0.384/h × 4 × 730h | ~$4,278. $700 plan + (23,360 CPU-h − 1,000 incl.) × $0.16 | ~$2,240. $599 plan + 4 × 2XL compute ($0.562/h) |
~$30. 100 GB × $0.30 / GB-mo | In-plan (≤500 GB included) | ~$49. 400 GB total - 8 GB quota × $0.125/GB-mo |
N/A | N/A | ~$10. 1 staging branch × $0.32/day |
$1,151 | $4,278 | $2,318 |
Xata
Four always-on xata.2xlarge nodes run about $1,121/mo in compute. With copy-on-write, the primary, two replicas, and staging branch all reference the same 100 GB dataset. Adding only $30 for storage costs. The total cost ends up being $1,151/mo. Fail-over or promotion is simply a metadata flip and recovery time is nearly instant.
Neon
Each 8-vCPU endpoint burns 5,840 CPU-h per month. With four nodes that is 23,360 CPU-h. After the Business plan’s 1,000 CPU-h allowance, 22,360 CPU-h are billed at $0.16 ($3,578), plus the $700 subscription. Storage is CoW-backed, so the single 100 GB copy stays inside the 500 GB quota of the Business plan, keeping the bill at around $4.3k/mo.
Supabase
Compute for four 2XL add-ons costs around $1,641. Add the $599 Team plan, the preview-branch fee for staging ($10), and storage for four full copies ($49), and the bill lands around $2.3k/mo. Because Supabase stores physical files per database, storage scales linearly with each replica and the staging branch.
Scenario 3: Per-tenant isolation for SaaS offerings
A common SaaS enterprise pattern is tenant isolation, also described as having a database-per-customer. In this scenario, we assume 200 isolated customer branches, each holding about 10 GB of data and running on smaller instances (2 vCPU / 1 GB).
In this scenario, branches are live 9AM - 5PM on work days (~ 176h/month), then hibernate outside of those hours. Storage is always allocated, so the fleet’s overall footprint is about 2 TB.
TL;DR
~$422. 35,200h × $0.012 / h (xata.micro) | ~$6,172. 35,200 CPU-h: 1,000 incl. = 34,200h × $0.16 + $700 base | ~$1,072. 35,200h × $0.01344 / h + $599 base |
$600. 2,000 GB × $0.30 / GB-mo | ~$750. 1.5 TB over 500 GB allowance × $0.50 / GB-mo | ~$249. 1,992 GB over 8 GB × $0.125 / GB-mo |
N/A | N/A | $1,920. 200 branches × $0.32 / day |
$1,022 | $6,922 | $3,241 |
Xata
We bill strictly for what’s used. When a tenant branch sleeps, its compute cost drops to zero. Only storage continues at $0.30 / GB-mo. With all 200 customer databases active during the day, the PostgreSQL fleet’s compute adds up to about $422. Copy-on-write means each branch stores just the pages it changes, keeping the 2 TB footprint flat. As a result, for roughly $1k/month you can have 200 isolated tenants.
Neon
Every active vCPU is metered. Running even a single-CU compute for 176 hours racks up 176 CPU-h. Multiply that by 200 branches and it quickly adds up to 35,200 CPU-h. After the 1,000h allowance the overage alone is $5.5k, plus the $700 plan fee. Storage beyond 500 GB is another $750. Scale-to-zero helps overnight, but eight hours a day across 200 databases still adds up, landing the total near $7k/month.
Supabase
Compute is cheap ($0.01344/h) but each preview branch carries a flat $0.32/day tax, whether it runs five minutes or eight hours. That fixed fee ($1,920/mo) quickly dominates. When you add $250 for disk overage and $599 for the Team plan base, the bill approaches about $3.2 k/month.
Scenario 4: Data-science sandboxes for model training
In this scenario, five analysts spin up 2 TB clones on 32 vCPU / 128 GB nodes for supervised fine-tuning runs against their models one day each week. Each clone runs about 8 hours every Monday (~32 h/mo), so the platform logs 160 instance-hours a month. We estimate the storage growth by assuming the training job rewrites about 10% of the source pages (roughly 200 GB per branch). Multiplied by five analysts that yields to about 1 TB of new data for training.
TL;DR
~$246. xata.8xlarge at $1.536 / h × 160h | ~$1,359. $700 plan + 5,120 CPU-h – 1,000 incl. = 4,120 × $0.16 | ~$410. 8 XL compute at $2.562 / h × 160h |
~$900. 3 TB total × $0.30/GB-mo | ~$1,250. 2.5 TB over 500 GB allowance × $0.50/GB-mo | ~$1,535. 12 TB total × $0.125 / GB-mo |
N/A | N/A | $48. 5 branches × $0.32/day |
$1,146 | $2,609 | $2,600 |
Xata
You pay strictly for the 160 hours on xata.8xlarge, about $246. Because the primary 2 TB production database also lives inside Xata, storage now totals 3 TB (2 TB base + 1 TB dirty pages) at $0.30/GB-mo, or roughly $900. Branches hibernate the remaining 672h each month, so there’s no idle-time compute charge. The total cost is about $1,146/mo, still linear to the minutes the big node is powered on and the pages that are actually modified.
Neon
The Business tier includes 1,000 CPU-hours and 500 GB storage for $700/mo. One 32-vCPU node burns 32 CPU per hour. Across 160h, that’s 5,120 CPU-h and 4,120h over that will be charged an overage cost $0.16 ($659). On top of this, you can add 2.5 TB of extra storage at $0.50/GB ($1,250), resulting at roughly $2.6k/mo for this use case.
Supabase
An 8 XL add-on costs $2.562/h. At 160h that’s around $410. The Team plan base is $599. Supabase lacks copy-on-write for data pages, so each sandbox must hold a full 2 TB copy, bringing total stored data to 12 TB vs 3 TB like Xata and Neon. At $0.125/GB-mo that is about $1,535. The branch tax adds $48 for five branches and monthly cost rises to $2,600. Note that 12 TB exceeds the Team plan’s 4 TB cap, so this workload would require a bespoke enterprise contract or aggressive down-sampling before each training run. Provisioning multi-terabyte disks also triggers lengthy resize operations and would require extra lead time before each training window.
Scenario 5: Autonomous agents with high branch churn
In the last few weeks, we’ve seen the importance of databases in the AI agent race explode. With Databricks recent acquisition of Neon and Snowflakes recent acquisition of CrunchyData, it’s fair to say PostgreSQL is a well positioned database for the use case. In this scenario, an AI platform creates 1,000 ephemeral branches every day, each on a small instance (2 vCPU/1 GB).
Because of the task oriented nature of the agents and speed of iteration, every branch lives only for about 30 min. In total, the PostgreSQL fleet logs 15,000 instance hours per month. In this hypothetical, the working set is tiny (20 GB total), and branches are dropped as soon as the agent finishes.
TL;DR
~$180. 15,000h × $0.012 / h (xata.micro) | ~$2,940. $700 plan + (15,000 CPU-h - 1,000 incl.) × $0.16 | ~$205. 15,000h × $10/730h + $599 plan base |
~$6. 20 GB × $0.30 / GB-mo | Covered by the plan | Covered by the plan |
N/A | N/A | $9,600. 1,000 branches/day × $0.32 / day × 30d |
$186 | $2,946 | $10,404 |
Xata
Billing is minute-level at Xata. Each 30-minute micro branch costs $0.006. Aggregate that over the month and it’s about $180 in compute. Because branches are copy-on-write, the 20 GB hot set is only stored once, adding only $6. There are no control-plane limits throttle the 1,000-per-day create / delete cycle. In total, it’s about $186/mo for effectively unlimited amounts of ephemeral databases for your agents.
Neon
Neon counts vCPU-hours. A micro defaults to 1 vCPU, so 15,000 branch-hours consume 15,000 CPU-h. After the Business allowance (1,000 CPU-h) you pay 14,000 × $0.16 ($2,240), plus the $700 subscription. Scale-to-zero only helps if branches live long enough to be suspended, and in this scenario they don’t. As a result you pay $2.9k/mo, with most of the cost coming from compute overage.
Supabase
Compute itself is modest ($205), but every branch incurs a flat $0.32/day once it exists, even if it only exists for a short period of time. With 1,000 new branches daily that’s $9.6k per month, dwarfing compute and the $599 Team base fee. Daily branch fees make high-frequency, short-lived branches hard to justify without additional discounts.
Pricing analysis conclusion
Across all five scenarios the headline prices turn out to be only part of the story. And realistically, at certain scales discounts would come into play or different architectural decisions would be made. At the end of the day, Xata’s pay-as-you-go model remains linear. You add up vCPU-minutes and the copy-on-write storage actually in use. A 2 vCPU dev instance always costs $0.024h and an 8 vCPU production instance always costs $0.384h, no matter how many branches you keep around. Neon, by contrast, bundles a fixed pool of compute hours with each plan. Once a project’s vCPU-hours cross that quota, every extra hour is billed at $0.16 per CPU-hour. Supabase sets a low entry price for compute, but each branch triggers a $0.32-per-day charge that accrues until the branch is deleted.
Those hidden costs quickly become the surprise line-items in your monthly invoice. In Neon, keeping a single 8-vCPU database online 24×7 burns 5,840 CPU-hours a month, over five times the Scale plans allowance. Overage quickly eclipses the base fee in long-running, high-CPU workloads. With Supabase, even ephemeral CI or agent branches are caught by the per-day branch tax. Five branches spun up every weekday add roughly $35 to a Pro-plan invoice, and high-churn scenarios can push that figure into the thousands. Because Xata has neither quota overages nor per-branch levies, its costs stay proportional to the resources you use, making final invoices more predictable when workloads scale up or branch counts explode.
Wrapping it up
Branching a PostgreSQL database has officially moved from an interesting idea to being common in daily developer workflows. Xata, Neon, and Supabase each prove the pattern works and is reshaping the way developers and agents build, test, and ship software. With branching, the old bottlenecks of one shared developer database or the risk of production data leaking into your staging environment can disappear. Teams get parallel feature work, reproducible CI pipelines, and more efficient release practices.
Where the platforms diverge is in how their architectures convert that experience into dollars and developer experience. Xata keeps costs linear to the resources you actually hold open, Neon prioritizes burstable, serverless efficiency for short-lived workloads, and Supabase offers an all-in-one stack at a predictable entry price. Each model suits a different style of workflow. When considering adopting branching, make sure your choice matches your reality and expectations.
At Xata we spent a lot of time weighing those trade-offs and identifying who we’re building this platform for. Ultimately we landed on a vanilla-Postgres, copy-on-write storage layer that scales and improves performance, with an invoice that’s easily predictable. If that sounds interesting to you, we’re currently in private beta onboarding new teams every day. You can request access here or drop by our Discord to chat.