Render's $0.30/GB Postgres Line: When Your Database Bill Stops Being About Compute

In October 2024, Render split its Postgres bill in two. Before the change, you bought a tier — Starter at $7 a month, Standard at $20, Pro at $95 — and each tier bundled a fixed amount of compute with a fixed amount of storage. After the change, you buy compute and storage separately: a compute plan starting around $6 a month on the Basic tier, plus storage at a flat $0.30 per GB per month, metered to the second.

It reads like a small pricing refactor. It is actually a change in what your database bill is about — and for growing databases, the storage line quietly becomes the whole bill.

Here is the answer up front, with the formula so you can check my math against your own database. Your Render Postgres cost is now two lines:

Monthly bill = compute plan + ($0.30 × provisioned GB)

The storage line overtakes the compute line at exactly compute price ÷ 0.30 GB. On the $6 Basic-256mb tier, that crossover lands at 20 GB. On the $55 Pro-4gb tier, at about 183 GB. On the $75 Basic-4gb tier, at 250 GB.

Past that point, every extra gigabyte costs the same no matter how small your compute tier is — a 500 GB database pays $150 a month for storage before compute enters the picture at all. Against that, a self-operated Postgres on flat-rate Hetzner hardware runs the same data for roughly a tenth of the money at mid sizes, with the gap widening as storage grows.

The catch, and it is a real one, is that Render's premium buys automatic failover and point-in-time recovery that you would have to build and carry yourself. This post puts numbers on all three sides: the new meter, the worked comparison at three representative sizes, and what the managed premium actually guarantees.

What flexible plans changed, and the one gotcha that matters most​

Under the legacy bundled tiers, the deal was legible: Starter gave you 256 MB of RAM, a tenth of a CPU, and 1 GB of storage for $7 a month; Standard gave 1 GB of RAM, 1 CPU, and 16 GB for $20; Pro gave 4 GB, 2 CPUs, and 96 GB for $95; Pro Plus gave 8 GB, 4 CPUs, and 256 GB for $185. Storage grew with the tier whether you needed it or not, which meant small databases overpaid for disk and large databases were effectively forced up the compute ladder to get more of it. The flexible plans fixed exactly that coupling: pick any compute tier, attach any storage size, scale each independently.

Read the new price list carefully, though, because it prices three different things on three different axes. Free and Basic-256mb are identical specs — the $0 versus $6 difference buys you persistence and backups, not hardware. And Pro-4gb at $55 with 1 CPU is cheaper than Basic-4gb at $75 with 2 CPUs, because the Pro line sells availability and recovery guarantees, not raw compute. If you compare tiers on RAM-per-dollar alone, you will misread the menu.

Now the gotcha, and it is the single most consequential line in the new docs: you can increase storage at any time, in multiples of 5 GB, with no downtime — and you can never reduce it. Storage only ratchets one direction. Provision 100 GB for a migration, a backfill, or a quarter of unexpected growth, and that $30-a-month line is yours permanently, even after you delete 80 GB of it. Every number in the next section should be read with that ratchet in mind, because the plan that fits your database today can become a bill for a database you no longer have.

The worked comparison at three sizes​

To keep this honest, both sides get fully loaded bills: Render's compute plus storage plus the high-availability standby where a production setup would use one, and the self-hosted side's server plus block volume plus backup costs. Hetzner list rates below are 2026 cloud pricing excluding VAT, converted at roughly €1 to $1.10 — close enough for a comparison where the gaps land in multiples, not percentages.

Toy database: ~5 GB, side project. On Render, Basic-256mb compute at $6 plus 5 GB at $0.30 gives $7.50 a month, with daily backups and no failover. On Hetzner, the database fits comfortably inside the 40 GB of included SSD on a CX22 cloud server at €3.79 a month (2 vCPUs, 4 GB RAM) — all-in around $4–5 a month with snapshots at €0.011 per GB adding cents. Rough parity in dollars, and Render wins outright once you price even one hour of your own ops time. Nobody should self-host a 5 GB side-project database to save three dollars.

Growing production: ~50 GB, real users. On Render, Basic-4gb compute at $75 plus 50 GB at $15 gives $90 a month for a single instance. On Hetzner, 50 GB still fits inside the 80 GB of included disk on a CX32 at €6.80 a month (4 vCPUs, 8 GB RAM); add Hetzner's automated backups at 20 percent of the instance price and periodic snapshots, and the all-in lands near $10 a month. That is a 9x gap for a database with no standby on either side. The storage line ($15) is still smaller than the compute line ($75) here — but notice that the entire self-hosted bill is already smaller than Render's storage line alone.

HA production: ~100 GB, must survive a node failure. On Render, Pro-4gb compute at $55 plus 100 GB at $30 is $85 — and high availability maintains a standby with identical compute and storage that is billed at the identical rate, doubling the total to $170 a month. That doubling is documented, not hidden, but teams modeling the single-instance price routinely forget it. On Hetzner, two CX32-class servers plus 100 GB volumes each (block storage runs roughly €0.05 per GB per month, so about €5 per volume) land near $25–30 a month all-in, running Patroni or Stolon for automated failover with WAL shipping to cheap object-style storage for backups. The gap narrows to about 6x — and the remaining difference is exactly the managed premium, which is the subject of the next section.

Three patterns fall out of the table. First, the crossover formula from the introduction understates the self-hosting case, because Hetzner's included SSD means small databases pay no per-GB line at all — the per-GB meter only starts biting the self-hosted side past 40–80 GB, in 10 GB volume increments. Second, the mid-size single-instance database is where the managed markup peaks: too big for the cheap compute tier, not big enough for the standby cost to dominate. Third, at HA sizes the comparison stops being about hardware at all and becomes purely about who carries the pager — which is where the premium either justifies itself or doesn't.

What the managed premium actually guarantees​

Render's high availability is available on any flexible-plan database with at least 1 CPU running Postgres 13 or later, and it works the way the docs say: Render maintains a standby in the same region but a geographically separate zone that asynchronously replicates the primary, declares the primary dead after 30 seconds of unavailability, and fails over in seconds with the standby taking over the original connection URL. That is a genuine, tested recovery path for node loss, network partitions, and Postgres crashes alike — the three failure modes that actually page people.

Point-in-time recovery is the second half of the guarantee, and its limits are worth reading precisely. Continuous backups cover paid databases only: the Free tier gets neither recovery nor exportable logical backups (you pg_dump it yourself or you upgrade). The recovery window depends on your workspace plan, not your database tier — 3 days on Hobby, 7 days on Pro or higher — and upgrading does not backfill history. Recovery itself spins up a new instance at the chosen point in time so you can validate before repointing services, which is the correct design, but note what it is not: it is not a seven-day archive, it is not cross-region, and the standby protects against node failure, not against dropping the wrong table (that is what the PITR window is for, and the window is measured in days).

Now price the DIY equivalent, because "run Patroni" is doing a lot of quiet work in the previous section. A self-managed setup needs a second node for failover (counted above), continuous WAL archiving to survive a full cluster loss, tested restore runbooks, version upgrades you schedule and execute, and someone who answers when replication lag spikes at 2 AM.

The hardware and storage for all of that costs single-digit euros a month — a terabyte of backup-grade storage rents for around €3.20 a month, and snapshots cost a cent per GB. The infrastructure is nearly free; the on-call rotation is the entire price.

Teams that already operate stateful workloads absorb this into existing capacity and pocket the 6–9x savings. Teams whose database has never paged anyone because Render absorbed every incident are not paying a markup — they are buying salary arbitrage, and they should keep buying it until the bill, not the principle, forces the conversation.

The sensitivity check: where each tier flips, and when to move​

Generalize the crossover with one table, since the answer depends entirely on which compute tier you sit on:

At double the crossover size, storage is two-thirds of the bill; at 500 GB, storage is $150 a month on every tier, and arguing about compute tiers is rearranging deck chairs. Two practical consequences follow. First, audit provisioned-versus-used storage before anything else: with the grow-only ratchet, a database holding 30 GB on a 100 GB provisioning wastes $21 a month forever, and that waste compounds with every temporary spike anyone ever provisioned headroom for. Second, treat crossing a crossover point as the trigger to re-run this whole comparison rather than as a bill to accept — it is the moment your database stopped being a compute purchase with storage attached and became a storage purchase with compute attached, which is a different product wearing the same dashboard.

So when do you stay, and when do you leave? Stay while the bill sits under roughly $100 a month with no standby, while nobody on the team has operated Postgres, and while the PITR window is load-bearing for your compliance story — the premium is cheap insurance. Start planning the exit when the loaded bill crosses into the low hundreds, when database sizes are steady-state rather than spiky (steady sizes make the ratchet harmless), and when the team already carries on-call for other stateful systems so Postgres joins an existing rotation instead of creating one. The migration itself is the unglamorous part this post won't minimize: a pg_dump-and-restore works under ~20 GB, beyond that you want logical replication with a cutover window, and the rollback plan is keeping the Render instance warm until the new primary survives its first full backup cycle.

One honest scoping note, since this site builds a self-hosting platform: managed databases are an explicit non-goal for Bex.co. There is no "migrate your Postgres to us" ending to this story, and that is deliberate — operating other people's data with its backup, compliance, and 2 AM surface is a fundamentally different business from running stateless apps on machines you own. Take this post as migration-world data instead: the true cost of leaving, the exact terms of what you give up, and the math to decide when the pager is worth carrying yourself.

The bottom line​

Render's unbundling was good product design wrapped around a quiet price escalator. Separating compute from storage lets small databases stop overpaying for bundled disk they never used — a 5 GB database really does cost $7.50 now instead of $20. But the same meter turns every gigabyte past the crossover into a permanent $0.30-a-month annuity that only ratchets up, and by 100 GB with a standby you are paying $170 for what flat-rate hardware runs at $30.

The decision was never really about dollars per gigabyte, though. It is about whether your team already owns a pager for stateful systems. If it does, the storage line is a tax you can stop paying. If it doesn't, it is the cheapest on-call engineer you will ever hire.

Running that comparison for real? Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.