Developer Tools · June 22, 2026 · 13 min read
Self-Hosted vs. Managed Postgres in 2026: A Cost & Reliability Breakdown
A technical, numbers-first comparison of self-hosted vs managed Postgres for engineering leads—real cost math across EC2, Hetzner, Neon, Supabase, RDS, and Aurora, plus the true price of an on-call rotation and a decision framework.
By FluxWriter Team
Every Postgres hosting decision comes down to three numbers, and most teams only look at one of them. The choice between self-hosted vs managed Postgres isn't really about the database engine—it's identical software either way—it's about who carries the pager at 3 a.m. and what that costs in dollars and salary. Before you compare a single price sheet, pin down your storage growth rate (GB/month), your realistic ops budget (engineer-hours you can spend on database babysitting), and your acceptable downtime (minutes per month you can absorb before it costs you customers).
Those three numbers will tell you more than any vendor benchmark. A 20 GB database growing 2 GB a month with a team that has zero spare ops capacity and a 99.9% SLA is a completely different decision than a 4 TB analytics warehouse with a dedicated platform team and a maintenance-window culture. Let's break down what each option actually costs and when each genuinely wins.
What "Managed" Actually Buys You
When you pay the markup for RDS, Aurora, Neon, or Supabase, you are not paying for Postgres. You are paying to never write the following yourself:
Automated backups and point-in-time recovery (PITR). A managed provider continuously ships WAL segments to object storage so you can restore to any second within a retention window—typically 7 days by default, up to 35 on RDS/Aurora. Rolling your own means configuring pgBackRest or wal-g, pointing it at S3 or Backblaze B2, scheduling full and incremental backups, and—the part everyone skips—actually testing a restore on a regular cadence. A backup you've never restored is a hope, not a backup.
Automated failover. Managed providers run a standby replica and promote it automatically when the primary dies, usually inside 60–120 seconds. RDS Multi-AZ does this with a synchronous standby; Aurora separates storage from compute so failover is faster still. Self-hosting equivalent reliability means running Patroni with etcd or Consul for consensus, plus HAProxy or PgBouncer in front for connection routing. That's a real distributed system you now operate.
Minor-version patching and OS maintenance. Postgres ships quarterly minor releases that fix real data-corruption and security bugs. A managed service applies these in a maintenance window with one click or automatically. Self-hosted, that's your job, on every node, forever—including the underlying Linux kernel, OpenSSL, and the storage driver.
Storage autoscaling and metrics. Managed disks grow without a pvresize/resize2fs dance, and you get Performance Insights or equivalent query-level telemetry out of the box.
The honest summary: managed Postgres is an insurance policy plus a labor-replacement service. Whether it's worth the premium depends entirely on what your engineers' time is worth and how much downtime hurts.
The Real Cost Math
List prices are where most comparisons go wrong, because they compare hardware to hardware and ignore the labor line entirely. Below are realistic monthly figures for three scales, as of mid-2026. I'm modeling a transactional OLTP workload, not bursty analytics.
- Small: ~20 GB data, 2 vCPU / 8 GB RAM equivalent, modest traffic.
- Medium: ~250 GB data, 8 vCPU / 32 GB RAM, steady production load, needs a replica.
- Large: ~2 TB data, 16 vCPU / 128 GB RAM, HA mandatory, read replicas.
All figures are infrastructure cost only (US regions), rounded, and assume reserved/committed pricing where it materially helps. Labor is called out separately afterward because that's where the real money is.
| Option | Small (~20 GB) | Medium (~250 GB) | Large (~2 TB) | Failover | PITR included |
|---|---|---|---|---|---|
| Hetzner dedicated/CCX (self-managed) | ~$25 | ~$120 | ~$450 | DIY (Patroni) | DIY (wal-g) |
| AWS EC2 self-managed (incl. EBS, 2 nodes for med/large) | ~$70 | ~$520 | ~$2,100 | DIY (Patroni) | DIY |
| Neon (serverless) | ~$19 | ~$300 | ~$1,200+ | Built-in | Yes |
| Supabase | ~$25 | ~$410 | ~$1,400+ | Built-in (paid tiers) | Yes (paid) |
| Amazon RDS (Multi-AZ) | ~$140 | ~$900 | ~$3,400 | Built-in | Yes |
| Amazon Aurora | ~$160 | ~$1,050 | ~$3,900 | Built-in | Yes |
A few things jump out. At small scale the absolute dollar differences are noise—$19 versus $140 is a rounding error against a single engineer's hourly rate, so optimize for convenience, not cost. The gap only becomes interesting at medium and large scale, where Hetzner self-hosting is genuinely 5–8x cheaper than RDS on raw infrastructure.
But that Hetzner column is a trap if you read it as the total cost. The $450/month large box has no failover, no tested backups, and no patching unless you build all of it. Aurora's $3,900 includes all three plus a storage layer that survives an availability-zone loss. The real comparison is $450 + (engineering labor) versus $3,900 + (near-zero labor).
Where Neon and Supabase Change the Equation
Neon's scale-to-zero and storage/compute separation make it the cheapest credible managed option for spiky or many-small-database workloads—think per-tenant databases or preview environments, where Aurora's per-instance pricing would bankrupt you. Supabase is priced for product teams who want Postgres plus auth, storage, and realtime in one bill; you're partly paying for the application platform, not just the database. Neither replaces RDS for a steady, high-throughput OLTP system at the 2 TB tier, where their costs climb toward—and sometimes past—RDS while giving you less control over the instance.
Reliability and the True Cost of On-Call
Here's the line item that never shows up on a pricing page: the human rotation required to operate self-hosted Postgres at production reliability.
To run an HA Postgres cluster you can actually trust, you need at least three engineers in a rotation—anything smaller is one resignation away from a single point of failure and burns out the people you have. Each carries the pager roughly one week in three. Conservatively:
- Fully-loaded cost of an infra engineer: ~$180,000/year (salary, benefits, overhead) in a US market; call it $90–110k in many European or remote-heavy teams.
- Share of their time spent on DB operations (patching, backup verification, failover drills, incident response, capacity planning): a realistic 10–20% even when things are quiet.
- That's roughly $18,000–$36,000 per engineer per year, or $54,000–$108,000 annually across a three-person rotation—$4,500–$9,000 a month in labor alone.
Suddenly Aurora's $3,900/month looks cheap. The self-hosted large-scale box at $450/month infrastructure plus $6,000/month in loaded ops labor is roughly $6,450/month and worse on every reliability axis unless your team is genuinely expert.
And reliability isn't just labor—it's outcome. The dangerous failure mode of self-hosting isn't the big visible outage; it's the silent one. The replica that's been broken for a week. The backup job that's been failing quietly since a credential rotated. The disk that filled at 2 a.m. because nobody wired up the alert. Managed services don't eliminate these, but they move the boundary of "things you can forget about" much further out.
Quantifying Acceptable Downtime
Translate your SLA into a budget. 99.9% availability is ~43 minutes of downtime per month. 99.99% is ~4.3 minutes. A single un-rehearsed self-hosted failover can eat your entire 99.99% budget in one event. If your business genuinely needs four-nines and you don't have a seasoned platform team, managed isn't a preference—it's a requirement.
When Self-Hosting Genuinely Wins
Self-hosting isn't a relic; there are real cases where it's the correct, sober choice—not just a way to save money.
You already have a platform team running Kubernetes or bare metal. If you're already operating Patroni, etcd, and a backup pipeline for other stateful services, the marginal cost of one more Postgres cluster is small and the savings at scale are real. The fixed cost of expertise is already paid.
Your data egress or storage volume makes managed pricing absurd. At 10 TB+ with heavy I/O, RDS/Aurora storage and IOPS charges can run into five figures monthly. Hetzner or owned hardware with NVMe can deliver more performance for a fraction of the price, and the labor delta is now small relative to the infra savings.
Data residency or compliance forces your hand. If you need Postgres in a specific jurisdiction, on specific hardware, or air-gapped, managed options may simply not exist for your requirements.
You need extensions or configuration the managed service won't allow. Want a custom C extension, a non-standard shared_preload_libraries, an exotic wal_level, or kernel-level tuning? RDS locks down superuser and a long list of parameters. Self-hosting gives you root.
Latency-critical co-location. If the database must live in the same rack as the app for single-digit-millisecond budgets, you control the topology directly.
Notice that "it's cheaper" appears in only one of these, and even there it's conditional on scale. Cost alone rarely justifies self-hosting once you honestly price the labor.
A Decision Framework
Run your three numbers through this in order. Stop at the first one that gives you a clear answer.
Acceptable downtime first. If you need 99.99%+ and don't have an experienced platform team already running stateful HA, choose managed. Full stop. No spreadsheet beats the cost of an outage you couldn't recover from.
Ops budget second. Honestly assess spare capacity. If you can't dedicate ~15% of three engineers to database operations without something else slipping, you don't have the budget to self-host reliably—choose managed. Be ruthlessly honest here; "we'll figure it out" is how silent backup failures happen.
Scale and growth third. If storage is under ~250 GB and growing slowly, the infrastructure savings from self-hosting are too small to bother—pick the most convenient managed option (Neon or Supabase for greenfield, RDS if you're already deep in AWS). If you're past ~1 TB with steady growth and you cleared gates 1 and 2, self-hosting on Hetzner or owned hardware starts paying for itself.
Special requirements override everything. Compliance, residency, exotic extensions, or extreme egress can force self-hosting regardless of the above. If you hit one of these, the framework is moot—you're self-hosting, so budget the team properly.
The framework's whole point is sequencing: reliability and labor capacity gate the decision before cost ever enters. Most teams that regret self-hosting skipped straight to step 3.
Frequently Asked Questions
Is managed Postgres always more expensive than self-hosting?
On raw infrastructure, almost always yes—RDS and Aurora carry a 2–5x markup over equivalent EC2, and Hetzner can be 8x cheaper still. But on total cost including the engineering labor to operate backups, failover, and patching, managed is frequently cheaper for teams under ~1 TB or without a dedicated platform team. The crossover point is where infrastructure savings exceed the loaded cost of the on-call rotation, which usually only happens at multi-terabyte scale.
Can I start self-hosted and migrate to managed later (or vice versa)?
Yes, and Postgres makes both directions feasible because it's the same engine everywhere. Logical replication (pglogical or built-in publication/subscription) lets you migrate with minimal downtime in either direction, and tools like AWS DMS exist specifically for this. The practical friction is usually connection-string changes and any provider-specific extensions—Aurora and Supabase add features you'd lose moving off them, so avoid coupling your app to vendor-specific bits if you want optionality.
What about Neon or Supabase versus traditional RDS for a new project?
For greenfield projects under heavy growth uncertainty, Neon and Supabase are often the better starting point: Neon's scale-to-zero and branching are excellent for preview environments and early-stage apps with unpredictable load, and Supabase bundles auth and storage so you ship faster. Move toward RDS or Aurora when you need a steady high-throughput instance, are already standardized on AWS, or hit the point where per-request serverless pricing exceeds a provisioned instance. Many teams use Neon/Supabase for the first two years and only reconsider at real scale.
The Bottom Line
The self-hosted versus managed Postgres decision is settled by your acceptable downtime and ops budget long before raw infrastructure price matters. Below a terabyte or without a dedicated platform team, pay for managed—the on-call labor you avoid dwarfs the markup. Self-host only when you've already got the operational expertise on staff, you're at multi-terabyte scale, or a hard requirement leaves you no choice.