Bigtable and Cloud SQL solve different problems. Cloud SQL is a managed relational database for transactional workloads, with the structure and consistency you expect from MySQL or PostgreSQL. Bigtable is a NoSQL wide-column store designed for very high throughput on very large datasets, with no joins and only one index, the row key. The Associate Cloud Engineer exam tests this comparison, and the right answer is almost always clear from the scenario once you know what to look for. This article covers the difference and the specific signals the exam uses.
It does not cover Spanner, BigQuery, or Firestore, which can both also come up in these scenarios. The focus is the Bigtable-versus-Cloud-SQL decision specifically.
Cloud SQL is a managed version of MySQL, PostgreSQL, or SQL Server. It supports SQL with all the usual features. Foreign keys, joins, ACID transactions, secondary indexes, complex queries. It is what most people picture when they hear "database."
The fit is transactional workloads. E-commerce orders. Bank ledgers. CRM. Inventory systems. Anything where the data is structured into related rows and tables, where consistency matters, and where the queries are a mix of single-row lookups and joins.
The constraint is scale. A single Cloud SQL instance maxes out at 64 TB of storage. It is single-region. Beyond that scale, Cloud SQL is the wrong tool.
Bigtable looks nothing like a relational database. There is no SQL. There are no joins. There is no schema in the relational sense. There is one index, the row key, and that is it. Anything you want to query has to be encoded into the row key, or you have to do a full scan.
What Bigtable does, it does extremely well. It can ingest hundreds of thousands of writes per second, store petabytes of data, and serve reads with consistent low latency. The fit is workloads where the volume and the velocity of the data are the dominant concerns, and the access patterns are predictable enough that you can design row keys around them.
The Associate Cloud Engineer exam gives the canonical Bigtable use cases: time-series data like stock prices, IoT sensor ingestion, geospatial data, real-time content recommendations. The common thread is high throughput, large volume, predictable row-key-based access.
If the workload involves joins, foreign keys, ad-hoc SQL queries, or arbitrary filtering across many fields, that is Cloud SQL. The relational model is what makes those access patterns efficient.
If the workload involves looking up data by a single key or by a range of keys, with very high read or write throughput, that is Bigtable. The row-key-only index is what makes high throughput possible.
If a scenario describes a workload that has outgrown 64 TB, Cloud SQL is out. The exam specifically points to Bigtable as one of the alternatives, on the condition that NoSQL is acceptable. If the workload also requires full ACID and relational structure, the right answer is Spanner instead. But if NoSQL is fine, Bigtable handles the scale that Cloud SQL cannot.
If a scenario mentions throughput in the hundreds of thousands of writes per second, that is Bigtable territory. Cloud SQL cannot do that on a single instance.
Both Cloud SQL and Bigtable offer strong consistency on a single row, which is the consistency people usually care about. Cloud SQL goes further with multi-row, multi-table ACID transactions, which is what makes things like fund transfers work correctly. Bigtable does not offer transactions across rows.
If a scenario requires multi-row atomic transactions, that rules Bigtable out. Cloud SQL or Spanner is the answer. If single-row consistency is enough and the scale is large, Bigtable is fine.
"A retail company needs to track orders, customers, and inventory with foreign keys and complex queries." Cloud SQL. The relational structure is the tell.
"An IoT platform ingests 200,000 sensor readings per second from millions of devices." Bigtable. The throughput and the IoT framing both point there.
"A financial services firm needs to process trades with multi-row atomic transactions." Cloud SQL or Spanner, not Bigtable.
"A streaming service needs to track user behavior in real time and serve content recommendations based on it." Bigtable. The scale and the access pattern both fit.
"A small business needs a managed relational database for their existing MySQL application." Cloud SQL. Lift-and-shift relational workloads are the canonical Cloud SQL fit.
Bigtable is for high-throughput NoSQL workloads with predictable row-key-based access. Cloud SQL is for transactional relational workloads up to 64 TB. If a question feels like it could go either way, look for the scale, the access pattern, and whether SQL or joins are mentioned. The Associate Cloud Engineer exam telegraphs this consistently.
Bigtable and Cloud SQL are not really competing for the same workload. They look like alternatives only because they both store data. In practice, a workload that fits one is almost always wrong for the other. Once you can read a scenario and ask "is this relational and bounded, or is this throughput-heavy and key-based," the answer falls out.
My Associate Cloud Engineer course covers the full database decision space the Associate Cloud Engineer exam tests, including where Spanner, BigQuery, and Firestore fit in alongside Bigtable and Cloud SQL.
