Google Cloud Spanner
Google Cloud Spanner is GCP's globally distributed relational database — and a genuinely unusual one: it offers the horizontal scalability of NoSQL together with the strong consistency, SQL, and ACID transactions of a traditional relational database, across regions and continents. For decades this combination was considered impossible (the CAP theorem forcing a choice); Spanner, built on Google's TrueTime technology, delivers externally-consistent transactions at global scale. It powers Google's own massive systems (Ads, Play) and is the archetype of the "NewSQL" category.
Spanner solves a specific, hard problem: applications that need relational data with strong consistency but have outgrown a single-node database's scaling limits. Where you'd normally choose between a scalable NoSQL store (losing SQL/consistency) or a relational database (hitting a scaling ceiling), Spanner gives both — at a premium price and with real design constraints. It's overkill for most applications and transformative for the few that genuinely need global-scale consistent relational data. The database fundamentals apply; this is Google's distributed-SQL flagship.
TL;DR
- Spanner is a globally distributed, strongly consistent, horizontally scalable relational database — SQL + ACID transactions + NoSQL-like scale, across regions.
- It resolves the usual trade-off: you don't choose between scale and consistency — Spanner provides both, at global scale.
- Powered by TrueTime — Google's globally-synchronized clock (GPS + atomic clocks) that enables externally-consistent transactions across the planet.
- It's the archetypal "NewSQL" database — relational semantics with distributed-systems scalability.
- The trade-offs: high cost, real design constraints (schema/interleaving, avoiding hotspots via good primary keys), and it's genuine overkill for most apps.
- Use Spanner when you truly need global scale + strong consistency + relational together; for most workloads, Cloud SQL/PostgreSQL is simpler and far cheaper.
Core Concepts
The Problem Spanner Solves
Traditionally, databases forced a choice as you scaled:
You either scaled up a relational database until it couldn't grow further (then sharded painfully, losing cross-shard transactions), or adopted NoSQL and gave up SQL, joins, and strong consistency. Spanner refuses the trade-off — it scales horizontally like NoSQL while keeping relational semantics and strong (externally-consistent) transactions globally.
TrueTime: How It Works
The magic behind global consistency is TrueTime — Google's infrastructure of GPS receivers and atomic clocks in every datacenter that gives Spanner a globally-synchronized notion of time with a bounded uncertainty. By knowing time accurately (within a tight, known error bound) everywhere, Spanner can assign globally-meaningful timestamps to transactions and guarantee external consistency (transactions appear in a consistent global order) without the coordination overhead that would otherwise make global ACID impractical. This clock infrastructure is what makes Spanner possible and why it was long considered a Google-only capability.
NewSQL and Relational Features
Spanner is "NewSQL" — it provides:
- SQL (GoogleSQL and PostgreSQL-dialect interfaces) with joins, secondary indexes, and familiar querying.
- ACID transactions — including across rows, tables, and regions (strong consistency, not eventual).
- Schemas with relational structure, plus table interleaving (co-locating related rows for performance).
- Horizontal scalability — add capacity (nodes/processing units) and Spanner redistributes data automatically, no manual sharding.
You get a database that feels relational to developers but scales like a distributed system — the best of both, which is exactly why it's expensive.
Design Constraints
Spanner's power comes with real constraints you must design for:
- Primary key design to avoid hotspots — like Cosmos DB/DynamoDB partition keys, monotonically increasing keys (timestamps, sequential IDs) funnel writes to one place, creating hotspots that limit scale. Use well-distributed keys (hashed prefixes, UUIDs) for high-write tables.
- Interleaving — co-locate child rows with parents (interleaved tables) for efficient joins/locality, a Spanner-specific modeling technique.
- Cost awareness — it's billed by compute (nodes/processing units) + storage; it's expensive, and over-provisioning wastes significant money.
When Spanner Is (and Isn't) Worth It
Use Spanner when you genuinely need all of:
- Global scale (beyond a single relational database's ceiling), and
- Strong consistency and ACID transactions, and
- Relational data with SQL.
This describes large-scale financial systems, global inventory/ordering platforms, multi-region applications needing consistent transactions, and workloads that have outgrown sharded relational setups. For these, Spanner is uniquely valuable.
Don't use Spanner when:
- A single Cloud SQL/PostgreSQL instance (which scales impressively far) meets your needs — it's simpler and far cheaper.
- You need scale but not strong consistency — NoSQL options are cheaper.
- You're a typical application — Spanner is overkill; most apps never approach the scale that justifies it.
The honest guidance: most applications should not use Spanner. Start with Cloud SQL; reach for Spanner only when you've genuinely hit the wall where scale and strong relational consistency are both non-negotiable. Choosing it prematurely means paying a large premium and accepting design constraints for capabilities you don't need.
Common Mistakes
Using Spanner When Cloud SQL Would Do
The biggest mistake: adopting Spanner's cost and complexity for an app that a single Cloud SQL/PostgreSQL instance handles easily. Postgres scales much further than people assume. Spanner is for when you've truly exhausted single-node relational scaling and need strong consistency — a threshold most applications never reach.
Hotspot-Prone Primary Keys
Sequential or monotonically increasing keys (auto-increment IDs, timestamps) concentrate writes on one server, creating hotspots that cap Spanner's scalability. Use well-distributed keys (hash prefixes, UUIDs, bit-reversed sequences) for high-write tables. This is the #1 Spanner performance mistake — the same partition-key discipline as any distributed database.
Ignoring Interleaving and Locality
Not using interleaved tables to co-locate related data (parent/child rows) means joins and related-row access fetch across the distributed store inefficiently. Model with interleaving where locality matters — a Spanner-specific technique for performance.
Under-Modeling Costs
Spanner bills by provisioned compute (nodes/processing units) plus storage, and it's expensive. Over-provisioning nodes, or adopting it without modeling the cost, produces large bills. Right-size compute (Spanner supports granular processing units, not just full nodes), and factor the premium into the decision. See cloud costs.
Treating It as a Drop-In Postgres
While Spanner offers a PostgreSQL dialect, it's a distributed database with its own constraints (key design, interleaving, some feature differences). Migrating a Postgres app expecting identical behavior hits surprises. Design for Spanner's distributed nature rather than assuming full Postgres parity.
FAQ
What makes Spanner special?
It combines things long thought incompatible: the horizontal scalability of NoSQL with the SQL, strong consistency, and ACID transactions of relational databases, across regions globally. Traditionally you chose scale or consistency; Spanner delivers both, using Google's TrueTime clock infrastructure to make global externally-consistent transactions practical. It's the archetype of the "NewSQL" category.
What is TrueTime?
Google's globally-synchronized time infrastructure — GPS receivers and atomic clocks in datacenters that give Spanner an accurate, bounded-uncertainty notion of time everywhere. By knowing time precisely across the globe, Spanner assigns consistent transaction timestamps and guarantees external consistency without prohibitive coordination overhead. It's the technical foundation that makes global ACID at scale possible and was long a Google-only capability.
Should I use Spanner or Cloud SQL?
Cloud SQL (PostgreSQL/MySQL) for the vast majority of applications — it's simpler, far cheaper, and scales further than most people expect. Choose Spanner only when you genuinely need global scale and strong consistency and relational SQL together — a high bar most apps never reach. Don't pay Spanner's premium and accept its constraints for capabilities you don't need; start with Cloud SQL and escalate only if you truly outgrow it.
Is Spanner NoSQL or SQL?
SQL — it's a relational database with SQL, joins, schemas, secondary indexes, and ACID transactions. It borrows NoSQL's scalability (horizontal distribution, automatic sharding) but keeps relational semantics. This is why it's called "NewSQL": relational database capabilities with distributed-systems scale, rather than the NoSQL trade-off of giving up SQL/consistency for scale.
Why is Spanner so expensive?
It provides a genuinely hard capability (global strong consistency at relational scale) backed by specialized infrastructure (TrueTime, global replication), billed by provisioned compute plus storage with a high floor. The cost reflects the unique value — but it means Spanner only makes economic sense when you truly need what it offers. For workloads that don't require global-scale consistent relational data, cheaper options (Cloud SQL, NoSQL) are the right call.
Related Topics
- Google Cloud SQL — The simpler, cheaper relational option (start here)
- Databases — Relational vs NoSQL fundamentals
- Database Transactions — ACID and consistency concepts
- PostgreSQL — Single-node relational (and Spanner's PG dialect)
- Azure Cosmos DB — A globally-distributed (NoSQL) counterpart
- Scalability — Horizontal scaling and sharding
- Google Cloud — The provider overview