Bigtable

Exam guide§2.2

Petabyte-scale wide-column NoSQL for high-throughput, low-latency single-key reads/writes. No SQL, no joins, no transactions across rows. Pick it for time-series, IoT, AdTech, and financial data - heavy read + write at scale.

⇄CompareBigtable vs BigQuery - one letter, opposite jobs

BigtableOperational NoSQL: low-latency single-row reads/writes, no SQL analytics.

BigQueryAnalytical warehouse that scans huge tables with SQL.

If the question says "analytics/reporting/dashboard", it's BigQuery - not Bigtable.

⚠GotchaBigtable never scales to zero

Bigtable bills for provisioned nodes even when idle - not a fit for small or intermittent workloads.

It is the same database that powers Google Search, Analytics, Maps, and Gmail, and it works for both operational and analytical apps. It integrates with the big-data tooling teams already use - Hadoop, Dataflow, and Dataproc - and speaks the open-source HBase API.

⚠GotchaHBase API compatibility is a portability signal

If a question asks for a managed store that is compatible with the HBase API, that is Bigtable. Existing HBase code and tooling can point at Bigtable with minimal change.

Storage model

Data lives in massively scalable tables, each a sorted key/value map. A table is made of rows (one entity each) and columns (the values). Every row is indexed by a single row key; related columns are grouped into a column family, and each column is identified by the column family plus a column qualifier (a unique name within that family).

Each row is keyed by a username; related columns live in the "follows" column family, where each column qualifier is another username. A blank cell stores nothing, so the table is sparse. A single cell can hold multiple timestamped versions.

Each row/column intersection can hold multiple cells - versions at different timestamps - giving a history of how a value changed. Tables are sparse: an empty cell costs no storage, so it is cheap to add new column qualifiers as your data evolves. In the example the qualifiers are themselves usernames, which is what lets the "follows" graph grow without schema changes.

⚠GotchaRow key design drives access uniformity

Data is distributed by row key. A key that spreads evenly (here, usernames across the alphabet) keeps reads and writes uniform across the table; a monotonic key (a timestamp prefix) creates hotspots.

Architecture

Bigtable separates processing from storage. Requests hit a frontend server pool and a set of nodes; the data itself sits on Colossus, Google's file system. A table is sharded into blocks of contiguous rows called tablets (the equivalent of HBase regions), stored in SSTable format - a persistent, ordered, immutable map from keys to values, both arbitrary byte strings.

Processing (the frontend pool and Bigtable nodes) is separate from storage: a table is sharded into tablets, stored as immutable SSTables on the Colossus file system. When one node handles a hot subset, Bigtable rebalances tablets across nodes so throughput stays even.

Because nodes hold no data, Bigtable learns access patterns: if one node keeps serving a hot subset, it updates the tablet-to-node indexes so other nodes absorb the load. Nothing is copied or moved on disk - only the pointers change.

⚠GotchaRebalancing moves pointers, not data

Tablets stay put on Colossus; only the node that serves each tablet changes. That is why rebalancing is fast and why adding a node adds throughput without a data migration.

Scaling

Throughput scales linearly: every node you add contributes a fixed increment of queries per second (QPS), up to hundreds of nodes.

Throughput scales linearly with node count - each node adds a fixed QPS increment, up to hundreds of nodes.

#NumbersCluster sizing

• Minimum cluster: 3 nodes
• Throughput per minimum cluster: ~30,000 operations/second
• Scale ceiling: linear up to hundreds of nodes
• Latency target: less than 10 ms read/write
• Data threshold: favour Bigtable above 1 TB of structured data

Recap

Any "yes" points to Bigtable; only when every answer is "no" do you fall through to Firestore. Bigtable scales up well, Firestore scales down well.

⇄CompareRemember: Bigtable scales UP, Firestore scales DOWN

This is the one-line tiebreaker for the whole decision.

Bigtable scales UPReach for it as volume, write throughput, and data size climb.

Firestore scales DOWNReach for it when the workload is small or intermittent and should cost little (even nothing) when idle.

?DECISIONBigtable or Firestore?

More than 1 TB of structured data, very high write volume, sub-10 ms latency→Bigtable

Need HBase API compatibility→Bigtable

Small or intermittent workload that should scale down (even to zero cost)→Firestore

Pick this when: size and write volume first, then the compatibility need