Schema Design, SQL Dialects & When to Reach for Spanner

Avoiding Hotspots

A monotonically increasing primary key (a simple auto-increment or timestamp) concentrates all new writes onto a single shard at any given moment — a "hotspot" that undermines the horizontal write scalability Spanner is chosen for. Techniques like key hashing or bit-reversal spread writes more evenly across shards.

Interleaved Tables

Interleaved tables physically co-locate related parent-child rows (an Order and its OrderItems) on the same storage node — improving query performance for related data that would otherwise be scattered across nodes by naive sharding.

SQL Dialects & Read Scaling

Spanner supports GoogleSQL and a PostgreSQL-compatible interface, letting teams pick whichever fits their existing tooling while both sit on the same distributed engine underneath. Read-only transactions can serve from replicas and a consistent snapshot without the full coordination overhead of read-write transactions, helping read throughput scale.

The Textbook Use Case

A globally distributed e-commerce inventory system is a classic fit: it needs strongly consistent, ACID-guaranteed counts (no overselling a limited-stock item to two customers at once) while serving a global user base with reasonable latency — exactly the combination Spanner is architected to satisfy. Banking ledgers and ad platforms fit the same profile.

When Simpler Is Better

Spanner's cost and schema-design complexity (hotspot avoidance, interleaving) are worth it only when a workload genuinely needs global distribution and horizontal scale beyond a single region — an application without those requirements is often better served by a simpler, cheaper managed relational database like Cloud SQL.