Google has made Spanner Omni generally available. It is a version of Spanner, the distributed SQL database behind many of Google's own services, that customers can run in their own data centres, on other clouds or even on a laptop. InfoQ reported the launch on 7 October.
For years, the standard argument against Spanner was that it only lived inside Google Cloud. That argument is now gone. A new one has taken its place.
How Google made it portable
Spanner famously relies on two pieces of Google hardware and software. TrueTime uses atomic clocks and GPS receivers to keep servers in very tight time agreement. Colossus is Google's internal file system. Neither exists in your data centre.
Spanner Omni replaces both with software. A storage layer spreads data from local disks across the network and rebalances it automatically. Time is kept in agreement with a software method that tolerates more uncertainty than TrueTime. Google argues this works because Spanner overlaps its time checks with other work. The core of the database, including its replication and automatic sharding, is unchanged.
Google claims millions of queries per second across petabytes in a single region, based on its own testing.
What you get and what you do not
The GA release adds the features you would expect before trusting it with production data: encryption in transit, access control, audit logs, backup and restore, and extra worker nodes to handle background tasks. It supports Google's own SQL dialect, PostgreSQL and a graph query language, plus vector and full-text search.
Some things stay behind. There is no availability SLA. Because the database runs on infrastructure you manage, Google offers reference designs instead of a promise. Integrations that depend on Google Cloud, such as BigQuery, are not included. Monitoring uses Prometheus and Grafana rather than Google's own tools. Upgrades, patching and maintenance are yours.
There is a free developer edition for non-production use. The commercial edition is an annual subscription priced per vCPU, with no public price list.
Who should look at it
Google says early users are following a few patterns. Some keep managed Spanner as the main database and run Omni elsewhere as a standby. Some want one database layer across every environment. Some want to modernise on-premises systems on hardware they already own. And some need several data centres in a country where Google has only one region but data must stay in the country.
That last case is the strongest. Data residency rules are tightening in many markets, including India and the EU, and a database that can span your own sites in one country solves a real problem.
The real trade
The decision is not Spanner Omni against other databases. It is Spanner Omni against managed Spanner. With managed Spanner, Google runs the database and stands behind its uptime. With Omni, you get control and location, and you take on the operating work: capacity planning, failure testing, upgrades and on-call. For a database designed to survive the loss of a whole zone, that work is serious.
The useful test is a like-for-like pilot. Run the same workload on both and compare tail latency, not averages, and the hours of operating effort each one needs.
What to do this quarter
- Name the reason. Data residency, cloud exit options or on-premises modernisation. If none applies, managed Spanner is probably the better deal.
- Cost the operating team, not just the licence. A multi-zone setup needs at least three zones with three servers in each.
- Use the free developer edition to test failure scenarios before any commercial talks.
- Ask Google for the commercial price early. With no public list price, budget conversations take time.
