Home › Associate Cloud Engineer › Section 2: Planning and Configuring a Cloud Solution › Bigtable

Bigtable Study Notes

By the Cloud Cert Notes Editorial Team
Last updated: November 2026

Cloud Bigtable is Google's fully managed, wide-column NoSQL database for very large operational and analytical workloads requiring single-digit millisecond latency. It powers use cases such as IoT ingestion, time-series data, and personalization at petabyte scale. Bigtable separates storage and compute, allowing clusters to scale nodes independently of stored data volume.

Exam tip: If the scenario mentions millions of writes per second, time-series or IoT data, and millisecond latency, answer Bigtable and check the row key for hotspots.

Key facts

Bigtable stores data in tables with rows identified by a row key, column families grouping related columns, and cells versioned by timestamp, forming a sparse wide-column model.
Row key design determines performance completely; keys should be designed for the primary query pattern and avoid hotspots from sequential timestamps or monotonically increasing values at the start of the key.
Clusters consist of nodes that provide compute for serving requests, and adding nodes increases throughput; replication between clusters in different zones or regions provides high availability and read isolation.
Bigtable offers strong consistency within a cluster and eventually consistent replication between clusters by default, with application profiles controlling routing and failover behavior.
It supports single-row transactions and read-modify-write operations, but does not provide SQL, joins, or multi-row transactions like a relational database does.
Storage types are SSD, which is the default for low latency, and HDD for large, batch-oriented workloads where cost matters more than performance, chosen at instance creation.
Common integrations include Dataflow for streaming ingestion, Dataproc and Apache HBase API compatibility for migration from on-premises HBase, and BigQuery for external querying.
Throughput scales linearly with nodes for well-designed schemas, handling millions of reads and writes per second for IoT, ad serving, and financial time-series workloads.
Garbage collection policies on column families control how many versions or how old cell versions are retained, preventing unbounded growth from timestamped cell versions.

What the exam expects you to know

Choose Bigtable for high-throughput, low-latency NoSQL workloads over one terabyte, especially time-series, IoT, and event data with simple key-based lookups and scans.
Diagnose hotspotting from poor row keys, such as starting with a timestamp, and propose reversing, hashing, or prefixing with a high-cardinality identifier instead.
Know that Bigtable has no SQL and no secondary indexes like a relational system, so query patterns must be planned around the row key and column families.
Use replication and app profiles to isolate analytical batch reads from operational traffic and to provide regional failover without impacting production latency.
Distinguish Bigtable from BigQuery: Bigtable is for operational serving at low latency, BigQuery is for analytical SQL over large datasets at higher latency per query.
Remember node count drives performance and cost; exam scenarios about increasing throughput without changing storage point to adding nodes to the cluster.

Bigtable vs Firestore: when to use which

Use Bigtable when you need petabyte-scale, high-throughput, low-latency storage for time-series, IoT, or operational data accessed mainly by row key, and your team can design the schema around query patterns. Use Firestore when you need a document database with rich queries, real-time listeners, offline sync for mobile and web apps, and automatic scaling without managing cluster nodes. The exam signal is workload shape: massive ingestion and scans favor Bigtable, while user-facing app data with flexible queries and SDK-driven development favors Firestore. See also the Firestore notes.

Useful gcloud commands

gcloud bigtable instances create my-instance --display-name=MyInstance --production-type=PRODUCTION --cluster-config-file=cluster.json
cbt -instance=my-instance createtable my-table
cbt -instance=my-instance read my-table

Common exam traps

Bigtable is not a relational database and does not support joins or SQL; proposing it for a transactional application needing complex relational queries is incorrect.
A row key starting with a timestamp creates hotspots because new writes concentrate on one tablet; this design flaw appears frequently as an exam distractor.
Bigtable and BigQuery sound similar but serve opposite purposes; low-latency operational serving is Bigtable, serverless analytics warehousing is BigQuery.
Adding storage does not add throughput automatically; throughput is governed by nodes, so scaling performance means scaling the cluster, not the disk.

Frequently asked questions

What makes a good Bigtable row key?

A good row key distributes writes evenly and matches the main query pattern, often starting with a high-cardinality identifier like a device or user ID, followed by a reversed timestamp for time ordering. This avoids hotspots and allows efficient scans for a single entity over time. Poor keys that start with timestamps concentrate load and destroy performance at scale.

Does Bigtable support SQL queries?

No, Bigtable does not offer SQL, joins, or flexible secondary indexing; access is primarily by row key, key range scans, and column family filters through its API or HBase compatibility layer. If a scenario requires ad hoc SQL analytics, the exam expects BigQuery instead. Bigtable design starts from known access patterns, not exploratory querying.

When is Bigtable too much for a workload?

Bigtable is optimized for very large datasets, typically over one terabyte, and high throughput, so it is cost-inefficient for small applications or low-volume document storage. For smaller NoSQL needs with rich queries or mobile sync, Firestore is the better fit. The exam penalizes over-engineering, so match the database size and throughput to the scenario described.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.