Cloud SQL vs Spanner vs Bigtable
Cloud SQL, Spanner, and Bigtable all store structured data, but they solve very different problems. Cloud SQL is managed relational, Spanner is globally distributed relational, and Bigtable is massive-scale NoSQL. Choosing wrongly is expensive and hard to reverse, so the Associate Cloud Engineer exam tests whether you can match workload shape to database architecture.
Cloud SQL: managed relational for most applications
Cloud SQL provides fully managed MySQL, PostgreSQL, and SQL Server instances with automated backups, point-in-time recovery, maintenance, replication, and an optional high availability configuration that fails over to a standby in another zone in the same region. For most line-of-business applications, this is the default answer: you keep familiar SQL, drivers, and tools while Google handles patching and backups.
Its limits are architectural. A Cloud SQL primary scales primarily vertically by choosing a larger machine, with read replicas to offload read traffic. It is not designed for global multi-region writes or for petabyte-scale key-value workloads. When a scenario emphasizes regional scope, relational integrity, and minimal migration effort from an on-premises MySQL or PostgreSQL database, Cloud SQL is almost always the intended choice.
- Best for: traditional web apps, e-commerce back ends, CRM, and lift-and-shift databases
- Watch out for: vertical scaling limits and single-region primary by design
- Exam clue: keywords MySQL, PostgreSQL, SQL Server, transactions, and backups point here
Spanner: relational data at global scale
Spanner combines the benefits of relational databases - SQL, schemas, transactions, and strong consistency - with the horizontal scalability normally associated with NoSQL systems. It synchronously replicates data across regions, provides externally consistent transactions, and supports multi-region configurations with extremely high availability targets. That makes it suitable for global applications where users in different continents write to the same logical database without conflicts being resolved later.
The trade-off is cost and design discipline. Spanner instances are priced for scale and are rarely economical for a small regional application. Hotspotting bad primary key choices, such as monotonically increasing keys without thought, can hurt performance, so schema design matters. On the exam, Spanner appears when a scenario explicitly combines global distribution, relational requirements, and strong consistency; if any one of those three is missing, a simpler service is probably correct.
- Best for: global inventory, financial ledgers needing global consistency, gaming state, and multi-region SaaS
- Watch out for: instance cost at small scale and the need to design schemas and primary keys carefully
- Exam clue: keywords globally distributed, strong consistency, SQL, and horizontal scale point here
Bigtable: wide-column NoSQL for massive throughput
Cloud Bigtable is a sparsely populated, wide-column NoSQL database built for very large operational and analytical workloads. It stores data by row key and can scale to petabytes with consistently low latency for key-based reads and writes at high throughput. It is the managed evolution of the technology behind many Google services and is ideal when the access pattern is known: fetch or write rows by key, scan ranges in key order, and process huge volumes fast.
Bigtable is not a general-purpose database. It does not provide relational joins, rich secondary indexes, or multi-row ACID transactions in the relational sense, and its query model is far less flexible than SQL. Cluster sizing and replication are operational decisions you manage more actively than with Cloud SQL or Spanner. Exam scenarios for Bigtable stress scale words - billions of rows, terabytes to petabytes, millions of operations per second - combined with simple access patterns.
- Best for: IoT telemetry, time series, ad serving features, fraud detection lookups, and large-scale personalization
- Watch out for: no SQL joins, limited transactions, and performance that depends heavily on row key design
- Exam clue: keywords wide-column, low-latency lookups, petabytes, and high write throughput point here
How to compare them side by side
A useful exam framework is to ask three questions in order. First, is the workload relational with SQL and transactions? If not, and the scale is massive with key-based access, consider Bigtable. Second, if it is relational, does it need multi-region writes and scale beyond a single primary? If yes, the answer is Spanner; if no, the answer is Cloud SQL. Third, check the distractors: BigQuery may appear in the same options, but it is an analytical warehouse, not an operational database, and Firestore is a document database for application data, not a replacement for any of these three at their core strengths.
- Data model: relational in Cloud SQL and Spanner, wide-column in Bigtable
- Scale: Cloud SQL regional, Spanner global horizontal, Bigtable global-scale throughput
- Consistency: strong in Cloud SQL and Spanner, eventual or strong within Bigtable design patterns depending on replication setup
- Operations: Cloud SQL simplest, Spanner managed but design-sensitive, Bigtable needs cluster planning
How to choose
Choose Cloud SQL for most regional relational applications because it is simple, familiar, and cost-effective. Choose Spanner only when the scenario demands global distribution, strong consistency, and horizontal relational scale together - it solves a harder problem at a higher price. Choose Bigtable for massive, high-throughput, key-based NoSQL workloads such as time series or telemetry. In exam framing, identify the data model first, then the geographic scale, and the correct service usually becomes obvious.
Frequently asked questions
Does a growing application always need Spanner instead of Cloud SQL?
No. Spanner is strongly consistent and globally distributed by design. If your workload is regional, transactional, and fits comfortably within Cloud SQL limits, Cloud SQL is simpler and usually less expensive. Choose Spanner when you need global scale, multi-region writes, or scale beyond a single primary.
Can Bigtable replace a relational database for an application that needs joins?
Not well. Bigtable is a wide-column NoSQL database optimized for high-throughput reads and writes by row key. It does not offer SQL joins, multi-row transactions like a relational database, or ad hoc relational queries. Use it for time series, telemetry, and large-scale operational lookups, not as a drop-in relational replacement.
Which of these databases is best for multi-region relational data?
Cloud SQL, including its high availability configuration, is primarily a regional service with read replicas for scaling reads and for disaster and migration scenarios. Spanner is the Google Cloud relational service designed for multi-region configurations with global strong consistency and very high availability.
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.