Google Spanner

1. TrueTime + external consistency: making "global linearizability" a product

What it is: Every datacenter has GPS + atomic clocks; the TrueTime API returns not a point in time but an interval [earliest, latest]; on commit the transaction takes commit_ts = TT.now().latest, then commit-wait (locks are released and the ACK returned only after TT.now().earliest > commit_ts), guaranteeing that any transaction that starts later gets a larger timestamp — causal order and real-time order agree across any two nodes on the planet. Why it's a real capability: No single timekeeping center, no centralized coordinator; CockroachDB's HLC approach to the same problem achieves only serializability and cannot preserve cross-key linearizability (Jepsen 2017 confirmed its causal-reverse as by-design). Spanner is one of the very few implementations beyond a paper that has been in production for 10+ years. Edge truth: ① every commit pays a fixed uncertainty window (usually single-digit ms, often masked by Paxos quorum RTT — official docs); ② TrueTime is a built-in Google capability, you cannot reproduce it elsewhere — choosing Spanner means betting correctness on Google's clock infrastructure; ③ if clock uncertainty exceeds bounds, Spanner chooses to block rather than risk — the correctness-first design, but it means writes stall under extreme clock failure. Evidence: OSDI 2012 paper; Google Cloud official blog "Strict Serializability and External Consistency in Spanner"; 2025 ACM SIGMOD Systems Award (vendor-claimed honor).

1. Transparent horizontal scaling: automatic sharding and rebalancing

What it is: Data is partitioned into splits by primary-key range, automatically split and migrated as load/size changes, with no manual resharding; adding nodes/PU completes online. Why it's a real capability: Growing from a single MySQL to multi-region multi-write traditionally means "application-level sharding + routing + DIY consistency" refactoring; Spanner walked that whole road and exposes only "add compute". Edge truth: ① what scales is the compute quota — the per-split throughput ceiling of a hot key won't disappear by adding nodes — adding 10 nodes won't save a single hot primary key (see deep-dive II); ② scaling is billed per node-hour, and scaling down late is burning money; ③ automatic rebalancing's split migration eats IO/network in the background and can be observed in extreme cases (visible in Key Visualizer).

1. Interleaved tables: physically co-located parent-child relationships

What it is: Child rows are physically stored together with parent rows by primary-key prefix, INTERLEAVE IN PARENT... ON DELETE CASCADE; point lookups/joins of parent + child are local operations. Why it's a real capability: This is a structural answer to "distributed joins are expensive" — encode the access pattern into the physical layout, and for workloads where 90%+ of access goes through the parent key, cross-table read latency and cost both come down. Edge truth: ① the interleave relationship is fixed at table-creation time and cannot be changed afterwards — model it wrong and you're rebuilding tables and migrating data; ② when the parent-child fan-out is 1:N with very large N (>10K) or child rows are updated independently at high frequency, interleaving turns locality into a hotspot/lock-contention factory; ③ ON DELETE CASCADE is a dangerous default for financial data (deleting the parent takes everything), and community migration guides explicitly recommend ON DELETE NO ACTION for financial tables. Evidence: Official schema design docs; multiple community migration skill guides agree.

1. Dual SQL dialects + multi-model in one engine

What it is: The same engine speaks both GoogleSQL and the PostgreSQL dialect; layered on top: Spanner Graph (GQL/openCypher), ScaNN vector search (10 billion+ vectors per single index, vendor claim), full-text search, JSON/ARRAY/STRUCT types, Change Streams. Why it's a real capability: The OLTP primary database can also do graph traversals, vector recall, and CDC downstream without standing up another database per model — in 2026 Google packaged it as the "Agentic Data Cloud" foundation, and the direction is sound. Edge truth: ① the PG dialect is a "subset + extensions", not real PG (see deep-dive V); ② graph/vector/columnar are bolt-on capabilities — heavy workloads (large-scale OLAP, professional graph analytics) are still better federated to BigQuery/specialized engines — the vendor itself positions heavy analytics as "federation", not "native".

1. Spanner Omni: an escape hatch outside GCP

What it is: The 2025 release of downloadable containerized Spanner, running on VMs/Linux containers/Kubernetes, deployable on-prem, AWS, Azure, edge; supports forming primary/standby (hot-cold failover) pairs with the GCP managed edition and multi-sovereignty jurisdiction deployments. Why it's a real capability: It partially answers Spanner's #1 structural criticism — "it only runs on Google Cloud". For regulated industries (data sovereignty, disaster-recovery compliance) it is a substantive decoupling. Edge truth: ① still proprietary license, not open source, with unclear commercial terms/pricing (contact sales, to-be-verified); ② how TrueTime guarantees timekeeping precision outside GCP is not fully disclosed in official details — how much of the global-strong-consistency magic survives in your own datacenter is to-be-verified; ③ once you self-operate, the biggest selling point — "zero operations" — disappears.

Deep-dive I: TrueTime and external consistency — the foundation of correctness, and a single point of trust (domain: transactions & time)

• Mechanism: GPS + atomic-clock TrueTime interval timekeeping; commits go through Paxos quorum + commit-wait; read-only transactions take a safe timestamp, lock-free, servable by any replica that has applied up to that timestamp.
• At the edge: ① cross-region write latency = intercontinental RTT + commit-wait — sub-millisecond OLTP is out of the question; ② when clock uncertainty exceeds bounds, writes block (correctness over availability, CP is in the genes); ③ under high contention in read-write transactions, serializability drives abort rates up — the vendor added Repeatable Read (snapshot isolation, with write-skew risk) as a pressure valve, effectively admitting "the strongest isolation" is taxed by hotspots.
• Implication: When you need global multi-write + linear consistency (financial ledgers, inventory, regulated systems), it is one of the very few answers; but the cost of "global strong consistency" is a write-latency floor set by physics — test with real cross-region topology before selection, not with single-region numbers.

Deep-dive II: Interleaved tables and primary-key design — modeling is sharding, and there's no undo button (domain: data modeling)

• Mechanism: Ranges are partitioned into splits by primary key; interleaved tables co-locate parents and children physically; monotonically increasing keys (auto-increment IDs, timestamps) send all new writes to the tail of a single split.
• At the edge: ① monotonic-key hotspots are the biggest gotcha: throughput is capped by a single split, adding nodes does nothing — one HN user built a "dynamically memory-scaled write-through cache" in front for this, spending tens of thousands of dollars extra per month, and eventually found "PG + cache" cheaper for read-heavy workloads; ② interleave relationships cannot be changed after creation; a parent-child fan-out of N>10K or independently-updated child rows turns the locality advantage into lock contention; ③ hard official limits: 80,000 mutations per commit, 100 MiB commit size (the 80K DML limit is relaxed to per-statement starting 2026-09) — large transactions/ETL must use Partitioned DML or batching, the easiest pitfall for teams coming from MySQL.
• Implication: POCs must stress-test with real primary-key distributions + real transaction models; primary-key design is a day-1 architecture decision, not a DBA tuning item later. UUID v4 / bit-reversed / hash scatter — pick one, there is no silver bullet.

Deep-dive III: Stale reads and the latency trade-off — consistency has a knob, but only two detents (domain: consistency/performance)

• Mechanism: Strong reads go to the leader, linearly consistent; stale reads (exact timestamp / bounded staleness) are lock-free and servable by any replica; read-only transactions reuse the same timestamp; MVCC version retention defaults to 1 hour, up to 7 days (long retention adds storage cost).
• At the edge: ① cross-region strong-read latency = RTT to the leader region — in global read-heavy/write-light workloads, skipping stale reads means paying a latency tax for strong consistency you don't need; ② stretching version retention to 7 days for PITR comes at the cost of old-version storage bloat — the retention period is configured per database, billed per storage; ③ the "staleness bound" of stale reads is set by your application itself — set it wrong and it's a business bug, not a database bug — and the official docs won't draw that responsibility boundary for you.
• Implication: Read/write ratio and geographic distribution decide whether you turn on stale reads; 7-day PITR is a lifeline for logical mishaps, but don't treat it as your whole backup strategy (there are also backups retainable up to 1 year).

Deep-dive IV: Cost model and entry floor — paying for "existing", not for "using" (domain: cost)

• Mechanism: Compute billed continuously per node-hour/PU-hour (billed as long as the instance exists, regardless of QPS); storage per GB-month (includes replicas); cross-region replication billed by volume; multi-region billed per compute unit per replica; the three editions Standard/Enterprise/Enterprise Plus have different features and unit prices.
• At the edge: ① in small/low-load scenarios, Spanner's "floor price" is notably higher than Cloud SQL (repeatedly confirmed by community consensus; Google itself admits the "expensive" impression came from the early 3-node starting point, with granular instances + 90-day trials as the remedy); ② the three big bill black holes: idle compute (forgot to scale down), multi-region per-replica compute billing (global deployment cost multiplier), long PITR retention + backup retention (storage bloat); ③ "pay for existing" means you're burning money in traffic valleys too — Autoscaler is mandatory, not optional.
• Implication: For TCO, add up "3 years of continuous compute + cross-region replication + backups"; Aurora DSQL (per-request billing, scale-to-zero) is the opposite philosophy: Spanner rewards stable high baselines and punishes small, spiky workloads.

Deep-dive V: PostgreSQL interface compatibility boundaries — "can connect" ≠ "can migrate" (domain: compatibility/migration)

• Mechanism: The PG dialect is "PG syntax subset + Spanner extensions"; PGAdapter provides a PG wire-protocol proxy.
• At the edge (confirmed absent in official docs, not "no evidence found"): the PG dialect does not support triggers, SERIAL, SAVEPOINT, transactional DDL, partial indexes, extensions, FDW, user-defined types/functions/operators; stored procedures are not supported at all (only CALL of built-in sample procedures); psql supports only a handful of meta commands (\d \dt \dn \di \l); PGAdapter supports only password authentication and COPY is limited to STDIN/STDOUT BINARY. JDBC/client libraries are the right path; PG ecosystem toolchains are "partially usable".
• Implication: The main benefit of migrating from PG is "less SQL-dialect friction at the application layer", but heavy users of triggers/stored procedures/extensions are effectively rewriting; don't interpret "PG compatible" as "you can load a PG dump and run" — schema redesign (interleaving, key scattering) is the bulk of the work.

Deep-dive VI: The positioning triangle with AlloyDB — the line Google drew itself (domain: positioning & selection)

• Mechanism: Google Cloud's official trio: Cloud SQL = standard open-source managed (cheapest, lift-and-shift); AlloyDB = PG only, high-performance HTAP (write scaling ceiling on the primary instance, cross-region async); Spanner = unlimited horizontal write scaling + global strong consistency + 99.999% SLA 厂商口径.
• At the edge: ① single-region PG workloads on Spanner: paying multiples of the bill and modeling rework for global consistency you don't use, with zero perceived performance gain — the most common "wrong tool"; ② when you need a huge single database / unlimited write scaling / global multi-write, AlloyDB's primary-instance write ceiling and async cross-region are hard limits, and Spanner is the only answer; ③ MySQL/SQL Server teams: AlloyDB is PG only, Spanner has a MySQL function package but the kernel is still Spanner — neither side offers a "zero-change" option.
• Implication: For the three-way choice, look at write-scaling needs and consistency needs first, then dialect lock-in; AlloyDB and Spanner are not competitors, they are two tiers Google split by "scale/consistency".

1. Near-zero-ops full management
2. Why it's true: Zero-downtime engine patches/upgrades with no maintenance windows; backup schedules on by default (daily full backups, configurable 7-day retention); online scaling; edition up/down ~10 minutes with zero downtime. DBA work changes from "operations" to "modeling + cost management".
3. Edge and limits: Zero ops assumes you accept the "black box" — split migration, compaction, GC are all Google's; when weird latency strikes you can only stare at Key Visualizer (community has "docs don't cover gotchas" complaints); this advantage disappears entirely once you self-operate Spanner Omni.
4. Source: Official docs; community migration case (Glance) 2023; community consensus, collected 2026-09.
5. Global multi-write + external consistency, actually run in production
6. Why it's true: TrueTime + Paxos are not paper concepts — Google has run them in production internally since 2012 (AdWords/Play), and external customers in finance/retail/gaming have global deployments; 99.999% multi-region SLA 官方文档.
7. Edge and limits: The SLA is a "vendor claim" and only covers "availability", not "your latency"; the cross-region write latency floor is set by physics, and no SLA pays for your P99.
8. Source: Official docs; OSDI 2012 paper; 2025 SIGMOD Systems Award 厂商口径.
9. First-tier observability
10. Why it's true: Key Visualizer heatmaps + SPANNER_SYS SQL-ified introspection (check top SQL, locks, transaction stats without learning new tools) + Spanner Studio query-plan visualization — hotspot localization efficiency is top-tier among managed databases.
11. Edge and limits: Strong at "seeing", weak at "fixing" — once you see a hotspot, the fix is still changing keys / adding nodes; there's no online re-sharding knob to turn.
12. Source: Official docs; Glance migration case 社区实测.
13. Complete PITR + backup system
14. Why it's true: Up to 7 days version retention, microsecond-precision point-in-time recovery, whole-database or create-new-database recovery, backups retainable up to 1 year, cross-region copies, backup-pointer fast first byte. Logical mishaps/bad releases have a well-trodden rollback playbook.
15. Edge and limits: The 7-day window is a hard cap; beyond that only backups help; small-grain recovery (a few rows) is still manual work, and RTO depends on human scripts — the official whitepaper admits this itself.
16. Source: Official disaster-recovery docs; Spanner data-protection whitepaper.
17. Elasticity and cost tooling catching up
18. Why it's true: granular instances (starting at 100 PU), managed Autoscaler (including asymmetric read-only regions), Data Boost (analysis workloads isolated to separate compute, not affecting OLTP), columnar engine in preview (vendor-claimed up to 200x analytics scan acceleration). The "expensive" floor keeps dropping year by year.
19. Edge and limits: Data Boost is not supported on free trial instances; the columnar engine is still in Preview; a badly configured Autoscaler lags in scaling during traffic peaks — elasticity is not "set and forget", it's "a different kind of management".
20. Source: Official release notes (2025-06/08); official pricing page.

• One-liner: One of the endpoints of distributed OLTP that you pay for "global multi-write + linear consistency + zero ops"; when you don't need those three, it's the most expensive wrong answer.
• Best for:
• Global OLTP with cross-region multi-write (financial ledgers, inventory, billing), where correctness requirements outweigh everything
• Teams whose single MySQL/PG has hit its scaling ceiling and cannot accept eventual consistency
• Teams willing to go all-in on GCP and "never touch the database again after shipping code"
• Regulated industries needing "managed primary + self-operated standby" dual-active/sovereign deployments (Spanner Omni route, details to-be-verified)
• Not for:
• Small/medium single-region applications (cost floor + modeling rework double hit, Cloud SQL/AlloyDB fit better)
• Analytics/scan-heavy workloads (federate to BigQuery, don't force it)
• Scenarios with extreme latency sensitivity that cannot afford cross-region commit wait
• Teams needing portability and averse to vendor lock-in (Omni mitigates but doesn't eliminate)
• Existing systems heavily dependent on PG triggers/stored procedures/extensions, or MySQL niche features
• Migration cost:
• MySQL → Medium: the 80+ MySQL function UDF package lowers SQL rework cost, but primary-key scattering + interleaved modeling are mandatory courses; auto-increment ID dependencies must be refactored
• PostgreSQL → Medium-high: PG dialect + PGAdapter lower dialect friction, but missing triggers/SERIAL/extensions/stored procedures mean logic-layer rewrites; direct dump loading is not feasible
• Oracle → High: no Oracle compatibility layer, zero correspondence for the PL/SQL ecosystem; application-layer rewrite + data migration only

• Architecture & consistency: OSDI 2012 Spanner paper; Google Cloud blog "Strict Serializability and External Consistency in Spanner"; official TrueTime/external-consistency docs
• Replication & limits: official replication docs; official quotas docs (80,000 mutations/commit, 100 MiB commit); 2026-09 official blog "Spanner removes DML mutation limits"
• Security: official CMEK docs; Cloud Audit Logs mechanism (GCP general docs); fine-grained access control release blog
• Backup/PITR: official "Disaster recovery overview" and "Recover data using PITR"; Spanner data-protection whitepaper
• Modeling: official "Schema design best practices" and "Schemas overview"; community migration skill guides (multiple, consistent)
• PG compatibility boundaries: official "The PostgreSQL language in Spanner" (updated 2026-02-03, lists unsupported items explicitly); official procedural language docs (explicitly no stored procedures); PGAdapter FAQ (GitHub)
• Cost & editions: official pricing page (90-day trial, Standard/Enterprise/Enterprise Plus, billing model); official editions docs; third-party 2026 comparison analysis (price figures not adopted)
• Spanner Omni: Google Cloud official blog "Introducing Spanner Omni" (2025); 2026-08 community hands-on post (details to-be-verified)
• AlloyDB positioning triangle: this project's alloydb.md deep-dive III (Google official trio comparison)
• Third-party review: druce/dbengines google-cloud-spanner.md (2026-06-04 research, high confidence; Jepsen absence, per-node throughput etc. marked as ⚠️ unverified items — this profile did not adopt its unverified figures)
• Gripe collection: Hacker News discussions (2023–2025); community migration/cost analysis posts; dev.to cost breakdowns
• Next review: track columnar engine GA, Spanner Omni commercial terms/timekeeping details, documentation landing of the DML limit relaxation, Enterprise Plus feature-matrix changes