Cloud Spanner Kosten sind Compute je Node-Stunde oder Processing-Unit-Stunde nach Edition und Instanzkonfiguration, Speicher je GiB-Monat über alle Replikate, Sicherungsspeicher je GiB-Monat und Replikation je GiB zwischen Regionen, mit einem Minimum an Compute, das rund um die Uhr läuft, ob Abfragen kommen oder nicht; Bigtable berechnet Nodes je Stunde nach Edition, SSD- oder HDD-Speicher je GiB-Monat, Sicherungen und Replikation je GiB; Firestore berechnet je 100.000 Dokumentlesevorgänge, -schreibvorgänge und -löschungen, Speicher je GiB-Monat und Egress je GiB, mit einem täglichen Freikontingent und einer eigenen Enterprise-Edition. Memorystore berechnet je GB Cache und Stunde nach Stufe. Auf der Rechnung dominieren bei Spanner und Bigtable die Nodes, die rund um die Uhr laufen, bei Firestore die Lesevorgänge einer Anwendung, die mehr abfragt als schreibt, und die Speicherzeile wächst bei allen dreien mit jedem Replikat.
Preisdimensionen
Google verkauft die drei Datenbanken in drei Einheiten, Nodes, Operationen und Bytes, und jede Edition, Konfiguration und Region hat ihre eigene SKU; die Instanzkonfiguration entscheidet, für wie viele Replikate jedes Byte und jeder Node zahlt.
| Dimension | Einheit | Was sie treibt | Optional |
|---|---|---|---|
| Spanner-Compute | Node-Stunde oder Processing-Unit-Stunde, 1.000 Processing Units je Node, stundenweise, je Edition (Standard, Enterprise, Enterprise Plus) und Instanzkonfiguration; regional am günstigsten, Dual- und Multi-Region teurer; Autoscaling zwischen Grenzen; ein- und dreijährige Commitments | Das bereitgestellte Compute, genutzt oder nicht; die Replikate der Konfiguration | Nein |
| Spanner-Speicher | GiB-Monat SSD oder HDD über alle Replikate der Konfiguration; Lesereplikate je GiB-Monat obendrauf | Datenbankgröße mal Replikate | Nein |
| Spanner-Sicherungen und -Replikation | GiB-Monat Sicherungsspeicher nach Konfiguration; GiB zwischen Regionen repliziert in Multi-Region-Konfigurationen je Kontinentpaar | Sicherungsaufbewahrung, Schreibvolumen in Multi-Region-Instanzen | Ja |
| Bigtable-Nodes | Node-Stunde je Edition (Enterprise, Enterprise Plus) je Cluster, stundenweise, zwischen Grenzen autoskaliert; ein- und dreijährige Commitments | Bereitgestellte Nodes je Cluster, genutzt oder nicht | Nein |
| Bigtable-Speicher | GiB-Monat SSD, HDD oder Infrequent-Access-Speicher, Standard- und Hot-Backup-Speicher; Datenbewegung der gestuften Speicherung je GiB; Data Boost je serverloser Processing-Unit-Stunde | Tabellengröße, Sicherungen, serverlose Lesevorgänge | Nein |
| Bigtable-Replikation | GiB zwischen Clustern zu Netzwerksätzen repliziert, frei zwischen Zonen einer Region | Instanzen mit mehreren Clustern | Ja |
| Firestore-Operationen | Je 100.000 Dokumentlesevorgänge, -schreibvorgänge und -löschungen in der Standard-Edition; Lese- und Schreibeinheiten in der Enterprise-Edition; ein tägliches Freikontingent von 50.000 Lese-, 20.000 Schreib- und 20.000 Löschvorgängen | Jedes Dokument eines Abfrageergebnisses, jeder Schreib-, jeder Löschvorgang | Nein |
| Firestore-Speicher und -Egress | GiB-Monat Dokumente und Indizes, 1 GiB frei; GiB Egress mit den ersten 10 GiB im Monat frei | Datenbankgröße einschließlich Indizes, Antworten an Clients | Nein |
| Memorystore | GB-Stunde Cache je Stufe für Redis, Valkey und Memcached; Redis Cluster je Node-Stunde | Bereitgestellte Kapazität, genutzt oder nicht | Ja |
| Kaufoption | Spanner- und Bigtable-Commitments über ein oder drei Jahre auf Compute; nichts bei Firestore | Gleichmäßiges Compute | Ja (Google Cloud Committed Use Discounts) |
Die bereitgestellte Einheit setzt den Preis bei Spanner und Bigtable: Ein Node zahlt seine Stunde, ob er eine Million Abfragen bedient oder keine, also ist die Rechnung Node-Zahl mal Stunden, und die Konfiguration vervielfacht sie, weil eine Multi-Region-Instanz ihr Compute und ihren Speicher in jeder Replikatregion und die Replikation dazwischen zahlt. Spanners Processing Units lassen eine Instanz bei einem Zehntel eines Nodes beginnen, und die Edition entscheidet den Satz, Enterprise rund 35 Prozent über Standard und Enterprise Plus rund 90 Prozent darüber, für Merkmale wie Multi-Region und die höhere Verfügbarkeit. Bigtable folgt derselben Form je Cluster, mit SSD-Speicher zum vollen Satz und HDD oder Infrequent Access zu einem Siebtel für selten gelesene Daten. Firestore ist das gegenteilige Modell: Nichts wird bereitgestellt, jedes gelesene, geschriebene oder gelöschte Dokument zahlt, und die Rechnung folgt dem Abfragemuster der Anwendung, mit einem Lesevorgang für jedes Dokument, das eine Abfrage liefert, und dem täglichen Freikontingent, das einen kleinen Dienst umsonst trägt. Die Mechanik aller drei Anbieter erklärt verwaltete Datenbanken; was die relationalen Engines auf Google Cloud kosten, Cloud-SQL- und AlloyDB-Preise.
So erscheint es in den Abrechnungsdaten
Im Abrechnungsexport tragen die Zeilen service.description Cloud Spanner, Cloud Bigtable oder Cloud Firestore und eine sku.description je Einheit, Edition und Konfiguration: Spanner Enterprise Edition Regional Node Frankfurt oder Spanner Enterprise Edition Regional Processing Units Frankfurt je Stunde, Spanner Regional SSD Storage Frankfurt und Spanner Regional Backup Storage Frankfurt je GiB-Monat, Spanner Inter Region Replication je GiB; Bigtable Enterprise Edition Node Hour Frankfurt, Bigtable SSD Storage Frankfurt, Bigtable Backup Storage Frankfurt; Firestore Standard Edition Document Reads, Document Writes und Document Deletes je 100.000 nach Multi-Region oder Region, Firestore Stored Data je GiB-Monat, Firestore Network Egress; usage.unit ist Stunde, Gibibyte-Monat, Gibibyte oder Anzahl. resource.name im Export mit Ressourcendetails nennt die Spanner-Instanz, den Bigtable-Cluster oder die Firestore-Datenbank, und deren Labels in labels sind die Zuordnung je Team; die Nutzung je Datenbank bei Spanner und Bigtable steht in ihren Metriken, CPU-Auslastung und Speicher je Datenbank und Tabelle, und Firestores Lesevorgänge je Sammlung in seinem Nutzungs-Dashboard, nicht im Export.
Commitments erscheinen als credits.type COMMITTED_USAGE_DISCOUNT neben den Node-Zeilen, das Firestore-Freikontingent als FREE_TIER neben den Operationen; einen Nutzungsrabatt gibt es bei den dreien nicht. Den Aufbau des Exports beschreibt Google-Cloud-Abrechnungsexport; im FOCUS-Export trägt ServiceName den Dienst, ServiceCategory Databases, SkuId die SKU, PricingCategory Standard oder Committed und CommitmentDiscountId das Commitment (FOCUS-Spalten).
Stellhebel
Konfiguration: Bei Spanner und Bigtable ist der erste Hebel die Node-Zahl gegen die CPU-Auslastung, weil ein Node bei 20 Prozent die übrigen 80 bezahlt und Autoscaling mit gemessenem Minimum der Last folgt; der zweite Edition und Konfiguration, Standard und regional, sofern Multi-Region-Verfügbarkeit keine Anforderung ist, weil Dual- und Multi-Region-Konfigurationen Compute und Speicher verdoppeln oder verdreifachen; der dritte bei Bigtable der Speichertyp, HDD oder Infrequent Access für selten gelesene Daten. Bei Firestore ist der Hebel die Abfrage: Eine Abfrage, die tausend Dokumente liefert, zahlt tausend Lesevorgänge, Aggregationsabfragen zahlen je Indexeintragsbündel, und ein Listener, der bei jeder Änderung neu liest, zahlt jede Änderung; das Datenmodell, das denormalisiert, was ein Bildschirm braucht, senkt die Lesevorgänge am stärksten. Muster für die Datenbankschicht stehen unter Datenbankoptimierung.
Kaufoption: Spanner- und Bigtable-Commitments über ein oder drei Jahre auf die Node-Grundlast, die rund um die Uhr läuft, 20 und 40 Prozent günstiger in Frankfurt am Lesedatum; nichts auf Speicher, nichts bei Firestore (Commitment-Strategie).
Architektur: Spanner, wo globale Konsistenz über Regionen die Anforderung ist, Cloud SQL oder AlloyDB für die relationale Last, die in eine Region passt, zu einem Bruchteil des Node-Preises; Bigtable für Zeitreihen im Wide-Column-Modell in großem Maßstab, mit Data Boost für analytische Lesevorgänge abseits der Nodes; Firestore für Anwendungen, deren Lesevorgänge je Bildschirm bekannt und begrenzt sind. Eine Spanner-Entwicklungsinstanz mit 100 Processing Units kostet ein Zehntel eines Nodes und zahlt trotzdem rund um die Uhr; sie gehört zwischen Tests gestoppt, was bei Spanner heißt gelöscht und aus der Sicherung wiederhergestellt.
Wo es schiefgeht
- Drei Nodes bei 15 Prozent. Eine Spanner-Instanz, für eine Spitze bereitgestellt, die nie kam, zahlt jede Stunde drei Node-Stunden. CPU-Auslastung je Datenbank und Autoscaling mit einem Minimum an Processing Units sind die Lösung.
- Multi-Region für eine regionale Anwendung. Eine Multi-Region-Konfiguration zahlt Compute und Speicher in jeder Region und die Replikation dazwischen. Regional, sofern das Failover über Regionen nicht verlangt ist.
- Die Entwicklungsinstanz hört nie auf. 100 Processing Units rund um die Uhr zahlen jede Stunde ein Zehntel eines Nodes, jeden Monat. Zwischen Testphasen löschen und aus der Sicherung wiederherstellen.
- Die Abfrage liefert die Sammlung. Eine Firestore-Abfrage über 10.000 Dokumente zahlt bei jedem Aufruf 10.000 Lesevorgänge. Paginierung, Limits und denormalisierte Zusammenfassungen senken es.
- Der Listener liest neu. Ein Echtzeit-Listener auf einem Dokument, das sich jede Sekunde ändert, zahlt je Änderung und Client einen Lesevorgang. Die Schreibvorgänge drosseln oder bündeln.
- SSD für kalte Daten. Ein Bigtable-Cluster auf SSD, der Jahre von Zeitreihen hält, zahlt je GiB das Siebenfache von HDD. Infrequent-Access-Stufung verschiebt die alten Daten.
- Sicherungen über ihren Nutzen hinaus. Spanner-Sicherungen zahlen je GiB-Monat der ganzen Datenbank bei jedem Aufbewahrungsschritt. Eine Aufbewahrung von Tagen, und weniger Sicherungen auf Entwicklungsdatenbanken.
Beispiel
Listenpreise in USD für Frankfurt (europe-west3), gelesen am 2026-10-21 von den Preisseiten von Spanner, Bigtable und Firestore: Ein regionaler Spanner-Node kostet 1,08 USD je Stunde in der Standard-Edition, 1,476 USD in Enterprise und 2,052 USD in Enterprise Plus, 0,864 USD und 0,648 USD je Stunde in Standard mit ein- und dreijährigem Commitment; regionaler SSD-Speicher 0,000493151 USD je GiB-Stunde über alle Replikate, 0,36 USD je GiB-Monat, HDD 0,072 USD, Multi-Region-SSD 0,54 USD, regionaler Sicherungsspeicher 0,10 USD je GiB-Monat, die SSD eines Lesereplikats 0,12 USD je GiB-Monat, Replikation zwischen europäischen Regionen 0,04 USD je GiB. Ein Bigtable-Node kostet 0,78 USD je Stunde in Enterprise und 1,003 USD in Enterprise Plus, 0,624 USD und 0,468 USD mit ein- und dreijährigem Commitment; SSD-Speicher 0,204 USD je GiB-Monat, HDD und Infrequent Access 0,031 USD, Standard-Sicherungsspeicher 0,031 USD, Hot Backup 0,144 USD, Data Boost 1,014 USD je 1.000 serverlose Processing-Unit-Stunden. Firestore kostet 0,039 USD je 100.000 Dokumentlesevorgänge, 0,117 USD je 100.000 Schreibvorgänge und 0,013 USD je 100.000 Löschungen, Speicher 0,000160274 USD je GiB-Stunde, 0,117 USD je GiB-Monat.
Eine regionale Spanner-Instanz mit drei Standard-Nodes und 500 GiB Daten kostet 3 × 730 × 1,08 = 2.365,20 USD Compute und 180,00 USD Speicher im Monat, 2.545,20 USD; in Enterprise 3.232,44 USD Compute; mit dreijährigem Commitment in Standard 1.419,12 USD Compute. Dieselbe Instanz mit 300 Processing Units kostet 236,52 USD Compute. Ein Bigtable-Cluster mit drei Enterprise-Nodes und 2 TiB auf SSD kostet 1.708,20 USD Nodes und 417,79 USD Speicher; dieselben Daten auf HDD 63,49 USD. Eine Firestore-Anwendung, die im Monat 300 Millionen Dokumente liest, 30 Millionen schreibt und 50 GiB speichert, zahlt 3.000 × 0,039 plus 300 × 0,117 plus 50 × 0,117 = 117,00 plus 35,10 plus 5,85 = 157,95 USD vor dem täglichen Freikontingent; dieselbe Anwendung mit einem Abfragemuster, das ein Zehntel so viele Dokumente liest, 52,65 USD. Die Zahlen zeigen, dass bereitgestellte Nodes die Spanner- und Bigtable-Rechnungen unabhängig von der Last tragen, dass Edition und Konfiguration sie vervielfachen, und dass bei Firestore das Abfragemuster, nicht die Daten, die Rechnung ist.
Quellen
Gelesen am 2026-10-21. Preise: Spanner Preise, Bigtable Preise, Firestore Preise. Dienst: Spanner-Rechenkapazität, Nodes und Processing Units, Spanner-Editionen, Bigtable-Speichertypen, Firestore-Nutzung und -Grenzen. Abrechnungsdaten: Struktur des Standard-Exports der Cloud-Billing-Daten.