Google Spanner - Learning Module

Loading content...

0/273

When to Use Spanner

The Right Tool for the Right Problem

Google Spanner is a remarkable engineering achievement—a globally distributed database with strong consistency, SQL semantics, and horizontal scalability. It solves problems that were previously considered unsolvable. But remarkable doesn't mean universal.

Every database is a collection of tradeoffs. Spanner trades single-region latency for global consistency. It trades operational simplicity for distributed resilience. It trades commodity pricing for premium guarantees. Understanding when these tradeoffs favor Spanner—and when they don't—is essential for making sound architectural decisions.

In this final page, we'll synthesize everything we've learned into practical decision-making guidance. You'll learn to recognize the use cases where Spanner excels, understand the scenarios where alternatives might serve better, and develop a framework for evaluating Spanner against your specific requirements.

What You Will Learn

By the end of this page, you will be able to evaluate whether Spanner is appropriate for a given use case, understand the tradeoffs involved in choosing Spanner, and make informed decisions about global database architecture.

Ideal Use Cases for Spanner

Spanner shines brightest when your requirements include multiple factors that traditional databases struggle to provide simultaneously.

1. Global User Base with Consistency Requirements:

If your users span continents and require consistent views of shared data, Spanner is a strong candidate:

Financial services: Trading platforms, payment systems, banking applications where users in different regions must see consistent account states
Gaming platforms: Multiplayer games where global leaderboards, inventories, and game state must be consistent
Enterprise collaboration: Document systems, project management tools where distributed teams work on shared data

2. Mission-Critical Data with Zero Tolerance for Inconsistency:

When data correctness is non-negotiable:

Transaction processing: Any system where incorrect data could cause financial loss or legal liability
Healthcare systems: Patient records that must be accurate across all access points
Inventory management: Systems where overselling or double-booking is unacceptable

3. Regulatory Requirements for Data Residency:

Spanner's configurable replication excels when:

EU users' data must remain in EU (GDPR)
Financial data must be stored in-country
Different regions have different data sovereignty requirements
You need compliance AND global availability simultaneously

4. Scaling Beyond Single-Machine Limits:

When data volume or transaction rate exceeds what traditional databases can handle:

Datasets in the hundreds of terabytes to petabytes
Transaction rates in the hundreds of thousands per second
Write-heavy workloads that can't be handled by a single primary

Spanner Ideal Fit Indicators
Requirement	Why Spanner Fits	Alternatives Struggle Because...
Global consistency	TrueTime + external consistency	Other systems can't order transactions globally
Horizontal write scaling	Distributed Paxos groups	Traditional SQL has single-writer bottleneck
SQL + scale	Full SQL semantics, automatic sharding	NoSQL sacrifices SQL; SQL databases don't auto-shard
Data residency + availability	Configurable per-row replication	Most databases: pick one region OR accept data spreading
Zero-downtime operations	Automatic rebalancing, online schema change	Traditional databases require maintenance windows

The Compounding Effect

Spanner becomes increasingly compelling as requirements compound. Global users + consistency + scale + compliance together make Spanner nearly unique. Any single requirement might be met by simpler solutions.

When Spanner May Not Be the Best Choice

Spanner's power comes with costs—financial, complexity, and latency. For many use cases, simpler or cheaper alternatives serve better.

1. Single-Region Deployments:

If all your users and data are in one region:

Spanner's global distribution provides no benefit
You're paying for TrueTime infrastructure you don't need
A well-tuned PostgreSQL or MySQL likely offers lower latency
Regional cloud databases (Cloud SQL, RDS) cost significantly less

Consider instead: PostgreSQL, MySQL, Cloud SQL, or regional CockroachDB.

2. Cost-Sensitive Workloads:

Spanner pricing reflects its premium capabilities:

Node-hours are expensive compared to traditional databases
Multi-region configurations multiply costs
Read-heavy workloads might be served cheaper by replicated traditional databases

Consider instead: Traditional databases + read replicas, or managed databases like Supabase, PlanetScale.

3. Extremely Low-Latency Requirements:

Spanner's consistency comes with latency:

Commit-wait adds 4-7ms to every write
Multi-region transactions add 100-300ms latency
For sub-millisecond requirements, in-memory databases may be necessary

Consider instead: Redis for caching, single-region databases for hot paths.

4. Simple, Non-Relational Data:

If your data model doesn't benefit from relational features:

Key-value workloads may be simpler on DynamoDB or Redis
Document stores like MongoDB may offer easier data modeling
Time-series databases may be better for metric workloads

Consider instead: DynamoDB, MongoDB, InfluxDB, or specialized databases.

Warning Signs: Spanner May Be Overkill

•"We might need global someday" — Design for current needs; migration is possible if requirements change.
•"We want the best database" — Best is context-dependent. Spanner is best for specific use cases.
•"Everyone uses it" — Most workloads don't need Spanner's capabilities. Follow your requirements, not trends.
•All users in one country — Global distribution benefits disappear without global users.
•Small data volumes — If your data fits comfortably on one server, you're paying for distributed overhead.
•Eventual consistency is acceptable — If you can tolerate stale reads, cheaper options exist.

The YAGNI Principle

You Aren't Gonna Need It. Choosing Spanner for future requirements that may never materialize wastes money today. Start with simpler solutions; migrate if and when requirements genuinely demand Spanner's capabilities.

Spanner vs. Alternatives

Let's compare Spanner directly with alternatives for common decision scenarios.

Spanner vs. CockroachDB:

CockroachDB is an open-source, Spanner-inspired distributed SQL database.

Aspect	Spanner	CockroachDB
Consistency	External (TrueTime)	Serializable (logical clocks)
Deployment	GCP managed only	Self-hosted or managed
Clock Sync	GPS + atomic clocks	Software-only (higher uncertainty)
Cost	Premium	Lower (especially self-hosted)
Vendor Lock-in	GCP-only	Multi-cloud, on-prem

Choose Spanner when: You need absolute best consistency, you're all-in on GCP, or Google's operational expertise matters.

Choose CockroachDB when: Multi-cloud/on-prem matters, cost is a priority, or you want to avoid vendor lock-in.

Spanner vs. Aurora (Global Database):

AWS Aurora Global Database offers cross-region replication.

Aspect	Spanner	Aurora Global
Write Scaling	Distributed (any region)	Single-primary (one region writes)
Consistency	External consistency	Eventual across regions
Read Latency	Stale: local. Strong: leader.	Secondary: stale. Primary: strong.
Cross-Region Writes	Native	Not supported (failover only)

Choose Spanner when: You need multi-region writes or global strong consistency.

Choose Aurora when: Single-region writes are acceptable, you're on AWS, or MySQL/PostgreSQL compatibility matters.

Database Selection Guide by Use Case
Use Case	Best Choice	Rationale
Single-region OLTP	PostgreSQL/MySQL (managed)	Simpler, cheaper, lower latency
Multi-region reads, single-region writes	Aurora Global/AlloyDB	Read replicas cheaper than Spanner for this pattern
Multi-region writes, strong consistency	Spanner or CockroachDB	These are designed for this use case
Multi-region writes, eventual consistency OK	DynamoDB Global Tables	Cheaper, simpler for this consistency level
GDPR compliance + global availability	Spanner	Configurable replication per row/region
Massive scale, simple queries	DynamoDB or Cassandra	Optimized for scale over SQL features
Time-series data	TimescaleDB/InfluxDB	Purpose-built for time-series access patterns

Spanner vs. DynamoDB (Global Tables):

DynamoDB is AWS's managed NoSQL database with global tables for multi-region replication.

Aspect	Spanner	DynamoDB Global Tables
Data Model	Relational (SQL)	Key-value/Document
Consistency	Strong + external	Eventually consistent (default)
Cross-Region	Strong consistency	Last-writer-wins
Query Model	Full SQL	Limited (scan/query by key)
Pricing	Node-hours	On-demand or provisioned capacity

Choose Spanner when: You need relational features, complex queries, or strong cross-region consistency.

Choose DynamoDB when: Simple access patterns, eventual consistency is fine, or you're on AWS.

The Hybrid Approach:

Many large systems use multiple databases:

Spanner for critical transactional data (orders, accounts, inventory)
DynamoDB for high-volume, simple-access data (session state, user preferences)
Redis for caching and real-time data
BigQuery/Snowflake for analytics

Don't feel compelled to use one database for everything.

No Silver Bullet

Every database excels at something and compromises on something else. The goal is matching database strengths to your requirements, not finding a universal solution.

Cost Considerations

Spanner's pricing model differs from traditional databases, and understanding it is essential for accurate budgeting.

Pricing Components:

1. Compute (Node-Hours):

Charged per node-hour (nodes are the unit of compute capacity)
More nodes = more throughput and storage capacity
Multi-region configurations require more nodes for same throughput
Minimum: 1 node for regional, 3 nodes for multi-regional

2. Storage:

Charged per GB-month
Includes data + indexes + internal metadata
Replicas are included (not charged separately)

3. Network:

Cross-region traffic is charged
Inter-zone traffic within a region is often free
Egress to internet is charged

4. Backup and Restore:

Backup storage charged separately
Point-in-time recovery has per-GB costs

Illustrative Cost Comparison (approximate, verify current pricing)
Database	Small Workload (1TB, 1K QPS)	Medium Workload (10TB, 10K QPS)	Large Workload (100TB, 100K QPS)
Spanner (Regional)	$1,000-2,000/month	$4,000-8,000/month	$30,000-60,000/month
Spanner (Multi-Region)	$3,000-5,000/month	$12,000-20,000/month	$80,000-150,000/month
Cloud SQL (PostgreSQL)	$300-600/month	$1,500-3,000/month	$10,000-20,000/month
CockroachDB Serverless	$500-1,000/month	$2,000-5,000/month	$15,000-40,000/month
DynamoDB On-Demand	$200-500/month	$1,000-3,000/month	$8,000-25,000/month

Cost Optimization Strategies:

1. Right-Size Regional vs. Multi-Regional:

Use regional configurations where multi-region isn't required
Consider dual-region for DR without full multi-region costs

2. Leverage Stale Reads:

Stale reads don't require leader coordination
Can reduce node requirements for read-heavy workloads

3. Efficient Schema Design:

Interleaving reduces multi-split transactions (lower latency = fewer nodes needed)
Appropriate indexing reduces scan costs

4. Batch Operations:

Batch reads and writes reduce per-operation overhead
Partitioned DML for bulk updates

5. Archive Cold Data:

Move historical data to cheaper storage (BigQuery, Cloud Storage)
Keep only active data in Spanner

When Cost Premium is Justified:

Spanner's premium pricing can be justified when:

Downtime costs exceed the cost difference (high-availability value)
Consistency issues would cause business harm (correctness value)
Operational overhead of alternatives exceeds price difference (productivity value)
Scaling challenges of alternatives limit growth (opportunity value)

Total Cost of Ownership

Compare total cost including operations, not just database pricing. Spanner's automation reduces operational overhead significantly. A cheaper database requiring a dedicated DBA may cost more overall.

Migration Considerations

Migrating to Spanner requires careful planning due to its unique characteristics.

Schema Adaptation:

Spanner's schema differs from traditional SQL databases:

1. Primary Keys:

Every table must have a primary key (no implicit rowid)
Primary key choice profoundly affects performance
Auto-increment IDs should be replaced with UUIDs or application-generated keys

2. Interleaving:

Parent-child relationships should use interleaved tables
Requires schema redesign, not just migration

3. Data Types:

Spanner has a specific set of data types
Some conversions may be needed (e.g., ENUM to STRING, DECIMAL precision limits)

4. Secondary Indexes:

Interleaved vs. non-interleaved indexes have different performance characteristics
Index design may need reconsideration

schema-migration-example.sql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
-- BEFORE: Traditional PostgreSQL Schema
 
CREATE TABLE users (
    id SERIAL PRIMARY KEY,  -- Auto-increment: BAD for Spanner
    email VARCHAR(255) UNIQUE,
    name VARCHAR(100),
    created_at TIMESTAMP DEFAULT NOW(),
    settings JSONB  -- Not directly supported in Spanner
);
 
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),  -- Soft reference
    total DECIMAL(10, 2),
    status VARCHAR(20),
    created_at TIMESTAMP DEFAULT NOW()
);
 
-- Separate tables, no physical locality guarantee

Migration Strategies:

1. Dual-Write Migration:

Write to both old and new databases during transition
Gradually shift reads to Spanner
Validate data consistency
Cut over when confident

2. Snapshot + CDC Migration:

Take initial snapshot of existing database
Load into Spanner
Apply change data capture (CDC) to keep synchronized
Cut over when lag is minimal

3. Incremental Migration:

Migrate subset of data/tables first
Learn from initial migration
Expand scope gradually

Application Changes:

Migrating to Spanner often requires application changes:

Connection handling: Spanner SDK differs from traditional database drivers
Transaction semantics: Spanner's retry behavior may differ
Timestamp handling: Spanner's timestamp precision and timezone handling
Stale read patterns: Leveraging Spanner's stale read capabilities

Testing Requirements:

Load testing with production-representative data volumes
Latency validation for critical paths
Failover testing for multi-region configurations
Cost validation with realistic usage patterns

Migration is Not Just Data Movement

Migrating to Spanner often requires schema redesign, application changes, and operational process updates. Plan for a project, not just a data copy operation.

Decision Framework

Let's consolidate everything into a practical decision framework.

Step 1: Assess Geographic Requirements

Are users in multiple continents with write requirements?
Is there regulatory requirement for data to stay in specific regions?
Do you need disaster recovery across regions?

If all answers are "no": Regional database likely sufficient.

Step 2: Assess Consistency Requirements

Is strong consistency required for correctness (financial, inventory)?
Are there cross-region transactions that must be atomic?
Is eventual consistency acceptable for most operations?

If eventual consistency is acceptable: DynamoDB Global Tables or similar may be simpler.

Step 3: Assess Scale Requirements

Is the dataset larger than single-server capacity (100s of GB to TB+)?
Are write rates beyond single-primary capacity (10K+ writes/sec)?
Is horizontal scaling needed for future growth?

If current and projected scale is modest: Traditional databases scale adequately.

Step 4: Assess Feature Requirements

Do you need full SQL capabilities (complex queries, joins, aggregations)?
Are ACID transactions required across multiple entities?
Is schema evolution needed without downtime?

If simple key-value access patterns: NoSQL databases may be simpler and cheaper.

spanner-decision-tree.txt
SPANNER DECISION TREE
═══════════════════════════════════════════════════════════════════
 
START: Does your application need a database?
       │
       ▼
   ┌──────────────────────────────────────────────────────────┐
   │ Q1: Are users distributed across multiple continents     │
   │     AND need to write data (not just read)?              │
   └──────────────────────────────────────────────────────────┘
       │                                    │
       ▼ YES                                ▼ NO
   ┌──────────────────┐                ┌────────────────────┐
   │ Multi-region     │                │ Single-region      │
   │ write required   │                │ sufficient         │
   │                  │                │                    │
   │ Continue ──────► │                │ Consider:          │
   │                  │                │ • PostgreSQL/MySQL │
   │                  │                │ • Cloud SQL        │
   │                  │                │ • Aurora           │
   └──────────────────┘                │ • AlloyDB          │
       │                               └────────────────────┘
       ▼
   ┌──────────────────────────────────────────────────────────┐
   │ Q2: Is STRONG consistency required across regions?       │
   │     (Financial accuracy, inventory correctness, etc.)    │
   └──────────────────────────────────────────────────────────┘
       │                                    │
       ▼ YES                                ▼ NO (Eventual OK)
   ┌──────────────────┐                ┌────────────────────┐
   │ Need external    │                │ Eventual           │
   │ consistency      │                │ consistency OK     │
   │                  │                │                    │
   │ Continue ──────► │                │ Consider:          │
   │                  │                │ • DynamoDB Global  │
   │                  │                │ • Cassandra        │
   │                  │                │ • CockroachDB      │
   └──────────────────┘                └────────────────────┘
       │
       ▼
   ┌──────────────────────────────────────────────────────────┐
   │ Q3: Do you need SQL semantics (complex queries, joins,   │
   │     transactions across entities)?                        │
   └──────────────────────────────────────────────────────────┘
       │                                    │
       ▼ YES                                ▼ NO
   ┌──────────────────┐                ┌────────────────────┐
   │ Need relational  │                │ Simple access      │
   │ capabilities     │                │ patterns OK        │
   │                  │                │                    │
   │ Continue ──────► │                │ Consider:          │
   │                  │                │ • DynamoDB         │
   │                  │                │   (with strong     │
   │                  │                │    consistency)    │
   └──────────────────┘                └────────────────────┘
       │
       ▼
   ┌──────────────────────────────────────────────────────────┐
   │ Q4: Is GCP acceptable? (or only option)                  │
   └──────────────────────────────────────────────────────────┘
       │                                    │
       ▼ YES                                ▼ NO (Multi-cloud needed)
   ┌──────────────────┐                ┌────────────────────┐
   │ ┌──────────────┐ │                │ Consider:          │
   │ │   SPANNER    │ │                │ • CockroachDB      │
   │ │              │ │                │ • YugabyteDB       │
   │ │ Strong fit!  │ │                │ • TiDB             │
   │ └──────────────┘ │                │                    │
   │                  │                │ (Spanner-inspired  │
   │ Validate:        │                │  alternatives)     │
   │ • Cost           │                │                    │
   │ • Schema design  │                └────────────────────┘
   │ • Migration path │
   └──────────────────┘

The Ultimate Question

Does the value of Spanner's unique capabilities (global consistency, SQL at scale, automatic sharding) exceed the cost premium and GCP dependency? If yes, Spanner is a strong choice. If those capabilities aren't critical to your application, simpler options likely serve better.

Summary: Google Spanner in Perspective

Over this module, we've explored Google Spanner in depth—from its global architecture to the TrueTime innovation, from distributed transactions to automatic sharding. Let's conclude by placing Spanner in the broader context of database engineering.

Module Key Takeaways

•Global Distribution: Spanner uses zones, Paxos groups, and configurable replication to span continents while maintaining consistency.
•TrueTime Enables Ordering: GPS receivers and atomic clocks provide bounded clock uncertainty, enabling commit-wait and external consistency.
•Distributed Transactions Work: Paxos-backed 2PC, wound-wait deadlock prevention, and careful protocol design enable globally atomic transactions.
•Automatic Sharding Reduces Operations: Splits, placement, and rebalancing happen automatically, freeing engineers from manual sharding burden.
•Interleaved Tables Matter: Physical co-location of related data is essential for performance—schema design is critical.
•Consistency Costs Latency: External consistency requires commit-wait. Understand and accept this tradeoff.
•Spanner Isn't Universal: It excels at specific use cases. For others, simpler and cheaper alternatives serve better.

The Broader Significance:

Spanner's significance extends beyond its specific capabilities. It demonstrated that the perceived tradeoffs of distributed systems—consistency vs. availability, SQL vs. scale—were engineering challenges, not fundamental limits. This inspired a generation of NewSQL databases (CockroachDB, TiDB, YugabyteDB) that bring similar capabilities to broader audiences.

The Learning:

Understanding Spanner deeply teaches you:

How distributed consensus works (Paxos, leader election, replication)
Why time matters in distributed systems (clock synchronization, ordering)
How to think about global consistency (external consistency, commit protocols)
How to design for distributed access (interleaving, key design, locality)

These concepts apply far beyond Spanner itself.

Final Thought:

Google Spanner represents what's possible when world-class engineering meets real-world requirements. Whether you use Spanner directly or not, understanding its design principles makes you a better distributed systems engineer. The same principles—locality, consensus, bounded uncertainty, automatic management—apply across the entire field.

Module Complete

You have completed the Google Spanner module. You now understand one of the most sophisticated database systems ever built—its architecture, its innovations, its tradeoffs, and when to use it. This knowledge positions you to make informed decisions about globally distributed data systems and to appreciate the engineering that makes planetary-scale databases possible.