The Associate Cloud Engineer exam loves to give you a scenario and ask which database to use. The most common three to choose between are Bigtable, Firestore, and Cloud SQL. They are different in almost every way that matters, which is good news for the exam because the right answer is usually clear once you know what to look for. This article walks through what each one is for, how they differ, and the patterns the exam tests.
It does not cover Spanner, BigQuery, or Memorystore in depth, even though those also come up. Those are different beasts and worth their own treatment. The focus here is the three-way decision the exam most often forces.
Cloud SQL is a managed relational database. It runs MySQL, PostgreSQL, or SQL Server. If you have ever used a relational database before, this is the one that looks familiar.
It is built for transactional workloads. INSERT, UPDATE, DELETE on rows that have foreign keys and constraints. E-commerce orders, banking ledgers, inventory, CRM. Strong consistency, ACID compliance, the things you expect from a real RDBMS.
The catch is scale. A single Cloud SQL instance maxes out at 64 TB of storage, and it is single-region. If you need more than that, or you need writes spread across regions, Cloud SQL is the wrong tool.
Firestore is a managed NoSQL database that stores data as documents in collections. It is the right tool when your data is structured but does not fit neatly into rows and columns, when you need real-time synchronization to clients, and when you want global scale without managing it yourself.
The canonical examples for the Associate Cloud Engineer exam are product catalogs, mobile app user profiles, game save states, and ACID transactions like fund transfers. The common thread is "an application that needs structured data at scale, with real-time sync to clients." Mobile apps, web apps, anything where the client needs to see fresh data without polling.
Firestore supports ACID transactions, which is unusual for a NoSQL database. So if a question says "we need atomic transactions but also real-time mobile sync," Firestore is fine.
Bigtable is also NoSQL, but it is a completely different shape from Firestore. It is a wide-column store designed for very high throughput on very large datasets. Think hundreds of thousands of writes per second, terabytes to petabytes of data.
The canonical use cases are time-series data, IoT sensor ingestion, geospatial data, and real-time content recommendations. The common thread is "large volumes of data flowing in continuously, with predictable access patterns based on a row key."
Bigtable is not for ad-hoc queries. It is not for joins. It does not have a flexible query language. You design your row key around the queries you need, and that row key is the only thing indexed. If you try to use Bigtable like a relational database, you will have a bad time.
Here is the framing that actually works on the Associate Cloud Engineer exam.
If the scenario involves SQL, foreign keys, joins, or a lift-and-shift from MySQL or PostgreSQL, the answer is Cloud SQL. If the data has the shape of a traditional RDBMS, that is the tell.
If the scenario involves a mobile or web application, real-time sync, user profiles, or document-shaped data, the answer is Firestore. The phrase "real-time" is a strong signal toward Firestore.
If the scenario involves time-series data, IoT, sensors, telemetry, very high write throughput, or "billions of rows," the answer is Bigtable. The phrases "high throughput" and "low latency at massive scale" are strong signals toward Bigtable.
The trickiest distinction is Firestore vs Bigtable, because both are NoSQL. The way to keep them separated is the use case. Firestore is for applications that serve users in real time. Bigtable is for analytical and operational workloads that need to ingest and serve massive volumes of data with predictable access patterns. If a question mentions a mobile app, that is Firestore. If it mentions IoT or time-series, that is Bigtable.
The other distinction is Cloud SQL vs Bigtable when scale is at issue. If a scenario describes a relational workload that has outgrown 64 TB, the exam specifically points to Bigtable as one of the options if NoSQL is acceptable, or Spanner if you still need full relational. If the scenario insists on relational and ACID at huge scale, that is a Spanner answer, not a Bigtable answer.
Cloud SQL: relational, MySQL or Postgres or SQL Server, transactional, up to 64 TB, single region.
Firestore: NoSQL, document model, real-time sync, mobile and web apps, global scale, ACID transactions.
Bigtable: NoSQL, wide column, very high throughput, time-series and IoT, terabytes to petabytes, row-key driven.
If you see SQL or relational language, pick Cloud SQL. If you see real-time mobile or web app, pick Firestore. If you see IoT, time-series, or massive throughput, pick Bigtable. The Associate Cloud Engineer exam is consistent about how it telegraphs which one it wants. The hard part is just knowing what each tool is actually for.
My Associate Cloud Engineer course covers all three databases in detail, with the exam-targeted scenarios that come up for each one and the cases where Spanner, BigQuery, or Memorystore would be a better fit instead.
