Cloud Spanner pricing is compute per node-hour or processing unit-hour by edition and instance configuration, storage per GiB-month across all replicas, backup storage per GiB-month and replication per GiB between regions, with a minimum of compute that runs around the clock whether queries come or not; Bigtable charges nodes per hour by edition, SSD or HDD storage per GiB-month, backups and replication per GiB; Firestore charges per 100,000 document reads, writes and deletes, storage per GiB-month and egress per GiB, with a daily free quota and an Enterprise edition of its own. Memorystore charges per GB of cache per hour by tier. On the bill, Spanner and Bigtable are dominated by the nodes that run around the clock, Firestore by the reads of an application that queries more than it writes, and the storage line grows on all three with every replica.
Pricing dimensions
Google sells the three databases on three units, nodes, operations and bytes, and every edition, configuration and region has its own SKU; the instance configuration decides how many replicas every byte and every node pays for.
| Dimension | Unit | What drives it | Optional |
|---|---|---|---|
| Spanner compute | Node-hour or processing unit-hour, 1,000 processing units per node, by the hour, per edition (Standard, Enterprise, Enterprise Plus) and instance configuration; regional cheapest, dual- and multi-region dearer; autoscaling between bounds; one- and three-year commitments | The provisioned compute, used or not; the configuration's replicas | No |
| Spanner storage | GiB-month of SSD or HDD across all replicas of the configuration; read-only replicas per GiB-month on top | Database size times replicas | No |
| Spanner backups and replication | GiB-month of backup storage by configuration; GiB replicated between regions in multi-region configurations by continent pair | Backup retention, write volume in multi-region instances | Yes |
| Bigtable nodes | Node-hour per edition (Enterprise, Enterprise Plus) per cluster, by the hour, autoscaled between bounds; one- and three-year commitments | Provisioned nodes per cluster, used or not | No |
| Bigtable storage | GiB-month of SSD, HDD or infrequent access storage, standard and hot backup storage; tiered storage data movement per GiB; Data Boost per serverless processing unit-hour | Table size, backups, serverless reads | No |
| Bigtable replication | GiB replicated between clusters at network rates, free between zones of a region | Multi-cluster instances | Yes |
| Firestore operations | Per 100,000 document reads, writes and deletes in Standard edition; read and write units in Enterprise edition; a daily free quota of 50,000 reads, 20,000 writes and 20,000 deletes | Every query result document, every write, every delete | No |
| Firestore storage and egress | GiB-month of documents and indexes, 1 GiB free; GiB of egress with the first 10 GiB a month free | Database size including indexes, responses to clients | No |
| Memorystore | GB-hour of cache per tier for Redis, Valkey and Memcached; Redis Cluster per node-hour | Provisioned capacity, used or not | Yes |
| Purchase option | Spanner and Bigtable commitments over one or three years on compute; nothing on Firestore | Steady compute | Yes (Google Cloud committed use discounts) |
The provisioned unit sets the price on Spanner and Bigtable: a node pays its hour whether it serves a million queries or none, so the bill is the node count times the hours, and the configuration multiplies it, because a multi-region instance pays its compute and storage in every replica region and the replication between them. Spanner's processing units let an instance start at a tenth of a node, and the edition decides the rate, Enterprise about 35 percent above Standard and Enterprise Plus about 90 percent above, for features such as multi-region and the higher availability. Bigtable follows the same shape per cluster, with SSD storage at the full rate and HDD or infrequent access at a seventh for data read rarely. Firestore is the opposite model: nothing is provisioned, every document read, written or deleted pays, and the bill follows the application's query pattern, with a read for every document a query returns and the daily free quota covering a small service for nothing. The mechanics across all three providers are in managed databases; what the relational engines cost on Google Cloud, in Cloud SQL and AlloyDB pricing.
How it appears in your billing data
In the billing export the rows carry service.description Cloud Spanner, Cloud Bigtable or Cloud Firestore and a sku.description per unit, edition and configuration: Spanner Enterprise Edition Regional Node Frankfurt or Spanner Enterprise Edition Regional Processing Units Frankfurt per hour, Spanner Regional SSD Storage Frankfurt and Spanner Regional Backup Storage Frankfurt per GiB-month, Spanner Inter Region Replication per GiB; Bigtable Enterprise Edition Node Hour Frankfurt, Bigtable SSD Storage Frankfurt, Bigtable Backup Storage Frankfurt; Firestore Standard Edition Document Reads, Document Writes and Document Deletes per 100,000 by multi-region or region, Firestore Stored Data per GiB-month, Firestore Network Egress; usage.unit is hour, gibibyte-month, gibibyte or count. resource.name in the export with resource-level detail names the Spanner instance, the Bigtable cluster or the Firestore database, and their labels in labels are the attribution per team; the per-database usage of Spanner and Bigtable sits in their metrics, CPU utilisation and storage per database and per table, and Firestore's reads per collection in its usage dashboard, not in the export.
Commitments appear as credits.type COMMITTED_USAGE_DISCOUNT beside the node rows, the Firestore free quota as FREE_TIER beside the operations; there is no sustained use discount on the three. The export's structure is described in the Google Cloud billing export; in the FOCUS export, ServiceName carries the service, ServiceCategory Databases, SkuId the SKU, PricingCategory Standard or Committed and CommitmentDiscountId the commitment (FOCUS columns).
Levers
Configuration: on Spanner and Bigtable the first lever is the node count against the CPU utilisation, because a node at 20 percent pays for the other 80 and autoscaling with a measured minimum follows the load; the second is the edition and configuration, Standard and regional unless multi-region availability is a requirement, because dual- and multi-region configurations double or triple the compute and storage; the third on Bigtable is the storage type, HDD or infrequent access for data read rarely. On Firestore the lever is the query: a query that returns a thousand documents pays a thousand reads, aggregation queries pay per index entry batch, and a listener that re-reads on every change pays every change; the data model that denormalises what one screen needs cuts reads most. Patterns for the database layer are in database optimisation.
Purchase option: Spanner and Bigtable commitments over one or three years on the node baseline that runs around the clock, 20 and 40 percent off in Frankfurt on the read date; nothing on storage, nothing on Firestore (commitment strategy).
Architecture: Spanner where global consistency across regions is the requirement, Cloud SQL or AlloyDB for the relational workload that fits one region at a fraction of the node price; Bigtable for wide-column time series at scale, with Data Boost for analytical reads off the nodes; Firestore for applications whose reads per screen are known and bounded. A development Spanner instance of 100 processing units costs a tenth of a node and still pays around the clock; it belongs stopped between tests, which on Spanner means deleted and restored from backup.
Where it goes wrong
- Three nodes at 15 percent. A Spanner instance provisioned for a peak that never came pays three node-hours every hour. CPU utilisation per database and autoscaling with a minimum of processing units are the fix.
- Multi-region for a regional application. A multi-region configuration pays compute and storage in every region and replication between them. Regional unless the failover across regions is required.
- The development instance never stops. 100 processing units around the clock pay a tenth of a node every hour, every month. Delete and restore from backup between test phases.
- The query returns the collection. A Firestore query over 10,000 documents pays 10,000 reads on every call. Pagination, limits and denormalised summaries cut it.
- The listener re-reads. A real-time listener on a document that changes every second pays a read per change per client. Throttle the writes or aggregate them.
- SSD for cold data. A Bigtable cluster on SSD holding years of time series pays seven times HDD per GiB. Infrequent access tiering moves the old data.
- Backups beyond their use. Spanner backups pay per GiB-month of the full database at every retention step. A retention of days, and fewer backups on development databases.
Example
List prices in USD for Frankfurt (europe-west3), read on 2026-10-21 from the Spanner, Bigtable and Firestore pricing pages: a Spanner regional node costs USD 1.08 per hour on the Standard edition, USD 1.476 on Enterprise and USD 2.052 on Enterprise Plus, USD 0.864 and USD 0.648 per hour on Standard with a one- and three-year commitment; regional SSD storage USD 0.000493151 per GiB-hour across all replicas, USD 0.36 per GiB-month, HDD USD 0.072, multi-region SSD USD 0.54, regional backup storage USD 0.10 per GiB-month, a read-only replica's SSD USD 0.12 per GiB-month, replication between European regions USD 0.04 per GiB. A Bigtable node costs USD 0.78 per hour on Enterprise and USD 1.003 on Enterprise Plus, USD 0.624 and USD 0.468 with a one- and three-year commitment; SSD storage USD 0.204 per GiB-month, HDD and infrequent access USD 0.031, standard backup storage USD 0.031, hot backup USD 0.144, Data Boost USD 1.014 per 1,000 serverless processing unit-hours. Firestore costs USD 0.039 per 100,000 document reads, USD 0.117 per 100,000 writes and USD 0.013 per 100,000 deletes, storage USD 0.000160274 per GiB-hour, USD 0.117 per GiB-month.
A regional Spanner instance of three Standard nodes with 500 GiB of data costs 3 × 730 × 1.08 = USD 2,365.20 of compute and USD 180.00 of storage a month, USD 2,545.20; on Enterprise USD 3,232.44 of compute; with a three-year commitment on Standard USD 1,419.12 of compute. The same instance at 300 processing units costs USD 236.52 of compute. A Bigtable cluster of three Enterprise nodes with 2 TiB on SSD costs USD 1,708.20 of nodes and USD 417.79 of storage; the same data on HDD USD 63.49. A Firestore application that reads 300 million documents, writes 30 million and stores 50 GiB a month pays 3,000 × 0.039 plus 300 × 0.117 plus 50 × 0.117 = USD 117.00 plus 35.10 plus 5.85 = USD 157.95 before the daily free quota; the same application with a query pattern that reads a tenth as many documents USD 52.65. The figures show that provisioned nodes carry the Spanner and Bigtable bills regardless of load, that the edition and the configuration multiply them, and that on Firestore the query pattern, not the data, is the bill.
Sources
Read on 2026-10-21. Prices: Spanner pricing, Bigtable pricing, Firestore pricing. Service: Spanner compute capacity, nodes and processing units, Spanner editions, Bigtable storage types, Firestore usage and limits. Billing data: structure of the standard Cloud Billing data export.