Where the Money Really Goes in MySQL, MongoDB & PostgreSQL

This article breaks down exactly how cloud database costs are structured across MySQL, MongoDB Atlas, and PostgreSQL — including the billing dimensions most teams miss until the invoice arrives.

Every team running MySQL, MongoDB, or PostgreSQL in the cloud starts with the same reasonable assumption: pay for an instance, pay for storage, done. Then the first real bill arrives. Compute is rarely the problem. The money disappears into Multi-AZ replication multipliers, cross-region egress charges, snapshot accumulation, IOPS provisioning mismatches, and end-of-life engine surcharges that nobody budgeted for.

Understanding exactly where cloud database costs accumulate — and why — is what separates teams that control their infrastructure spend from those that chase it. This article goes engine by engine through the real billing anatomy of cloud DB cost for MySQL, MongoDB Atlas, and PostgreSQL. Figures are based on publicly available pricing as of April 2026 for AWS us-east-1 / MongoDB Atlas us-east-1 / Azure East US.

The six billing dimensions that drive every cloud database bill

Regardless of engine or provider, cloud database pricing resolves into six dimensions. Most teams fully account for two at planning time and discover the rest on their bill.

• Compute (instance hours) — vCPUs and RAM, billed per second or per hour. The headline number everyone looks at first, but rarely the largest surprise.
• Storage — provisioned GB billed regardless of actual utilization. RDS storage cannot shrink once provisioned without migrating to a new instance.
• IOPS / throughput — provisioned or consumed I/O operations. Frequently guessed at planning time and corrected painfully on the first bill.
• High availability (Multi-AZ / replica sets) — enabling a standby node multiplies both compute and storage costs by 2x. Treated as a checkbox by most teams, not as a cost multiplier.
• Backup storage — snapshots beyond the free tier, compounded by retention window length. Accretes silently month over month.
• Data transfer / egress — charges for traffic crossing availability zones, regions, or going to the internet. Often zero-budgeted at project start.

Each engine weights these six dimensions differently. MySQL on RDS is dominated by the compute/HA axis. PostgreSQL adds table bloat and vacuum I/O overhead that indirectly inflate storage costs. MongoDB Atlas bundles compute, storage, and connection limits per tier in ways that make the jump between tiers highly non-linear.

MySQL on AWS RDS: where the money really goes

Compute is the baseline, not the ceiling

RDS for MySQL prices compute on a per-second basis after a 10-minute minimum. On-demand instance costs in us-east-1:

• A db.t3.micro (2 vCPU, 1 GB RAM) runs ~$0.017/hour, or roughly $12/month
• A db.m5.large (2 vCPU, 8 GB RAM) costs ~$0.192/hour, or ~$140/month on-demand
• Enabling Multi-AZ — required for any production workload — exactly doubles both compute and storage charges
• That same db.m5.large in Multi-AZ becomes ~$280/month before a single byte of data is stored

Storage: provisioned, not consumed

• RDS storage billing is based on what you provision, not what you use — General Purpose SSD (gp3) runs at ~$0.115/GB-month
• A 500 GB provisioned volume costs $57.50/month even if the database holds only 200 GB of live data
• RDS does not support storage shrinkage — once you scale a volume up, you stay at that size
• With gp2, hitting 3,000 IOPS required provisioning at least 1,000 GB of storage (3 IOPS/GB). gp3 decouples IOPS from volume size entirely — 3,000 IOPS are included at no extra charge regardless of volume size
• Migrating from gp2 to gp3 is zero-downtime and achievable via a single CLI command — it is one of the highest-ROI changes you can make to a running RDS fleet. See our MySQL upgrade case study for details.

Provisioned IOPS: the most expensive line item for write-heavy workloads

• io1 charges ~$0.10/IOPS-month on top of $0.125/GB-month for storage
• A 10,000 IOPS configuration on a 500 GB io1 volume costs $1,062.50/month in storage and IOPS alone — before any compute, backup, or egress charges
• gp3 allows provisioning extra IOPS independently at ~$0.02/IOPS-month above the 3,000 baseline — an 80% reduction in IOPS cost for equivalent throughput

Backup storage: silent accumulation

• AWS provides automated backup storage equal to the provisioned database size at no extra charge
• Beyond that threshold, additional backup storage costs $0.095/GB-month
• RDS snapshots persist until explicitly deleted — they accrue charges even if the source instance is gone
• Snapshot-and-restore upgrade workflows often leave orphaned snapshots that silently grow the backup bill month after month

Watch out: Running MySQL 5.7 or MySQL 8.0 past their AWS standard support end dates triggers Extended Support pricing — a per-vCPU-hour charge added on top of standard instance costs. A db.m5.xlarge (4 vCPUs) in Extended Support accrues an extra ~$292/month. These charges also apply to Multi-AZ standbys and Read Replicas — multiplying impact across every instance in the deployment.

Reserved Instances: the largest single lever for cost reduction

• 1-year No Upfront RIs reduce compute costs by ~29% with no cash commitment beyond the commitment to use the engine and instance family
• 3-year All Upfront RIs reach ~53% savings on compute
• RIs cover compute only — storage, IOPS, backup storage, and data transfer remain at on-demand rates
• Size-flexible RIs for MySQL and PostgreSQL let you cover any instance in the same family, providing room to resize without losing your reservation

MongoDB Atlas: where the tier model creates non-linear cost jumps

Tier pricing is not linear

Atlas dedicated clusters start at ~$57/month for an M10 on AWS us-east-1. An M30 runs ~$190/month. That appears to be a 3x jump. In practice, teams moving from M10 to M30 for connection limits or memory pressure face a 6–8x increase in effective monthly spend once storage, backups, and egress are included at the new tier's rate structure.

• Each tier bundles RAM, storage IOPS, and connection limits together — you pay for all of it even if you only need one component
• M10 and M20 clusters run on burstable-performance infrastructure; M30 and above use dedicated vCPUs — the jump in compute quality is real, not just marketing
• MongoDB recommends starting at a lower tier and monitoring, but production SLA requirements frequently force the upgrade before workload metrics fully support it

Multi-region deployments: cost structure, not just a checkbox

• Adding a second Atlas region for a replica set approximately doubles the base cluster cost
• Adding a third region (for global reads or disaster recovery) triples the base cost
• A 3-node M30 cluster in us-east-1 at ~$190/month becomes ~$570/month when replicated to eu-west-1 and ap-southeast-1 — before cross-region replication egress charges
• Cross-region replication generates write traffic from every primary write, billed at $0.02/GB — a meaningful cost for write-heavy workloads running globally distributed deployments. For sharding and high availability strategies, see our MongoDB Change Stream case study.

Backup costs: compound with retention and cluster size

• Atlas backup storage starts at ~$0.14/GB-month depending on region
• A 500 GB production cluster with 30-day retention and hourly snapshots can generate $300–400/month in backup costs alone — often invisible until a detailed billing review
• Teams enabling continuous backups for compliance find this line item growing proportionally with data volume, independent of cluster tier changes
• The free M0 tier does not include backups — the first time you need to restore, you've already outgrown the tier

Data egress: the invisible cost in read-heavy architectures

• Inbound data transfer to Atlas is free — egress is not
• Same-region transfers cost ~$0.01/GB; cross-region transfers run ~$0.02/GB; data sent to the public internet costs ~$0.09/GB
• A pipeline pulling 2 TB/month from Atlas to an external analytics system generates roughly $180/month in network costs — a figure that appears nowhere in the cluster tier estimate
• Atlas Search runs on the same cluster nodes and consumes CPU and RAM from the provisioned tier — for collections with large full-text indexes, this frequently forces a tier upgrade that would otherwise not be necessary

Atlas Data Federation charges $5 per TB of data processed with a 10 MB minimum per query — a cost structure that makes exploratory queries on large datasets expensive without disciplined query scoping. Always LIMIT federation queries and test against a subset before running full-dataset operations.

PostgreSQL: where bloat and vacuum inflate storage costs

RDS for PostgreSQL: structurally similar to MySQL with one major difference

PostgreSQL on RDS follows the same billing structure as MySQL — compute per second, storage per GB, IOPS provisioned or included, Multi-AZ doubling compute and storage. The pricing per instance type is within ~10% of MySQL for equivalent configurations. The same Extended Support penalties apply:

• PostgreSQL 12 passed its AWS standard support end date in February 2025
• Extended Support charges begin at ~$0.10/vCPU-hour in Year 1, rising to $0.20/vCPU-hour in Year 3
• All instances in a Multi-AZ deployment are charged Extended Support — both primary and standby
• Reserved Instance discounts do not apply to Extended Support charges — they are billed separately at full rate

Table bloat: a PostgreSQL-specific storage cost driver

PostgreSQL's MVCC implementation marks deleted and updated rows as dead tuples without immediately reclaiming their storage. Autovacuum reclaims this space asynchronously — but on high-write tables, dead tuples accumulate faster than autovacuum can process them.

• On a heavily-written 100 GB table, bloat rates of 20–40% are not uncommon without tuned autovacuum settings
• That translates to 20–40 GB of provisioned storage costs that deliver no actual data capacity — billed at full gp3 rates indefinitely
• Unlike MySQL, PostgreSQL does not release reclaimed space back to the OS after a standard VACUUM — only VACUUM FULL or pg_repack returns disk space to the volume. Review our PostgreSQL load balancing guide for architectural alternatives.
• Index bloat compounds the problem — B-tree indexes on high-churn columns accumulate dead pages alongside the table, further inflating storage

Identify bloated tables using pg_stat_user_tables:

SELECT relname,
       n_dead_tup,
       n_live_tup,
       round(
         n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2
       ) AS dead_pct
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

Tables with dead_pct above 10–15% on large datasets are candidates for a targeted VACUUM ANALYZE or a pg_repack run to reclaim space without an exclusive lock.

Autovacuum on large tables: when it becomes an IOPS cost driver

• On databases with tables in the tens-of-terabytes range, autovacuum workers generate significant I/O load reading through large tables to identify dead tuples
• Teams running io1/io2 storage are paying for every one of those vacuum I/O operations at the provisioned IOPS rate
• Setting autovacuum_vacuum_cost_delay and autovacuum_vacuum_cost_limit at the table level throttles vacuum I/O per table without disabling it globally

ALTER TABLE high_write_table SET (
  autovacuum_vacuum_cost_delay = 10,
  autovacuum_vacuum_cost_limit = 200
);

Azure Database for PostgreSQL: stop/start and reserved capacity

• A business-hours schedule (5-day, 9 AM–6 PM) reduces compute to ~180 hours/month versus 720 hours always-on — a 75% reduction with no architectural change
• Azure reserved capacity for 1 year saves up to 40% on PostgreSQL compute; 3-year commitments save up to 60–65%
• High Availability doubles the deployment cost, consistent with AWS Multi-AZ behavior — evaluate against actual RTO requirements before enabling

The Serverless alternative: Amazon Aurora Serverless v2 for MySQL & PostgreSQL

For workloads with highly unpredictable, spiky, or variable traffic patterns, provisioning a fixed instance size inevitably leads to two problems: paying for idle compute during quiet hours, or risking database lag and downtime during sudden traffic spikes. AWS offers a cloud-native alternative: Amazon Aurora Serverless v2, which supports both MySQL and PostgreSQL-compatible engines.

Rather than billing for fixed instance hours (like a db.m5.large), Aurora Serverless v2 scales database capacity dynamically, in-place, and automatically based on CPU usage, memory pressure, and network throughput.

How the billing capacity works

• Aurora Capacity Units (ACUs) — Capacity is measured in ACUs. One ACU provides approximately 2 GiB of memory, along with proportional CPU and networking resources.
• Granular scaling — The engine scales up and down in increments as small as 0.5 ACU, tracking your application’s workload variations in real-time. It is billed per-second with a 10-minute minimum.
• Minimum & Maximum bounds — You specify a capacity range (typically from a minimum of 0.5 ACU up to a maximum of 256 ACUs). If traffic spikes, it scales instantly; when the load drops, it shrinks back to your baseline.
• Scale-to-zero auto-pause — For development, staging, or intermittent test environments, Serverless v2 supports auto-pausing (scaling to 0 ACUs) when there are no active connections, reducing idle database compute costs to zero.

The Serverless "pricing premium" trade-off

While autoscaling is structurally convenient, Serverless v2 carries a notable unit-cost premium compared to provisioned RDS instances. In us-east-1, standard Aurora Serverless v2 costs approximately $0.12 per ACU-hour.

If your database workload runs at a sustained average of 8 ACUs (which equals 16 GiB of RAM) to handle consistent background tasks or worker queues, your monthly compute bill will be roughly ~$700. That is more than double the cost of a comparable provisioned 16 GiB instance.

The Serverless Math: Aurora Serverless v2 is highly cost-efficient if your database experiences prolonged idle periods punctuated by short, high-intensity spikes. However, for steady-state workloads with predictable, baseline CPU and memory usage, provisioned instances (especially when paired with Reserved Instance/Savings Plan commitments) remain much more cost-effective.

Beware the I/O and Multi-AZ multipliers

Two hidden cost drivers often surprise teams migrating to Aurora Serverless v2:

• The Multi-AZ multiplier — Enabling high availability in Aurora requires provisioned reader nodes in a secondary AZ. These reader nodes scale dynamically to mirror the capacity of the primary writer instance, effectively doubling your hourly ACU consumption.
• Standard I/O costs — Standard Aurora billing charges $0.20 per million I/O requests on top of compute and storage. For highly read-heavy or unindexed write workloads, I/O charges can easily exceed the base compute cost. If your database is I/O-intensive, you should evaluate the Aurora I/O-Optimized tier, which increases the ACU rate to ~$0.156/hour but entirely eliminates per-query I/O fees.

Five cost reduction actions that work across all three engines

1. Migrate gp2 volumes to gp3 — Zero-downtime, single CLI call, 80% reduction in IOPS cost per unit, and no performance regression for most workloads. If any RDS instance in your fleet is still on gp2, this is the first thing to do this week.
2. Stop non-production databases outside working hours — RDS stop/start and Atlas cluster pause all halt compute billing. A business-hours schedule (9 AM–6 PM, Mon–Fri) reduces compute from 720 to ~180 hours/month — a 75% reduction with zero architectural change.
3. Purchase Reserved Instances or reserved capacity for stable production workloads — If a production database has run at a consistent instance size for 6+ months with no planned resize, it qualifies. 1-year No Upfront RIs on RDS deliver ~29% compute savings with no cash commitment. 3-year All Upfront reaches ~53%. Azure PostgreSQL reserved capacity saves up to 65% over 3 years.
4. Audit and delete orphaned snapshots quarterly — RDS snapshots persist until manually deleted, accruing $0.095/GB-month indefinitely. Atlas backup retention windows should be set to the minimum compliant period, not the maximum available. A quarterly snapshot audit is one of the highest-ROI operational routines for any team running multiple production databases.
5. Right-size before reserving — Purchasing an RI on an oversized instance locks in the overspend. Validate that CPU utilization over 30 days is consistently above 40% and memory utilization above 50% before committing. AWS CloudWatch, GCP Cloud Monitoring, and Azure Monitor all provide the necessary usage metrics. A downsized, reserved instance saves more than a reserved instance on the wrong size.

FAQs

Does Multi-AZ on RDS double the total bill, or just compute?

Multi-AZ doubles both compute and storage. The synchronous standby replica in the second Availability Zone is billed at the same instance rate as the primary and uses its own provisioned storage volume. IOPS provisioning also doubles on io1/io2. Backup storage and data transfer are not doubled by Multi-AZ configuration itself, though the additional storage volume increases the baseline for the free backup tier calculation.

Why does my MongoDB Atlas bill spike after upgrading from M10 to M30?

The M10-to-M30 jump bundles significantly more RAM, connection limits, and storage IOPS together. Production deployments on M30 typically also add backup policies, may enable Atlas Search, and often run in multi-region configurations — none of which apply at M10 scale. The cluster tier cost itself roughly triples, but total bill impact is frequently 6–8x when surrounding services are included. Monitor Atlas Cost Explorer before committing to a tier upgrade — often query optimization or index improvements can delay the jump by 6–12 months.

How does PostgreSQL table bloat affect my cloud storage bill directly?

RDS storage is billed on provisioned GB, not on live data GB. Dead tuples from PostgreSQL's MVCC mechanism occupy space in the table's on-disk files but are invisible to application queries. If autovacuum is not keeping up on a high-write table, the physical file size grows continuously regardless of how many live rows the table holds. That inflated file size counts against the provisioned storage volume, generating real billing cost for space that stores no queryable data.

Are Reserved Instances a good choice for MySQL databases that need to scale up within the year?

Not necessarily if you expect to change instance families. AWS offers size-flexible RIs for MySQL and PostgreSQL — buying a db.r5.large RI covers any instance in the R5 family, with larger instances consuming the RI at a proportionally higher rate. This gives flexibility for growth within the same family. If you expect to cross instance families (e.g., M5 to R6i), wait until the architecture is stable before committing to a 1-year or 3-year RI.

What is the cheapest way to run a PostgreSQL database for dev/test on AWS?

A db.t4g.micro on gp3 storage in Single-AZ configuration, with stop/start enabled outside working hours. If the account is within its first 12 months on the legacy free tier, the first 750 instance-hours/month and 20 GB of storage are provided at no charge. After the free tier, a business-hours schedule reduces the compute charge from ~$12/month to approximately $3/month for the same instance type.

Cloud database billing is fundamentally an engineering problem, not a finance problem. Every cost driver described above — IOPS provisioning, Multi-AZ multiplication, snapshot accumulation, MongoDB tier non-linearity, PostgreSQL bloat — is addressable through specific configuration decisions at the database layer. The teams that control this spend review billing dimensions at the same cadence as query performance: regularly, with the right metrics, and before the invoice arrives.

Is your cloud DB bill growing faster than your user base?

Mydbops manages MySQL, PostgreSQL, and MongoDB deployments for engineering teams that want database reliability without dedicating internal bandwidth to infrastructure decisions. Our team can audit your current configuration, identify the specific cost drivers inflating your bill, and implement changes — storage tier migrations, RI recommendations, autovacuum tuning, bloat cleanup, backup retention tightening — that reduce spend without touching your application layer.

We offer Managed MySQL, Managed PostgreSQL, Managed MongoDB, Managed Redis, Database Consulting, and Emergency DBA services — all backed by senior engineers who live in database internals.