Managed Postgres vs self-hosted: the monthly bill at 500 GB and 2,000 connections

The bill is per instance-hour, and the standby is a second instance

Amazon RDS for PostgreSQL prices compute by the hour. The pricing page states that Single-AZ and Multi-AZ deployments are billed per DB instance-hour consumed from the time a DB instance is launched until it is stopped or deleted, and that partial hours after a billable status change are billed in one-second increments with a 10-minute minimum charge. A team running a handful of long-lived production databases sees a clean monthly figure; a team that spins up a database per branch or per test run pays ten minutes for every one of them.

High availability is where the shape of the bill changes. In a Multi-AZ DB instance deployment, RDS provisions and maintains a standby in a different Availability Zone and fails over to it automatically on a scheduled or unplanned outage. The AWS documentation is explicit that this standby provides failover support but does not serve read traffic. The reader is therefore paying for a second instance whose only job is to exist until the primary fails.

There is a second Multi-AZ shape that changes the arithmetic. A Multi-AZ DB cluster deployment keeps two standby instances across three Availability Zones, and those standbys do serve read-only workloads. For an estate whose read traffic is the bottleneck, the cluster option converts the standby from insurance into capacity, which is the difference between paying twice for one workload and paying three times for roughly three.

500 GB and 2,000 connections do not move the compute line

Storage is billed separately from compute, and the pricing page lists storage as its own line alongside instance hours. At 500 GB the storage charge is a fixed monthly cost that does not change with the deployment shape the way the instance count does; the Multi-AZ premium lands on compute, because each additional instance is another instance-hour. A team modelling the move should build the estimate from the instance class first and treat the 500 GB as a constant on both sides of the comparison.

Connection count is not a billed dimension on this page. Amazon RDS for PostgreSQL pricing is expressed in instance-hours, storage and deployment option, and the page describes a cost calculator that estimates by Region, instance type and deployment option. Nothing in the published pricing meters connections, so 2,000 connections is a sizing question rather than a billing one: it decides which instance class and how much memory the database needs, and the instance class is what sets the hourly rate.

That distinction matters for the comparison because self-hosting prices connections the same way. A self-managed PostgreSQL server sized for 2,000 connections is a server with enough memory to hold the connection overhead, and the cost is the machine plus whatever pooling discipline the team applies. Neither side charges per connection, so the honest comparison is instance class against server specification, not connections against connections.

The published rates are served live, so ask for a quote

The AWS pricing page does not print a dollar figure in its text. The instance tables are populated from a pricing endpoint at request time, with placeholders for general purpose and memory optimized instance types across Single-AZ and Multi-AZ. A reader who wants the number for a specific instance class has to load the page or use the cost calculator, and a reader comparing two options needs that number for the class they would actually run.

This is a finding rather than a gap. Because the rate is not fixed in the page, any figure quoted in a planning document is only as good as the day it was pulled, and the comparison should carry the date. The thing to ask AWS or a reseller for is a written monthly estimate for the chosen instance class at 500 GB of storage in the target Region, under both Single-AZ and Multi-AZ, so the premium is stated in currency rather than in instance counts.

There are two published levers that change the rate without changing the architecture. On-Demand pricing carries no upfront fee or minimum commitment, and Reserved Instances are offered at a discounted rate. The page also notes that RDS for PostgreSQL usage may be eligible for Database Savings Plans, which trade a one-year commitment to a dollar-per-hour spend for savings. A team that knows its baseline can price the commitment against the on-demand figure and see what the discount is worth.

What self-hosting actually costs beyond the server

The self-hosted side of the comparison is a server plus the work of running PostgreSQL on it. The AWS page does not price a self-managed deployment, so the server cost depends on where it runs and is outside what these sources state. What the page does establish is the list of things RDS performs that a self-hosted team takes on: provisioning and maintaining a standby in a second Availability Zone, automatic failover on a scheduled or unplanned outage, and the storage and backup lines that appear on the managed bill.

The Multi-AZ comparison is the clearest place to see the trade. A self-hosted primary with a streaming replica gives the same failover property, but the replica is a second server the team configures, monitors and promotes by hand, and the promotion is a runbook rather than an automatic event. The managed premium buys the automation of that runbook, and the reader should price the on-call hours honestly against it rather than treating the DBA time as free.

Capacity is the other hidden line. Amazon RDS On-Demand Capacity Reservations let a team reserve compute capacity in one or more Availability Zones so that create, restore, scaling and start operations do not fail for insufficient capacity. Immediately active reservations require no commitment and can be cancelled at any time, while future-dated reservations require a minimum commitment duration. A self-hosted estate gets the same guarantee by buying hardware ahead of demand, which is a capital commitment rather than an hourly one.

Where the managed premium stops being worth paying

The premium is easiest to justify where the database count is low and the availability requirement is high. A single production database at 500 GB with a Multi-AZ DB instance deployment pays for two instances and gets automatic failover, managed backups and no server to patch. Spread that fixed operational overhead across one database and it is a large share of the bill; spread it across twenty and the per-database cost of the automation falls sharply.

The arithmetic reverses for estates with many small, short-lived databases. The 10-minute minimum charge on partial instance-hours means a database created and deleted within a minute still bills ten minutes, and a team that provisions a database per test run or per branch accumulates those minimums. A self-hosted server running many small databases shares one machine and one patching cycle, and the marginal cost of the twentieth database is close to zero.

Read-heavy workloads are the third case. A Multi-AZ DB cluster puts two standbys to work serving read-only traffic, so the extra instances return query capacity rather than sitting idle. A team whose primary is saturated by reads should compare the cluster option against adding read replicas, because both add instances and only one of them also improves the failover story.

The decision rule

Choose Amazon RDS for PostgreSQL with a Multi-AZ DB instance deployment if the estate runs a small number of production databases that must survive an Availability Zone failure without a manual promotion, and the team would rather pay a second instance-hour than own the failover runbook. Choose the Multi-AZ DB cluster if read traffic is the constraint as well as availability, because the two standbys serve reads and the third instance earns its place. Choose self-hosted PostgreSQL if the estate runs many small or short-lived databases, where the 10-minute minimum on partial hours and the per-instance billing make the managed premium scale with database count rather than with workload.

Before signing, ask for a written monthly estimate for the specific instance class at 500 GB in the target Region under both Single-AZ and Multi-AZ, and ask what the Database Savings Plans commitment would return against that baseline over one year. The published page gives the billing mechanics and the deployment shapes; the currency figure has to come from the calculator or the account team, and it should carry the date it was pulled.