By ByteBot
Google Spanner has been the distributed database backend architects wanted but couldn’t have — unless they ran entirely on GCP. That locked-in era ends now. Spanner Omni hit general availability this week, and you can run the same database that powers Google Pay and YouTube on your own hardware, on AWS, or on a laptop. The engineering reason Spanner was GCP-only for 14 years came down to two proprietary components. Google just replaced both with software.
What Made Spanner Untouchable
Original Spanner requires two things no other company has at scale. First, TrueTime: a time API backed by GPS receivers and atomic clocks in every Google data center, giving Spanner a max clock uncertainty of roughly 7ms and enabling the external consistency that makes global ACID transactions possible. Second, Colossus: Google’s proprietary distributed file system that handles the storage layer. Neither shipped outside Google. Until now.
The Software Replacement
Spanner Omni solves both problems. TrueTime becomes a software-based time server: a leader-elected primary in each deployment zone, with host clients synchronizing via NTP-style error-bounded intervals. The database overlaps uncertainty waits with other work, so it tolerates weaker clock bounds than the atomic-clock version delivers. It’s not identical — but Google calls it production-ready.
Colossus becomes an abstraction layer that writes to local SSDs and makes that storage network-available to other nodes in the cluster. Automatic shard splitting and rebalancing handles distribution. Each VM requires 500 GB of SSD per vCPU with an ext4 filesystem. Google says performance is comparable to managed Spanner for most workloads.
What You Actually Get
Spanner Omni isn’t a stripped-down version. It carries the full multi-model feature set:
- Relational: GoogleSQL and PostgreSQL dialects, full ACID transactions
- Vector search: KNN and ANN indexes, supports 10 billion+ vectors — semantic search sitting inside the transactional engine
- Graph: Spanner Graph for property graph traversals
- Full-text search: Built into the same engine, no separate index service
You can run a single ACID-compliant SQL statement that joins a relational table, traverses a graph, and filters by vector similarity. That’s the pitch for AI-era applications where you need structured data, relationships, and embeddings in one place — without stitching three different databases together. Google covers the multi-model angle in detail in their agentic era Spanner post.
Deployment: Four Topologies, Kubernetes-Native
Spanner Omni deploys via Helm and runs on Kubernetes. Four topologies cover the range from local development to production HA:
- Single server: One machine, good for local development and evaluation
- Single-zone: Minimum three servers, one zone
- Multi-zone: Minimum three zones, high availability
- Multi-cluster: Multiple zones across multiple clusters, geo-distribution
Charts live at us-docker.pkg.dev/spanner-omni/charts. Sample configs — covering single-server, regional, scaleout, multi-region, and multi-cloud — are on GitHub at GoogleCloudPlatform/spanner-omni. The official Spanner Omni documentation covers Kubernetes deployment step by step.
Pricing: Free Tier, Opaque Commercial
The Developer Edition is free: single-server deployments of four vCPUs or fewer never expire and include backup and restore. Larger development clusters get a 90-day license. The Commercial Edition is a vCPU-based annual subscription with no published price — you contact the Google Cloud team. That’s a frustrating answer for anyone trying to evaluate total cost of ownership, but the free tier is a genuine on-ramp.
The Honest Catch
Two things to understand before deploying to production. First: there is no availability SLA. Google provides reference topologies instead of contractual uptime guarantees — a meaningful gap versus managed Cloud Spanner’s 99.999% SLA. Second: software TrueTime is weaker than atomic clocks. Google mitigates this by overlapping uncertainty waits, but sub-millisecond consistency requirements in financial systems should factor in that difference. InfoQ’s technical breakdown goes deeper on the consistency trade-offs.
Azure support also lags. You can run Spanner Omni on Azure VMs using Hyper-V PTP with Chrony NTP, but the integration is less polished than GCP or on-premises bare metal deployments.
The Market Shift
CockroachDB has run without atomic clocks since day one — their hybrid logical clocks solve the same problem a different way. YugabyteDB offers deeper PostgreSQL compatibility by reusing the actual PG query engine. Spanner Omni doesn’t make either of those go away overnight. What it does is bring Google’s engineering pedigree, multi-model depth, and vector+graph+relational integration into a market where those databases have operated without serious competition from Google. That changes the pricing and roadmap math for everyone in distributed SQL.
If you’ve been waiting to evaluate Spanner without committing to GCP, the free developer tier is ready. Production use is a different conversation — one that starts with Google Cloud’s account team and ends with a contract you can’t read on their website. Start at the official GA announcement and download the Helm chart.
