Cloud database cost: one Postgres on AWS, GCP and Azure

TL;DR. Cloud database cost for one PostgreSQL database with 4 vCPUs, 16 GB of memory, 500 GB of SSD and high availability comes to $606.71 a month on Cloud SQL, $634.76 on Amazon RDS and $637.52 on Azure at October 2026 list prices. The clouds differ by $30.81, about 5%. In a hypothetical estate built around that same database, the staging copy alone costs $634.76, and the production database is under a third of a $1,961.78 bill. Choosing the cheaper cloud saves less than finding one forgotten copy, and finding copies needs cost per database across every account and provider.

The question behind "cloud database cost" is usually which provider is cheaper. This post answers it with one spec priced on all three from each provider's own price data, read on October 27, 2026, then shows why the answer matters less than the reader expects: an estate's bill grows through copies, defaults that double lines, and storage that only goes up. The last part is the query that puts every database's cost in one table.

The same Postgres costs about the same on all three clouds

The spec: PostgreSQL, 4 vCPUs, 16 GB of memory, 500 GB of SSD, high availability across zones, 400 GB of automated backups, 730 hours a month. The nearest offer on each cloud:

• Amazon RDS for PostgreSQL, db.m6i.xlarge (4 vCPUs, 16 GiB) Multi-AZ, gp3, US East (N. Virginia). Rates from AWS's price list for Amazon RDS, publication of October 26, 2026.
• Cloud SQL for PostgreSQL, Enterprise edition, custom 4 vCPUs and 16 GB (Enterprise allows 0.9 GB to 6.5 GB per vCPU), SSD, HA, Iowa (us-central1). Rates from the Cloud SQL pricing page, which renders Iowa by default.
• Azure Database for PostgreSQL flexible server, General Purpose D4ds_v5 (4 vCores, 16 GiB), Premium SSD, zone-redundant HA, East US. Rates from the Azure Retail Prices API.

Cloud SQL's hourly rates ($0.000465753 per GiB-hour of HA SSD, $0.000109589 per GiB-hour of backup) are shown here as monthly rates over 730 hours. Azure's line uses 512 GiB because its storage table lists Premium SSD in discrete sizes (256 GiB, 512 GiB, 1 TiB), and 500 GB is not one of them.

The spread is $30.81 a month. At list price, picking a provider for one database is a 5% decision. The lines underneath differ more than the totals, and those differences decide which cloud is cheaper for a given workload.

Where RDS, Cloud SQL and Azure bill differently

High availability doubles the main lines everywhere. RDS Multi-AZ rates are twice Single-AZ for the instance and storage. Google: "An HA-configured instance costs twice as much as a standalone instance. This price includes CPU, RAM, and storage". Azure's pricing FAQ: a zone-redundant server with 4 vCores and 512 GiB "will be billed for 8 vCores and 1,024 GiB of storage".

The rest is not uniform:

The IOPS row means the specs are not equal. At the same storage size, the RDS volume gets roughly five times the Azure Premium SSD baseline. Azure's storage table lists Premium SSD v2 at 512 GiB with the first 12,000 IOPS included, at the same $0.115 per GiB list rate, so a write-heavy database on Azure should be priced on v2.

Egress can outweigh the whole spread. A database sending 1,000 GB a month to clients outside the cloud adds about $177 on Cloud SQL (931 GiB at $0.19) against $81 on RDS and $78 on Azure once their free 100 GB is used. That one workload trait moves a database's bill by close to $100, three times the list-price spread.

Licensed engines change the scale entirely. On RDS, a db.m6i.xlarge running SQL Server Standard with the licence included lists at $1.224 an hour Single-AZ against $0.356 for PostgreSQL: the licence costs $633.64 a month on one instance. Cloud SQL charges SQL Server Standard at $0.13 per core-hour with a four-core minimum, $379.60 a month at 4 vCPUs, and does not support bringing your own licence. In AWS's US East price list, RDS for Oracle on this class is offered only as bring-your-own-licence, so the Oracle licence is one you bring and pay for yourself. We did not price Azure SQL Database, a separate product from Azure's PostgreSQL service.

Why the estate's bill grows faster than any one database

Consider a team that runs the production database above on RDS, and the databases that grew around it:

Production is 32% of the estate. The staging and dev copies are $1,009.64, more than half, and the staging copy alone is 20 times the spread between clouds. None of this shows up on a pricing page, because each copy is a reasonable decision on the day it is made. Three mechanics keep it there:

1. Copies inherit production's settings. A staging database restored from a production snapshot comes back at production's size, and nobody turns off Multi-AZ on a database that "is only staging". Doubling applies on every cloud.
2. Storage only goes up. RDS: "You can't reduce the amount of storage for a DB instance after storage has been allocated". Azure: "You can only increase the storage size". Cloud SQL's settings page says you can increase capacity "but you cannot decrease it", while the same page mentions a manual shrink after automatic increases; we did not test it. A one-off data load leaves a permanent line.
3. Stopping does not stop the bill. A stopped RDS instance can stay stopped for at most 7 consecutive days, and Azure's stop guide shows the service message that a server "will be automatically started after 7 days". Cloud SQL stays stopped, but "charges for storage and IP addresses continue to apply".

Snapshots add a fourth line that the table leaves out. "When you delete your DB instance, RDS doesn't delete manual DB snapshots", and because the free backup allowance is sized on the Region's total database storage, deleting instances shrinks the allowance those snapshots sit in. The broader pattern across warehouses, pipelines and BI is in cloud waste in data infrastructure.

Put every database's cost in one table with FOCUS exports

All three clouds now export billing in the FinOps Open Cost and Usage Specification (FOCUS): AWS as the FOCUS 1.0 with AWS columns table in Data Exports, Google as a FOCUS export to BigQuery, Azure as a FOCUS cost and usage details export. Each has ResourceId, ResourceName, ServiceName and EffectiveCost, which is the cost after discounts with prepaid purchases amortized.

The owner tag is where the standard stops. AWS puts tags in Tags as a map<string, string>. Azure's Tags is a JSON object, and its usage details note that resource tags do not include resource group tags. Google's FOCUS export lists Tags as "Not provided" and points to x_Tags; labels, the kind Cloud SQL instances carry, are in x_Labels, a repeated key and value record. So the per-cloud part of the query is the owner expression. Written for DuckDB 2.0 (tested on mock rows, not a real account) after loading the three exports, with an owner tag or label on every database. Fill each ServiceName from SELECT DISTINCT ServiceName on your own export:

WITH dbs AS (
  SELECT 'AWS' AS cloud, ResourceId, ResourceName,
         Tags['owner'] AS owner, EffectiveCost
  FROM focus_aws
  WHERE ServiceName = '<RDS service name>'
  UNION ALL
  SELECT 'Google Cloud', ResourceId, ResourceName,
         list_filter(x_Labels, lambda l: l.key = 'owner')[1].value, EffectiveCost
  FROM focus_gcp
  WHERE ServiceName = '<Cloud SQL service name>'
  UNION ALL
  SELECT 'Azure', ResourceId, ResourceName,
         json_extract_string(Tags, '$.owner'), EffectiveCost
  FROM focus_azure
  WHERE ServiceName = '<Azure PostgreSQL service name>'
)
SELECT cloud, coalesce(owner, '(no owner)') AS owner, ResourceName,
       round(sum(EffectiveCost), 2) AS cost
FROM dbs
GROUP BY ALL
ORDER BY cost DESC;

Three gaps remain after the query runs:

• Backups land on other rows. On RDS, snapshot storage shows the snapshot ARN, not the DB instance ARN. For its detailed export, Google notes that some network transfer, "Cloud SQL backups in specific locations, and Storage Snapshot costs aren't included in the granular Cloud SQL instance costs".
• Transfer has no owner. AWS's resource ID "is blank for usage types that aren't associated with an instantiated host, such as data transfers".
• Tags only cover what was tagged. Cloud SQL accepts up to 50 user-defined labels per instance; the (no owner) row is the list of databases to chase first.

For the RDS side in depth, RDS pricing walks each meter and RDS cost optimization covers which instances to cut once each has an owner.

The objection: 5% of a large bill is still money

The strongest case for shopping on price: at a few hundred databases, 5% is real, and commitments widen the gap. Cloud SQL's one-year committed use price for HA vCPUs is $0.06195 against $0.0826 on demand, 25% off, which takes this database's compute from $404.71 to $303.53 a month. Add an egress-heavy workload and the cloud choice can move a database's bill by a fifth.

That is true per database, and it is the argument for pricing each workload on its own lines, egress and IOPS included. It does not change the estate arithmetic. A commitment discounts the staging copy at the same rate as production, so it locks the copy in for a year. The order that saves the most is to find and remove the copies first, then commit on what is left, then choose clouds for new workloads by their egress and storage profile.

What this comparison does not cover

Prices are on-demand list prices read on October 27, 2026, for one Region per cloud: US East for AWS and Azure, Iowa for Google, which is not Google's Northern Virginia region and may differ. GB and GiB are used as each provider bills them. We did not compare Cloud SQL disk performance, Enterprise Plus, Aurora, AlloyDB, serverless options, negotiated discounts or support plans. The estate is hypothetical, not a measured account.

Where Datapace fits

An estate's database cost sits in three exports with three tag formats, and the copies that drive it rarely carry an owner. Datapace is building one map of your data estate with usage and cost attached, and agents that propose changes as pull requests your team reviews and merges. For the same exercise on analytics platforms, read data warehouse cost: one workload priced on four platforms.

Sources

1. AWS, Price List API offer file for Amazon RDS, US East, publication of October 26, 2026, read October 27, 2026 (PostgreSQL, SQL Server and Oracle rates for db.m6i.xlarge and db.m6i.large, gp3 storage, backup storage, Extended Support).
2. AWS, Price List API offer file for AWS Data Transfer, US East (internet egress, first 10 TB).
3. AWS, Amazon RDS for PostgreSQL pricing (free backup allowance, 100 GB global egress free tier, Extended Support on Multi-AZ).
4. AWS, DB instance storage, storage autoscaling, stopping a DB instance, deleting a DB instance and DB instance billing.
5. AWS, FOCUS 1.0 with AWS columns and CUR 2.0 line item columns.
6. Google Cloud, Cloud SQL pricing, Iowa (us-central1), read October 27, 2026 (vCPU, memory, SSD, backup, egress, SQL Server licence, extended support and committed use rates).
7. Google Cloud, Cloud SQL for PostgreSQL docs: instance settings, high availability, backup options, start, stop and restart and labels.
8. Google Cloud, FOCUS data export structure and detailed usage cost export.
9. Microsoft, Azure Retail Prices API, East US, read October 27, 2026 (Ddsv5 compute, Premium SSD and v2 storage, backup storage, extended support, bandwidth).
10. Microsoft, Azure Database for PostgreSQL flexible server pricing (zone-redundant HA billing example).
11. Microsoft Learn, Azure Database for PostgreSQL: compute options, storage, backup and restore, scaling resources and stop a server.
12. Microsoft Learn, FOCUS cost and usage details schema and usage details fields.