- Published on
Spanner Omni Reaches GA, Replacing Google's Atomic Clocks and File System with Software
- Authors
- Name
- DeepHorus
Google has made Spanner Omni generally available, a deploy-anywhere edition of its flagship distributed SQL database that can run inside a customer's own data center, on other public clouds, or on a laptop. The release marks a notable departure from Google's tightly integrated cloud stack, since running Spanner outside Google's own infrastructure meant replacing the two components it depended on most: Colossus, the distributed file system, and TrueTime, the clock service built on atomic clocks and GPS. The trade-off is explicit — what customers gain in portability, they lose in contractual guarantees, because Spanner Omni ships without an availability SLA. Google frames the move as an answer to demand for data residency and hybrid deployments.
Colossus and TrueTime have long been the hidden foundations of Spanner's claims about correctness and durability. Colossus stores and distributes data across Google's fleet, while TrueTime supplies globally consistent timestamps with tightly bounded uncertainty — a luxury few operators can replicate. Removing both meant rebuilding Spanner's assumptions in software rather than hardware. Google describes that work plainly, acknowledging compromises while arguing results remain comparable to the managed service.
In place of Colossus, Spanner Omni introduces what the company calls a Colossus-like abstraction layer that writes to attached local file systems and exposes them across the network to other nodes. Shard splitting and rebalancing are handled automatically, so the operational surface looks familiar. Google is direct about the substitution: the file layer is not Colossus, but it is a sufficient stand-in to perform comparably for most workloads.
TrueTime received the same treatment, replaced by a software-based alternative providing error-bounded time synchronization across servers. Google's justification turns on how Spanner already behaves: the database overlaps time uncertainty waits with other work, tolerating weaker bounds than TrueTime delivers in practice. That slack allows timekeeping across heterogeneous hardware without limiting availability or performance. Core machinery carries over unchanged — Paxos consensus, automatic sharding and synchronous replication — and Google's internal benchmarks claim millions of queries per second across petabytes in a single regional deployment.
Practitioner reaction has focused less on architecture than on operations. Carlos Pérez Martín, CTO at Q2BSTUDIO, argued the interesting shift is operational rather than architectural: once the same engine runs in your racks, the failure domains become yours. He identified three consequences: quorum and witness topology must be re-derived for the local latency budget; patching, versioned upgrades and rollback become change management with the customer's name on it; and private data residency drags backup, key management and audit burdens along. His recommended test is narrower than a feature comparison — a like-for-like pilot against the managed service, measured on tail latency and ops toil.
Google's documentation supports that reading. Because Spanner Omni runs on customer-managed infrastructure, Google provides no availability SLA, pointing instead to reference architectures it says help achieve comparable high availability. What replaces the SLA is a set of topologies: single server, where upgrades cause downtime; single-zone with a minimum of three servers; multi-zone needing at least three zones with three servers each; and multi-cluster using three zones across two or more clusters. Monitoring also moves in-house, through Prometheus alerts and Grafana dashboards rather than Cloud Monitoring, alongside a diagnostics command collecting logs, traces and thread stacks.
Several boundaries matter at evaluation time. Integrations depending on Google Cloud are excluded, including BigQuery, Knowledge Catalog and Gemini Enterprise, and Google acknowledges remaining feature gaps against the managed service without naming which or when they close. Supported public clouds are listed as Google Cloud and Amazon, alongside on-premises and laptops, with Azure not mentioned. What carries over is the database itself: Spanner Omni supports GoogleSQL, PostgreSQL and Spanner Graph Language. Adoption will likely hinge on whether enterprises value portability enough to absorb the operational load.
