Cloud Spanner is one of those Google Cloud services that confuses people on the Professional Cloud Architect exam because it sits in a strange spot. It is a relational database with SQL and ACID transactions, but it scales horizontally across regions like a NoSQL system. Most teams will never need it, and that is exactly why the exam tests whether you can recognize the narrow set of scenarios where it actually fits.
I want to walk through what Spanner is, the workloads it is built for, and how to spot a Spanner question on the Professional Cloud Architect exam.
Spanner is a relational database designed around three properties: global availability, global scalability, and global consistency. The data is always reachable, the database can grow as your application demands more, and every replica stays synchronized so reads return the same answer regardless of which region serves them.
The interesting claim Google makes about Spanner is that it addresses the trade-offs forced by the CAP theorem. CAP says that in a distributed data system you can only fully guarantee two of three properties: Consistency, Availability, and Partition Tolerance. Most distributed databases pick two and accept weaker behavior on the third. Spanner is engineered to deliver strong consistency and high availability while still tolerating network partitions, which is what makes it unusual for a relational system.
For exam purposes, you do not need to understand the underlying mechanics. You need to know that Spanner is the option when someone asks for a relational database that operates globally without giving up consistency.
The workloads Spanner targets share a specific shape. They are transactional, they need strong consistency, and they cannot tolerate the latency or stale reads that come with eventually consistent systems spread across regions.
A globally distributed ledger has to process transactions correctly under heavy concurrency, prevent double-spending, and keep balances accurate in real time. ACID guarantees are not optional here. If two users in different regions hit the same account at the same time, the database has to serialize those writes and produce a single correct outcome.
If a patient is treated in one region and shows up at a hospital in another a day later, the second provider needs the updated record immediately. Stale reads can lead to wrong diagnoses or dangerous prescriptions. The system needs synchronous replication and strong consistency, not eventual consistency that catches up after a few seconds.
Retailers running across multiple warehouses or regions need accurate stock counts everywhere at once. Overselling happens when one node thinks there are still units available while another has already committed the last one. A strongly consistent, scalable database closes that gap.
When players in different regions interact with the same game world, two clients must never see conflicting versions of the state. A strongly consistent backend prevents the situation where one player sees an item picked up and another sees it still available.
The common thread for Spanner workloads is a fixed set of characteristics:
If a scenario does not need all of these together, Spanner is almost certainly the wrong answer. A regional transactional workload is a Cloud SQL job. An analytical workload is BigQuery. A high-throughput non-relational workload is Bigtable. A flexible document store is Firestore. Spanner's footprint is narrow on purpose.
Spanner does not get heavy coverage on the Professional Cloud Architect exam. When it does appear, the question almost always points at the same trigger: the customer needs a relational database with SQL and transactions, the workload spans multiple regions, and they cannot accept the consistency compromises that other globally distributed systems make.
Watch for phrases like "globally distributed", "strong consistency", "ACID transactions across regions", and "horizontal scaling beyond a single instance". When you see those clustered together with a relational requirement, Spanner is the answer.
If the scenario is a single-region OLTP workload, pick Cloud SQL. If it is analytics, pick BigQuery. If it does not need relational features, look at Bigtable or Firestore depending on the access pattern. The exam rewards architects who do not over-reach for Spanner just because it sounds powerful.
My Professional Cloud Architect course covers Cloud Spanner alongside the rest of the databases material.
