Cloud Spanner Study Notes

Cloud Spanner is a fully managed, globally distributed relational database that combines SQL, strong consistency, and horizontal scaling without manual sharding. It is designed for mission-critical applications that outgrow a single-region database in scale or availability. Spanner offers regional and multi-region configurations with very high availability service level agreements.

Key facts

• Spanner provides externally consistent transactions globally, meaning it offers the strongest consistency model while distributing data across zones and regions automatically.
• Data is automatically sharded into splits based on primary keys and load, so choosing a well-distributed primary key, for example using UUIDs instead of sequential IDs, is critical to avoid hotspots.
• Instances are sized in processing units or nodes, and you scale by adjusting that capacity; storage scales automatically as data grows without provisioning fixed disk sizes.
• Multi-region configurations replicate data across multiple regions and can serve reads and writes globally with high availability, at higher cost than a single-region instance.
• Spanner uses a GoogleSQL dialect similar to standard SQL and also offers a PostgreSQL interface for compatibility, but it is not a drop-in MySQL replacement for existing applications.
• Interleaved tables store child rows physically alongside parent rows for efficient joins on hierarchical data, a design concept frequently referenced in schema optimization questions.
• Strong reads return the latest committed data, while stale reads can serve slightly older data with lower latency from replicas, giving applications a consistency versus performance trade-off.
• Backup and restore and point-in-time recovery are built in, allowing recovery to any point within the retention window without managing separate log shipping systems.
• Because Spanner handles replication, failover, and sharding automatically, operational tasks focus on schema design, query optimization, and capacity monitoring rather than server maintenance.

What the exam expects you to know

• Select Spanner when the scenario requires global strong consistency, horizontal write scaling, or availability beyond what a single-region relational database can provide.
• Identify poor primary key choices, such as monotonically increasing timestamps or sequential IDs as the first key column, as the cause of hotspotting in Spanner designs.
• Know that Spanner is relational and SQL-based, distinguishing it from Bigtable and Firestore which are NoSQL and do not offer the same transactional SQL model.
• Understand regional versus multi-region instance configurations and that multi-region improves global availability and latency at increased cost.
• Recognize that Spanner eliminates manual sharding and replica management, so exam answers proposing custom sharding on Cloud SQL are inferior when Spanner fits.
• Remember Spanner is a premium service; for small regional workloads the exam expects Cloud SQL as the more cost-effective correct choice.

Cloud Spanner vs Cloud SQL: when to use which

Use Cloud Spanner when you need a relational database that scales horizontally across regions, maintains strong consistency globally, and supports very high throughput and availability for systems like global inventory, payments, or gaming leaderboards. Use Cloud SQL when the workload is regional, fits comfortably on a single primary, and benefits from native MySQL, PostgreSQL, or SQL Server compatibility at lower cost. The exam trigger words are global, unlimited scale, and strong consistency together, which point to Spanner, while standard application database needs point to Cloud SQL. See also the Cloud SQL notes.

Useful gcloud commands

gcloud spanner instances create my-instance --config=regional-us-central1 --description=MyInstance --processing-units=1000
gcloud spanner databases create my-db --instance=my-instance
gcloud spanner instances list

Common exam traps

• Spanner is not a NoSQL wide-column store; it is fully relational with SQL and transactions, unlike Bigtable which has no joins or multi-row transactions of the same kind.
• Choosing a sequential primary key creates a hotspot on a single split, negating Spanner's distributed scaling advantage, a trap the exam tests repeatedly.
• Spanner is not the cheapest option for a small development database; over-proposing it for simple regional apps contradicts cost-optimization principles.
• Multi-region Spanner still requires thoughtful schema and query design; it does not make inefficient queries or full table scans perform well automatically.

Frequently asked questions

Why does primary key design matter so much in Spanner?

Spanner distributes data by primary key ranges into splits that can live on different servers, so a well spread key balances load across the system. Sequential keys send all new writes to the same split, creating a hotspot and limiting throughput. Using UUIDs, hashed values, or reversing timestamps distributes writes and unlocks horizontal scaling.

Is Spanner suitable for analytics queries?

Spanner is optimized for operational, transactional workloads with strong consistency, not for large analytical scans across billions of rows. For data warehousing and business intelligence, BigQuery is the intended service and can query Spanner data through external connections or exports. The exam separates OLTP in Spanner from OLAP in BigQuery very clearly.

What availability does Spanner offer?

Regional Spanner configurations offer high availability across zones, and multi-region configurations offer even higher availability, up to 99.999 percent at the time of writing, by replicating across regions. Failover is automatic and does not require promoting a read replica manually. This managed resilience is a key reason to choose Spanner for mission-critical global systems.

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.