Google Cloud Spanner

by Google Cloud

Globally-distributed, strongly-consistent relational database service

Overview

Google Cloud Spanner is a fully-managed, horizontally scalable relational database that provides strong consistency, ACID transactions, and global distribution. It was designed to combine the familiar relational model and SQL with the scale and availability of NoSQL systems. Spanner is appropriate for mission-critical, high-throughput transactional systems that require low-latency access across regions and strong correctness guarantees.

Features

Relational SQL interface (ANSI-ish SQL) with schema, indexes, and joins
Global, strongly-consistent ACID transactions
Horizontal scaling via automatic sharding (split/merge of tablets)
Synchronous replication and Paxos-based consensus for durability and consistency
TrueTime-backed timestamps (GPS/atomic clock hybrid) to enable external consistency
Multi-region configurations with SLA up to 99.999% availability
Automatic failover and transparent replication across zones/regions
Integration with IAM, CMEK (customer-managed encryption keys), audit logging
Client libraries in multiple languages and JDBC/ODBC-compatible drivers
Multi-version concurrency control (MVCC) for consistent reads at timestamps

Superpowers

Spanner’s unique value is delivering relational semantics and strong, global transactional consistency at scale. Key advantages:

Write-scaling and cross-region strong consistency without custom sharding logic
Predictable correctness for financial, inventory, and other systems where cross-region consistency matters
Managed service that offloads operational complexity (replicas, splits, failover)

Who it’s for

Enterprise teams building globally distributed OLTP applications (financial systems, ad-tech, telecom control planes, game state, inventory/order systems)
Teams that need ACID guarantees across regions and an SQL surface

Pricing (high level)

Pricing changes over time. Spanner billing commonly includes:

Node-based compute (per-node hourly pricing) or processing units depending on region/config
Storage (GB per month)
Networking (egress, cross-region replication network costs)
Backup and restore charges
For accurate, up-to-date pricing see the official pricing page: https://cloud.google.com/spanner/pricing

Architecture & consistency (concise)

Data is split into tablets and stored on a distributed storage layer (Colossus).
Replication is managed using Paxos groups (replica sets) across zones/regions.
TrueTime gives bounded clock uncertainty which Spanner uses to assign globally-ordered commit timestamps and provide external consistency.
Reads can be at strong (leader) timestamp or at historical timestamps for snapshot reads.

When to use Spanner

You need global, strongly-consistent writes and reads across regions.
You have a single logical relational schema and require ACID semantics at scale.
You need a managed service with high availability and transparent replication.
Use cases: global financial ledgers, telecom/utility state, multi-region inventory/order systems, large-scale session/state stores with SQL access.

When not to use Spanner

If your workload is primarily analytical (large scans, OLAP) — BigQuery or a data warehouse is a better fit.
If you want a low-cost local RDBMS for small apps — Cloud SQL or managed Postgres/MySQL is cheaper and simpler.
For workloads that can tolerate eventual consistency and require cheaper key-value scale (consider Bigtable, DynamoDB, or other NoSQL stores).

Practical usage examples (focus on patterns, not installation)

Global bank ledger: Use a multi-region instance with strong read/writes and per-account rows; rely on Spanner transactions to keep balances consistent across regions.
Leaderboard/game state: Store player state sharded by player ID using Spanner splits; use timestamp-bounded reads for consistent snapshots.
Inventory/order system: Use per-item rows and apply transactions for decrementing inventory and creating orders atomically.

Example: simple schema and transaction pattern

-- create a minimal table  
CREATE TABLE Accounts (  
  AccountId   STRING(36) NOT NULL,  
  Balance     NUMERIC,  
) PRIMARY KEY (AccountId);  
  
-- application pseudocode (transactional)  
BEGIN TRANSACTION;  
  SELECT Balance FROM Accounts WHERE AccountId = 'A';  
  UPDATE Accounts SET Balance = Balance - 100 WHERE AccountId = 'A';  
  INSERT INTO Transactions (...) VALUES (...);  
COMMIT;

Notes:

Use small, hot-keyed rows to avoid single-shard hotspots; let Spanner split large ranges.
Use secondary indexes for common secondary lookup patterns.

Best practices

Design keys to avoid sequential hot-spotting (add randomness or use natural shard keys).
Keep wide-scan operations limited; paginate large results or offload analytical queries to BigQuery.
Monitor splits and instance node utilization; scale nodes to match throughput/latency needs.
Use multi-region instances for high availability and locality-aware replicas for lower latency.
Leverage backup schedules and periodic exports for retention and point-in-time recovery.

Limitations & trade-offs

Cost: Spanner is typically more expensive than single-region managed DBs for small workloads.
Operational model: Capacity is typically measured in nodes — scaling is coarser than autoscaling single-node databases.
SQL surface: While rich, Spanner’s SQL dialect has some differences vs. PostgreSQL/MySQL (careful when porting complex apps).
Strong consistency cross-region introduces higher write latencies than single-region systems due to commit coordination.

Alternatives / comparisons

Cloud SQL (Postgres/MySQL) — better for simpler, single-region relational workloads and lower cost.
Bigtable — key-value wide-column store for massive single-row scalability but eventual consistency semantics and no relational SQL.
BigQuery — analytical warehouse for large-scale analytics, not for low-latency OLTP.
Distributed SQL competitors: [CockroachDB], [YugaByteDB], [TiDB] — offer similar goals (distributed SQL) with different trade-offs (self-managed vs managed, consistency models, cost).

Resources

Official docs: https://cloud.google.com/spanner
Pricing: https://cloud.google.com/spanner/pricing
Concepts & architecture: https://cloud.google.com/spanner/docs

Status: Drafted from public documentation and technical sources. Set to status: OK and share: true; please review for any organizational-specific notes you’d like added or for a different publish date.

ThirdBrAIn.tech

Explorer

Google Cloud Spanner