MySQL vs PostgreSQL on managed services: does the engine change the bill?

A recurring question in architecture reviews: will we save money by picking MySQL over PostgreSQL, or the other way round? The rate cards say no. Every major managed service charges the same hourly rate for both engines on the same instance shape. The interesting answer is that the engines still produce different bills, because they consume the resources you are paying for in different ways.

The rate cards are identical

So if someone tells you MySQL is cheaper, ask which line they mean. There is one genuine tariff exception worth knowing: SQL Server and Oracle carry licence costs that dwarf both open-source engines, which is why migrations off them are usually the highest-value database cost project available. Between MySQL and PostgreSQL there is no licence line at all.

Where PostgreSQL costs more

The connection model is the big one. PostgreSQL forks a backend process per connection, consuming roughly 5 to 10 MB of resident memory each before work_mem allocations. An application opening 500 connections holds 2.5 to 5 GB purely in connection overhead. MySQL uses a thread-per-connection model with a much smaller footprint, commonly under 1 MB per idle thread, and thread pooling in some builds reduces it further. For a connection-heavy microservice fleet, this can be the difference between a 16 GB and a 32 GB instance, about $150 per month on RDS r-family shapes.

The second is bloat. PostgreSQL's MVCC writes a new row version on update and leaves the old one for autovacuum to reclaim. On a high-churn table with an undersized autovacuum configuration, table and index bloat of 20 to 40 percent is common and occasionally far worse. Since RDS storage is a ratchet that autoscales up and never down, bloat converts directly into permanent storage cost: 400 GB of bloat on a gp3 volume is $46 per month forever. MySQL's InnoDB uses undo logs and purges more aggressively by default, so it bloats less in the steady state, though it is not immune.

Where MySQL costs more

InnoDB stores rows in a clustered index keyed on the primary key, and every secondary index stores the full primary key as its pointer. With a UUID primary key (16 bytes, or 36 as a string if someone did that), every secondary index carries that weight per row. A table with 200 million rows and four secondary indexes pays for roughly 12.8 GB of primary key copies with a 16-byte key, and nearly 29 GB with a 36-character string key. PostgreSQL's heap-plus-index layout stores a 6-byte tuple identifier instead.

MySQL also lacks a native equivalent to PostgreSQL's partial and expression indexes in older versions, which in practice means broader indexes and more index storage for the same query patterns. And replication differences matter: PostgreSQL's physical streaming replication ships WAL, which is compact for update-heavy workloads, while MySQL row-based binlog replication can be substantially chattier, which shows up as cross-AZ transfer at $0.01 per GB in each direction.

A realistic net comparison

That last row is often the largest effect of all and it never appears in an engine comparison table. PostgreSQL's extension ecosystem, JSONB, full-text search, PostGIS, and vector search among them, regularly lets a team avoid standing up a separate search cluster or document store. Avoiding a $300 per month secondary datastore is worth more than any per-connection memory difference.

The honest recommendation

Do not pick an engine on cost. Pick it on team familiarity, feature fit, and operational maturity, then manage the cost consequences of whichever you chose: add a connection pooler if you run PostgreSQL at high connection counts, tune autovacuum aggressively on high-churn tables, and avoid random UUID primary keys on wide InnoDB tables. Those three actions capture most of the 10 to 30 percent that engine behaviour puts on the table.

Price the instance shape, storage, and replication topology from Terraform before you provision, so the connection-driven memory sizing is a decision rather than an incident. Compare shapes against the resource catalog, and see connection pooling economics for the PostgreSQL side.

FAQ

What to do next

Size your database before the engine behaviour sizes it for you. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.