Cloud Spanner vs Cloud SQL: When to Use Each
Fast recall
Quick revision
Core answer
Understanding of distributed database trade-offs and the ability to recommend the right data store based on requirements rather than defaulting to the most expensive option.
Recommending Spanner for every use case due to its impressive specs, ignoring cost (Spanner is 10–100x more expensive than Cloud SQL for small workloads) or its proprietary SQL dialect quirks.
Mention TrueTime, Spanner's external consistency mechanism, and discuss JDBC driver options for both services in Java.
Interview-ready guide
Interview answer
Cloud SQL and Cloud Spanner are both relational databases on GCP, but they occupy completely different parts of the spectrum — Cloud SQL is a managed traditional RDBMS; Cloud Spanner is a globally distributed, horizontally scalable relational database.
Cloud SQL — managed PostgreSQL and MySQL
- Cloud SQL manages PostgreSQL, MySQL, or SQL Server with automatic backups, point-in-time recovery, read replicas, and failover — which means Spring Data JPA and Hibernate work with no code changes; you choose the instance size and Cloud SQL handles the rest
- Cloud SQL scales vertically — you move to a larger machine class (more CPU, more RAM); there's a ceiling at the largest available instance, and scaling up requires a brief restart
Cloud Spanner — horizontally scalable, strongly consistent
- Cloud Spanner splits data across nodes automatically using range-based sharding on the primary key — adding nodes increases both storage and throughput linearly, which means you scale write capacity by adding nodes rather than upgrading hardware
- Cloud Spanner offers external consistency — the strongest consistency model, equivalent to serializable isolation with globally synchronized timestamps; every read sees all committed writes regardless of which region processed them
- The trade-off is higher latency for write commits (2-4ms single-region, 100ms+ multi-region) due to Paxos consensus across nodes; Cloud SQL commit latency is sub-millisecond in most cases
Choosing between them
- Cloud SQL: standard relational workloads, OLTP applications with Spring Data JPA, datasets under a few TB that fit comfortably on one large instance; most Spring Boot services live here
- Cloud Spanner: applications that need horizontal write scale beyond what a single database node can handle, global applications requiring strong consistency across regions, or regulated industries requiring a fully managed database without maintenance windows
Spring Data integration
- Cloud SQL: standard JDBC driver; no code changes from a self-hosted database
- Cloud Spanner: use the Spanner JDBC driver or Spring Data Spanner (
spring-cloud-gcp-starter-data-spanner) — some JPA features (auto-increment, sequences) work differently due to Spanner's schema constraints
Cloud Spanner vs Cloud SQL: When to Use Each
Direct Answer
Cloud Spanner is a globally distributed, horizontally scalable, strongly consistent relational database that handles millions of transactions per second across regions. Cloud SQL is a managed single-region PostgreSQL/MySQL instance suited for standard web application workloads. Choose Spanner when you need horizontal write scaling or multi-region strong consistency; use Cloud SQL when you need a familiar SQL dialect, lower cost, and simpler operation at moderate scale.
Common Mistakes & Pitfalls
Recommending Spanner for every use case due to its impressive specs, ignoring cost (Spanner is 10–100x more expensive than Cloud SQL for small workloads) or its proprietary SQL dialect quirks.
Check your understanding
Answer these without looking back at the article.
- How do you avoid hotspots when designing primary keys in Cloud Spanner?
- How does the Cloud SQL Java Connector differ from using the Cloud SQL Auth Proxy?
- What is TrueTime and how does it enable external consistency in Spanner?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.