Cloud Bigtable 2026: Wann Wide-Column BigQuery, Spanner und Cassandra schlägt

Bigtable ist die am meisten missverstandene Datenbank in Google Cloud. Teams greifen zu BigQuery, wenn sie Bigtable brauchen, schrauben ein Analytics-Warehouse an einen Workload, der nur schnelle Key-Lookups will, und wundern sich dann, warum Rechnung und Latenz beide in die falsche Richtung liefen. Andere hören „NoSQL in Google-Größe“ und werfen Bigtable auf ein Problem, das eigentlich relationale Transaktionen brauchte.

Die Verwirrung ist verständlich — die Namen verschwimmen, und auf jedem steht „Petabytes“. Aber diese Engines lösen wirklich unterschiedliche Probleme, und die falsche zu wählen ist auf eine Weise teuer, die man jahrelang spürt. Das hier ist ein praktischer Leitfaden dazu, was Cloud Bigtable wirklich ist, wann es BigQuery, Spanner, Cassandra und DynamoDB schlägt, und die eine Design-Entscheidung, die bestimmt, ob es fliegt oder abstürzt.

Was Bigtable wirklich ist

Bigtable ist ein Wide-Column-NoSQL-Store: eine einzige, riesige Tabelle, in der jede Zeile über einen Row Key adressiert wird und Spalten spärlich sind und in Column Families gruppiert werden. Es stammt direkt vom Bigtable-Paper von 2006 ab, das HBase, Cassandra und einen Großteil der NoSQL-Ära inspirierte — und dieselben Kernideen erklären sein Verhalten bis heute.

Unter der Haube zählen drei Dinge:

1. Zeilen werden nach Row Key sortiert gespeichert. Die Tabelle ist ein langer, lexikografisch geordneter Keyspace — deshalb sind Range-Scans günstig und deshalb zählt das Key-Design so sehr (dazu unten mehr).
2. Die Tabelle wird in Tablets aufgeteilt. Zusammenhängende Zeilenbereiche bilden Tablets, und jedes Tablet wird von genau einem Node bedient. Füge Nodes hinzu, und Bigtable verteilt Tablets automatisch neu.
3. Speicher ist von Compute getrennt. Daten liegen als immutable SSTables auf Colossus, Googles verteiltem Dateisystem. Nodes bedienen Requests; sie besitzen die Daten nicht. Diese Trennung ist der Grund, warum du Durchsatz durch Hinzufügen von Nodes skalierst, ohne je ein Byte zu verschieben — und warum Bigtable von Gigabytes bis Petabytes einstellige Millisekunden-Latenz hält.

Das ist das ganze mentale Modell: eine sortierte Wide-Column-Tabelle, in Tablets zerlegt, bedient von einer dünnen Compute-Schicht über dauerhaftem Speicher. Alles, worin Bigtable gut und schlecht ist, folgt daraus.

Wo es passt: Bigtable vs BigQuery vs Spanner vs Cassandra

Am schnellsten wählst du richtig, indem du jede Engine danach einordnest, wie du auf die Daten zugreifst, nicht nach dem Marketing.

• Cloud Bigtable — Punkt-/Key-Zugriff, Wide-Column-NoSQL. Durchsatzstarke Reads und Writes per Row Key, einstellige ms-Latenz, Single-Row-Atomarität.
• Cloud Spanner — Punkt-/Key-Zugriff, aber relational mit SQL und starken Multi-Row-Transaktionen. Diese Korrektheit kostet pro Operation mehr.
• BigQuery — die entgegengesetzte Ecke: analytische Full-Table-Scans mit SQL. Hervorragend für Aggregationen über Milliarden Zeilen, falsch fürs schnelle Holen einer einzelnen Zeile.
• Cassandra / DynamoDB — dieselbe Wide-Column-Familie wie Bigtable, die man auf AWS/Azure oder in einem bestimmten Hybrid-Setup wählt.

Dieselbe Entscheidung als Tabelle:

Das Muster ist klar: Bigtable gehört der Punktzugriff im großen Maßstab. Sobald du SQL-Analytics brauchst, ist das BigQuery; sobald du relationale Transaktionen brauchst, ist das Spanner. Wenn du für die Analytics-Seite noch zwischen den beiden Warehouses wählst, sind die Trade-offs hier aufgeschlüsselt: BigQuery vs Snowflake 2026: Ein ehrlicher Vergleich.

Wann Bigtable die richtige Wahl ist

Bigtable glänzt, wenn ein Workload ein bekanntes Key-Zugriffsmuster und eine sehr hohe Lese-/Schreibrate hat. Die klassischen Fälle:

• Zeitreihen und Monitoring — Metriken, Events und Sensordaten, kontinuierlich geschrieben und nach Entität + Zeitbereich zurückgelesen.
• IoT — Millionen Geräte, die je Daten anhängen; Bigtable schluckt die Schreib-Feuerwehr ohne Latenzeinbruch.
• Adtech und Personalisierung — Nutzerprofile und Echtzeit-Bidding-State, in Millisekunden abgerufen, milliardenfach am Tag.
• Finanz-/Betriebsdaten — hochvolumige transaktionale Datensätze (keine Multi-Row-Transaktionen) wie Tick-Daten oder Ledger.
• ML-Feature-Stores — Feature-Lookups mit niedriger Latenz zur Serving-Zeit, in einem Maßstab, der eine relationale Datenbank ins Schwitzen brächte.

Der rote Faden: Du kennst den Key, brauchst die Antwort schnell, und es gibt viel Traffic. Ist das dein Workload und brauchst du keine Joins oder Multi-Row-Transaktionen, ist Bigtable schwer zu schlagen.

Der Row Key ist das ganze Spiel

Alles Gute an Bigtable hängt an einer Entscheidung: dem Row Key. Weil Zeilen sortiert gespeichert und nach zusammenhängenden Bereichen in Tablets aufgeteilt werden, bestimmt der Key, welcher Node jeden Write bearbeitet. Machst du ihn falsch, hebelst du die gesamte Architektur aus.

Die Falle sind sequenzielle Keys — ein roher Zeitstempel, ein hochzählender Counter, alles Monotone. Jeder neue Write sortiert sich ans Ende des Keyspace, also landet jeder Write im selben Tablet, also nimmt ein Node 100 % der Schreiblast, während der Rest untätig bleibt. Du hast ein Hundert-Node-Cluster gekauft und nutzt eines. Das ist der Bigtable-Performance-Bug Nummer eins — und komplett selbstverschuldet.

Die Lösung ist ein hochkardinales Präfix, das Writes über den Keyspace verteilt:

• Field Promotion — setze ein hochkardinales Attribut (wie device_id oder user_id) vor den Zeitstempel: device123#2026-07-13T10:00. Writes streuen jetzt über Geräte statt sich auf „jetzt“ zu türmen.
• Salting — stell einen Hash-Bucket voran (03#…), sodass Writes rundlaufend über N Tablets verteilt werden.
• Hashing / Umkehren — kehre eine sequenzielle ID um oder hashe sie, sodass benachbarte Werte weit auseinanderliegen.

In der Praxis ist der Key ein zusammengesetzter String, und die Reihenfolge seiner Teile ist die ganze Entscheidung:

# Gut: hochkardinales Präfix zuerst, dann umgekehrter Zeitstempel
#   device123#20260713T0959      → Writes streuen über Geräte
# Schlecht: der Zeitstempel führt
#   20260713T1000#device123      → jeder Write türmt sich auf "jetzt"

cbt createtable metrics families=m
cbt set metrics "device123#20260713T0959" m:temp=21.4
cbt read metrics prefix="device123#"     # schneller Range-Scan, ein Gerät

Das Ziel ist immer dasselbe: Writes verteilen, nicht nach Zeit sortieren. Halte zusammengehörige Daten nah genug, damit deine üblichen Range-Scans effizient bleiben, aber lass nie die „neuesten“ Zeilen alle auf ein Tablet fallen. In Bigtable ist der Row Key kein bloßer Bezeichner — er ist das Performance-Modell.

Drei weitere Dinge, die in der Produktion beißen

Das Row-Key-Design ist das große Thema, aber drei Einschränkungen erwischen Teams beim ersten Mal:

• Es gibt keine Sekundärindizes. Du kannst nur per Row Key nachschlagen, also entwirfst du den Key für deinen primären Read — und für ein zweites Zugriffsmuster speicherst du dieselben Daten oft erneut unter einem anderen Key oder in einer zweiten Tabelle. Plane bewusste Denormalisierung ein; ein ad-hoc WHERE auf einer Nicht-Key-Spalte gibt es nicht.
• Konsistenz hängt vom Cluster-Setup ab. Eine Single-Cluster-Instanz ist stark konsistent. Multi-Cluster-Replikation ist eventuell konsistent, und du steuerst den Traffic mit App-Profiles. Brauchst du starke Konsistenz über Regionen, ist das Spanner, nicht Bigtable.
• Du zahlst für Nodes × Zeit, plus Speicher. Durchsatz wird bereitgestellt: untätige Nodes kosten trotzdem, also dimensioniere auf die Dauerlast und nutze Autoscaling für Spitzen. Und halte Zeilen hoch, nicht breit — modelliere Events als viele Zeilen und halte jede einzelne Zeile deutlich unter dem ~256-MB-Limit, statt eine riesige Zeile wachsen zu lassen.

Wann man Bigtable NICHT nutzen sollte

Bigtable ist ein Spezialist, und der falsche Workload macht es schmerzhaft:

• Du brauchst SQL-Analytics, Joins oder Ad-hoc-Aggregation → das ist BigQuery. Bigtable scannt und gruppiert dir keine Milliarden Zeilen.
• Du brauchst Multi-Row-Transaktionen oder ein relationales Schema → das ist Spanner. Bigtable garantiert Atomarität nur pro Zeile.
• Du hast kleine Daten oder moderaten Traffic → das Mindest-Cluster und das Betriebsmodell sind Overkill. Ein verwaltetes Postgres (Cloud SQL / AlloyDB) ist einfacher und günstiger.
• Dein Zugriffsmuster ist unvorhersehbar und query-getrieben → ohne klares Key-Zugriffsmuster kämpfst du gegen das Row-Key-Modell, statt es zu reiten.

Bigtable verdient sein Geld im großen Maßstab, auf einem bekannten Key. Darunter gewinnen einfachere Werkzeuge.

Die Feldregel

Passe die Engine an das Zugriffsmuster an, nicht an das „Petabytes“-Etikett. Bigtable für durchsatzstarken Punktzugriff auf einem bekannten Key; BigQuery für SQL-Analytics über riesige Scans; Spanner für relationale Transaktionen; Cassandra oder DynamoDB, wenn du außerhalb von Google Cloud bist. Und wenn du Bigtable wählst, verbring deine Design-Zeit mit dem Row Key — verteile Writes, halte Scans knapp und sortiere deinen Keyspace nie nach Zeit. Alles andere am Skalieren von Bigtable erledigt sich von selbst; der Row Key ist der Teil, den nur du richtig hinbekommen kannst.

Bigtable steht selten allein — meist sitzt es hinter einem Strom von Events, der es mit Writes füttert. Um diesen Ingestion-Pfad sauber zu halten, siehe Pub/Sub oder Eventarc? Event-getriebenes GCP ohne Spaghetti.