Cloud SQL and AlloyDB pricing

Cloud SQL pricing is vCPU-hours and GiB-hours of memory per edition and region, by the second, plus storage per GiB-month by type, backups per GiB-month, and for a highly available instance double the compute and the storage, because the standby is a second instance; on top come licences per core-hour for SQL Server, an extended support fee per vCPU-hour for major versions past their end of life, and the idle public address per hour. AlloyDB charges the same shape at higher rates per vCPU, with cluster storage per GiB-month that only grows and read pools at the primary's rate. On the bill, the instances that nobody stops dominate, high availability doubles them, and the storage line is the one that grows on its own, because Cloud SQL auto-grows a disk and never shrinks it.

Pricing dimensions

Google prices a database instance as compute per edition plus storage per type, and every combination of edition, region and resource has its own SKU; the machine series behind the edition sets the rate.

The edition sets the rate per vCPU and the series behind it: Enterprise on the general-purpose series is the baseline, Enterprise Plus on C4 costs about 30 percent more per vCPU and GiB and brings the data cache, more memory per vCPU and a 99.99 percent SLA. High availability is the multiplier that matters most: a regional instance doubles vCPUs, memory and storage, because the standby runs and replicates all the time, and the licence for SQL Server is the only item HA does not double. Storage is provisioned, not used: Cloud SQL grows the disk automatically when it fills, charges every GiB from then on, and never shrinks it; HDD costs about half of SSD per GiB, and Hyperdisk Balanced on Enterprise Plus separates capacity from IOPS and throughput. Extended support is the fee for staying: an instance on a major version past its end of life pays per vCPU-hour on top of the instance, and double from the third year, so an old MySQL 5.7 instance pays about 170 percent of its Enterprise vCPU rate for the version alone. AlloyDB is the same model with higher rates and storage that is charged per GiB-month of the cluster's data, so it grows with the data and not with a provisioned size. The mechanics across all three providers are in managed databases; what the database layer can be optimised by, in database optimisation.

How it appears in your billing data

In the billing export the rows carry service.description Cloud SQL and a sku.description that names engine, edition, resource and region: Cloud SQL for PostgreSQL: Enterprise edition vCPU in Frankfurt, Cloud SQL for PostgreSQL: Enterprise edition RAM in Frankfurt, Cloud SQL for MySQL: Enterprise Plus edition vCPU in Frankfurt, Cloud SQL for PostgreSQL: Regional - Enterprise edition vCPU in Frankfurt for the HA variant, Cloud SQL for PostgreSQL: Enterprise edition Storage SSD in Frankfurt, Cloud SQL: Backups in Frankfurt, Cloud SQL for SQL Server: Standard Edition License for the licence per core-hour, Cloud SQL for MySQL: Extended Support vCPU in Frankfurt, Cloud SQL: IP address idling in Frankfurt; usage.unit is hour for vCPU and licences, gibibyte-hour for memory and storage. resource.name in the export with resource-level detail names the instance, and system_labels carry nothing for databases, so without resource-level detail the attribution per instance rests on labels, which an instance carries and a replica inherits only if set. AlloyDB rows carry service.description AlloyDB with AlloyDB vCPU in Frankfurt, AlloyDB Memory in Frankfurt, AlloyDB Regional Cluster Storage in Frankfurt and AlloyDB Backup Storage in Frankfurt.

Discounts sit in credits: a committed use discount on Cloud SQL appears as credits.type COMMITTED_USAGE_DISCOUNT beside the vCPU and memory rows at list price, never beside storage, licences or shared-core rows, and the commitment fee as its own row per region; there is no sustained use discount on Cloud SQL. The export's structure is described in the Google Cloud billing export; in the FOCUS export, ServiceName carries Cloud SQL or AlloyDB, ServiceCategory Databases, SkuId the SKU, PricingCategory Standard or Committed and CommitmentDiscountId the commitment (FOCUS columns). Which instance runs which version, and therefore pays extended support, is in the instance list, not in the export; the SKU names the engine and the fee, not the version.

Levers

Configuration: the first lever is high availability per environment, because it doubles compute and storage and development databases need none; the second is the size, because vCPU and memory pay by the second and a database at 10 percent CPU pays for the other 90 (rightsizing); the third is storage type and growth, HDD for archives and logs, SSD for everything that queries, and a watch on the auto-grown disk that never shrinks, where a new smaller instance and a migration are the only way back. Backups get a retention of days, not months, and point-in-time recovery only where a restore to the minute is needed.

Purchase option: committed use discounts on vCPU and memory per region over one or three years, 25 and 52 percent on Enterprise in Frankfurt at the read date, for instances that run around the clock; nothing for shared-core, storage or licences. Stopping an instance at night pays nothing for compute but keeps the storage; for development the stop beats the commitment (scheduling and auto-scaling).

Architecture: the version upgrade is the lever with the shortest payback, because extended support costs more per vCPU-hour than the instance itself from the third year; read replicas only where reads actually move off the primary, because each pays the full rate; and AlloyDB where its columnar engine replaces a larger Cloud SQL instance, not as a default, because its rate per vCPU is higher. What the instance behind a self-managed database costs is in Compute Engine pricing.

Where it goes wrong

• HA on the development database. A regional instance doubles every line. Regional in the SKU on an instance nobody would fail over is the clue.
• The disk grew and stayed. Auto-growth added 500 GiB during a bulk load and the data is gone; the GiB-months stay. A new instance with the right size and a migration end it.
• Extended support on the old version. MySQL 5.7 or PostgreSQL 12 pay per vCPU-hour on top, double from the third year. Extended Support rows name the instances to upgrade.
• The licence on an idle SQL Server. Enterprise edition pays per core-hour whether queries run or not; a stopped instance pays no licence. Standard edition where the features suffice.
• The replica pays the primary's price. A read replica nobody reads from pays vCPU, memory and storage in full. The replica's query count shows it.
• Backups beyond their use. 30 days of retention with point-in-time logs on a database restored never. Retention of days, and the logs only in production.
• The public address idles. An instance with a public IP that connects through the private one pays the idle address per hour. Private IP only.

Example

List prices in USD for Frankfurt (europe-west3), read on 2026-10-21 from the Cloud SQL and AlloyDB pricing pages: Enterprise edition costs USD 0.0496 per vCPU-hour and USD 0.0084 per GiB-hour of memory, USD 0.0372 and USD 0.0063 with a one-year commitment, USD 0.023808 and USD 0.004032 with three years; highly available USD 0.0991 and USD 0.0168; Enterprise Plus on C4 USD 0.0648 per vCPU-hour and USD 0.0108 per GiB-hour, the data cache USD 0.000345205 per GiB-hour; SSD storage USD 0.000279452 per GiB-hour, USD 0.204 per GiB-month, HDD USD 0.108, backups USD 0.096 per GiB-month; a db-f1-micro USD 0.0126 per hour; SQL Server licences USD 0.47 per core-hour Enterprise, USD 0.13 Standard, USD 0.01134 Web; extended support USD 0.084 per vCPU-hour in the first two years and USD 0.168 from the third; an idle public IPv4 address USD 0.012 per hour. AlloyDB on the N2 and C4A series costs USD 0.07797 per vCPU-hour and USD 0.01322 per GiB-hour, regional cluster storage USD 0.0004849 per GiB-hour, USD 0.354 per GiB-month, backups USD 0.118 per GiB-month.

A PostgreSQL instance with 4 vCPUs and 16 GiB on Enterprise costs 730 × (4 × 0.0496 + 16 × 0.0084) = USD 242.94 a month for compute, plus 200 GiB of SSD USD 40.80 and 400 GiB of backups USD 38.40, USD 322.14 in all; the same instance with high availability USD 605.34, with a three-year commitment on the compute USD 195.75. The same 4 vCPUs on MySQL 5.7 in extended support pay 730 × 4 × 0.084 = USD 245.28 on top in the first two years, more than the instance's compute, and USD 490.56 from the third year. A SQL Server Standard instance with 4 vCPUs pays USD 379.60 of licence a month beside USD 242.94 of compute. The same 4 vCPUs and 16 GiB on AlloyDB cost USD 382.02 of compute plus 200 GiB of cluster storage USD 70.80. Ten development instances with 2 vCPUs and 8 GiB that run only on working days from 08:00 to 18:00 cost 10 × 220 × (2 × 0.0496 + 8 × 0.0084) = USD 366.08 instead of USD 1,214.72 around the clock. The figures show that high availability and extended support each cost as much as the instance again, that the commitment saves half on compute that runs around the clock, and that the stop saves more than the commitment on compute that does not.

Sources

Read on 2026-10-21. Prices: Cloud SQL pricing, AlloyDB pricing. Service: Cloud SQL editions, database version policies and extended support, committed use discounts for Cloud SQL. Billing data: structure of the standard Cloud Billing data export.