Self-Hosted Postgres vs. Cloud Database: Which Costs Less?

Is self-hosted Postgres cheaper than a cloud database?

Self-hosted Postgres beats a managed cloud database on raw infrastructure cost almost every time, often by 50 to 90 percent. Add the engineering hours it takes to run it safely, and the gap shrinks fast, sometimes to nothing. The real question isn't which option is cheaper on paper. It's whether the convenience you're renting from AWS, Google, or Azure is worth the 40 to 60 percent markup they charge for it, or whether your team already has the skills to do that work itself.

What does a production Postgres database actually cost on AWS RDS?

A realistic production workload, 2 vCPU, 8GB RAM, Multi-AZ, one read replica, a staging environment, and 500GB of storage, runs about $744 a month on AWS RDS. The same spec self-hosted on EC2 costs roughly $332 a month in raw infrastructure, a 55 percent reduction before anyone touches a config file. Scale up to a mid-size production instance, 4 vCPU and 32GB RAM with high availability, and the gap gets uglier: AWS RDS, Google Cloud SQL, and Azure Flexible Server all converge around $460 to $580 a month for essentially the same box, while the equivalent server from Hetzner runs about $45 a month. That's a 10 to 20x difference in sticker price for infrastructure that is, underneath, running the same open-source Postgres engine either way.

So why does the bill look nothing alike? That's worth unpacking before anyone decides to migrate.

Why do cloud databases cost what they cost?

Managed database pricing isn't really a markup on compute. It's a bundle of operational insurance you're buying whether you need it or not. A base RDS instance might start around $138 a month, but a handful of standard production requirements stack on top of it fast:

• Multi-AZ failover roughly doubles compute cost by running a synchronously replicated standby instance you hope you never need.
• Read replicas add another full instance's worth of compute for every replica, even if your read load barely justifies one.
• Provisioned IOPS charges separately for storage performance that a self-managed NVMe disk gives you by default.
• Backup retention beyond the free window bills per gigabyte-month, and longer retention windows for compliance add up quietly.
• Data transfer and egress charge you to move your own data out, which is free coming in and never free going out.

Stack those together and a $138 instance becomes a $744 monthly line item without a single code change. You're not paying for faster Postgres. You're paying AWS to run Chef or Ansible, watch dashboards, and page someone at 3 a.m. so you don't have to. That's a legitimate thing to pay for. It's just worth knowing that's what the money buys.

What does self-hosting actually cost once you count engineering time?

Here's where most self-hosting pitches go wrong: they stop at the infrastructure number and call it a win. The honest version counts your team's time.

Setting up a self-hosted Postgres stack properly, with Patroni for failover, pgBackRest for backups, and Prometheus for monitoring, takes about 20 to 40 hours of initial engineering work. Ongoing maintenance after that runs 5 to 9 hours a month. At a blended engineering rate of roughly $100 an hour, that pushes the effective monthly cost of self-hosted Postgres to somewhere between $832 and $1,232, once you fold in the maintenance hours on top of the $332 infrastructure bill. That can land above the $744 RDS bill it was supposed to replace.

The wrinkle is that this labor cost isn't fixed. Pierce Freeman, who has run self-hosted Postgres in production for two years serving thousands of users and tens of millions of queries a day, reports about 30 minutes of total stress during that entire period and roughly half an hour a month of ongoing work on his high-availability setup. The gap between his 30 minutes and someone else's 9 hours comes down to one thing: whether the team already knows how to run a database, or is learning on the job while production traffic depends on it. Engineering time isn't a fixed tax. It's a function of the skills already sitting on your team.

How did 37signals cut cloud spend by walking away?

The clearest proof that this isn't just spreadsheet theory came from 37signals, the company behind Basecamp and HEY. Before its cloud exit, 37signals was paying over $500,000 a year combined for AWS RDS and Elasticsearch alone. In 2023 the company moved Basecamp, HEY, and five other apps off AWS entirely, onto roughly $600,000 of owned hardware, without hiring anyone new.

The payoff came fast. Within months, the move was already saving roughly $1 million a year, and the company's five-year projection put total savings at $10 million, a reduction of between half and two-thirds of their infrastructure spend. DHH's framing at the time was blunt: AWS was running a business with margins near 30 percent, and 37signals had been paying for that margin on every database query. That number tracks with Flexera's broader finding that 29 percent of cloud spend goes to waste industry-wide, and that 85 percent of organizations now call managing cloud cost their top challenge.

37signals isn't a startup making this call on day one. It's a company with existing ops talent, predictable load, and a cost base already well above the threshold where ownership pays off. That's the same calculus behind owning more of your own stack instead of renting availability from a vendor you don't control. It matters for the next question.

When does self-hosted Postgres win outright?

Self-hosting makes the most sense for a specific profile of team and workload:

1. Predictable load. Traffic that doesn't spike wildly means you can size hardware once instead of paying for elastic headroom you rarely use.
2. Existing ops talent. If someone on the team already knows Postgres internals, replication, and backup verification, the 5 to 9 hour monthly tax shrinks toward Freeman's half hour.
3. A bill already above $500 to $1,000 a month. Below that line, the engineering time to migrate rarely pays itself back fast enough to matter.
4. No heavy compliance burden. Fewer audits and attestations mean fewer hours spent proving your setup meets a standard rather than just running correctly.

There's also a narrower case that doesn't involve Postgres at all: SQLite. Its own maintainers describe it as an alternative to fopen(), not an alternative to a client-server database like Postgres. For single-writer, embedded, or low-write-concurrency apps, SQLite eliminates the database server entirely, which means there's no infrastructure bill to compare in the first place. It's a real production database for the right shape of app, not a general-purpose Postgres replacement. For teams rethinking their whole backend around owning more of the stack, it pairs naturally with the shift toward simpler, cheaper storage layers that skip managed services altogether.

When do managed or cloud databases still make sense?

The other side of the ledger is just as real. Managed services earn their markup when:

• Load is highly variable. Serverless options like Neon and Supabase, which can scale to zero and pause when idle, are genuinely cheaper than always-on self-hosted infrastructure for spiky or early-stage traffic.
• The workload is regulated. HIPAA, PCI, or FedRAMP requirements come with audit and attestation overhead that a managed provider has already absorbed into its platform.
• There's no dedicated ops capacity. A two-person engineering team with no database specialist will spend its scarce hours on product, not Patroni configs, and that tradeoff is often correct.
• The app is pre-product-market-fit. Paying a premium for convenience makes sense when the bigger risk is building the wrong thing, not overspending on infrastructure.

Postgres itself is now the default underneath almost all of this: it grew from 33 percent usage among professional developers in 2018 to 55.6 percent in the most recent Stack Overflow Developer Survey, making it the most-used database in the industry. The decision in front of most teams isn't which database, it's who operates it.

What is the middle path between managed and self-hosted: BYOC and other ways to de-risk the move?

Between fully managed and fully self-hosted sits Bring Your Own Cloud, where a platform handles the operational tooling, Patroni, pgBackRest, Prometheus, and the failover logic, while the database itself runs in your own cloud account at raw EC2 and EBS rates. For the same production workload used above, BYOC lands around $300 to $400 a month, undercutting both the full RDS bill and the self-hosted total once engineering time is counted. It's a reasonable hedge for teams that want the cost profile of ownership without building the operational tooling from zero, and it fits the broader pattern of turn-key self-hosting platforms quietly solving the hard parts of running your own infrastructure.

How do you actually run the numbers on your own database bill?

Before moving anything, price both sides honestly using the same checklist:

1. Add up the real cloud bill. Compute, Multi-AZ, replicas, provisioned IOPS, backup retention, and egress, not just the headline instance price.
2. Price the self-hosted infrastructure equivalent. Same vCPU, RAM, and storage, on EC2 or a dedicated host like Hetzner.
3. Estimate setup hours honestly. Twenty to forty hours for Patroni, pgBackRest, and monitoring if your team hasn't done this before.
4. Estimate ongoing hours at your blended rate. Somewhere between Freeman's half hour and the 5 to 9 hour range depends entirely on existing skill.
5. Compare the egress exposure. If moving data in or out is frequent, egress fees can be 10 to 15 percent of total cloud spend and a real factor in any future exit.

Run those five numbers side by side and the decision usually makes itself. The database was never the expensive part. The convenience was.