Database
Google's Spanner Omni Now Generally Available, Running Distributed SQL Anywhere Without Atomic Clocks
Spanner Omni, Google's deploy-anywhere version of its distributed SQL database, becomes production-ready by replacing proprietary infrastructure with software-based alternatives.
InfoQ
Google has released Spanner Omni as generally available, making its distributed SQL database portable to any infrastructure—customer data centers, competing cloud platforms, or even laptops. The shift required reimagining two foundational pillars of Google's managed version: the Colossus distributed file system and TrueTime, a clock service that relies on atomic hardware and GPS satellites.
Replacing Infrastructure with Software#
Google tackled the most critical dependencies by building software abstractions that replicate essential behavior without the specialized hardware. Rather than Colossus, Spanner Omni uses a file abstraction layer that writes to local storage and distributes it across networked nodes, with automatic shard splitting and rebalancing. The company is candid that this is not Colossus itself—but performs adequately for most production workloads.
Similarly, the software-based TrueTime alternative synchronizes clocks across servers with bounded error margins. The engineering insight is that Spanner's architecture already tolerates weaker time guarantees because it overlaps synchronization waits with productive database work. This design slack eliminates the need for atomic clocks while maintaining consistency and performance.
The database engine preserves what works: Paxos consensus, automatic sharding, and synchronous replication remain unchanged. Google's internal testing shows the system sustains millions of queries per second across petabytes in single regional deployments.
The Hidden Cost: Operations Becomes Your Problem#
The architectural changes mask a deeper operational shift. Carlos Pérez Martín, CTO at Q2BSTUDIO, observed that "the interesting shift is operational, not architectural: once the same engine runs in your racks, the failure domains become yours."
This reframing exposes three categories of new work:
- Topology design — Quorum and witness configurations must be recalculated for local network latencies; users experience tail latency rather than average response times when a whole data center becomes a failure unit.
- Change management — Patching, upgrades, and rollback transition from a managed service duty to an internal operation requiring formal change control processes.
- Data governance — Hosting in private infrastructure brings backup, encryption key management, and audit compliance into the operator's hands.

