Google has made Spanner Omni generally available, a deploy-anywhere version of its distributed SQL database that runs in a customer's own data center, on other clouds, or on a laptop.
Getting Spanner off Google's 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. What does not come with it is an availability SLA.
In place of Colossus, Spanner Omni introduces what the company calls a Colossus-like abstraction layer, writing to attached local file systems and making them available across the network to other nodes, with shard splitting and rebalancing handled automatically. Google is direct about the compromise: the file layer is not Colossus, but it is a sufficient stand-in to perform comparably to the managed service for most workloads.
TrueTime got the same treatment. The software-based alternative provides error-bounded time synchronization across servers, as the original does using atomic clocks and GPS. Google's explanation for why that works turns on how Spanner already behaves: the database overlaps time uncertainty waits with other work, so it tolerates weaker uncertainty bounds than TrueTime delivers in practice. That slack is what allows timekeeping across heterogeneous hardware without limiting availability or performance.
Paxos consensus, automatic sharding and synchronous replication carry over unchanged, and Google's internal benchmarks claim millions of queries per second across petabytes in a single regional deployment.
Practitioner reaction has focused on what that means to run. Carlos Pérez Martín, CTO at Q2BSTUDIO, argued that the change is not primarily a design question: "The interesting shift is operational, not architectural: once the same engine runs in your racks, the failure domains become yours."
He set out three consequences. Quorum and witness topology has to be re-derived for the local latency budget, and when a whole datacenter becomes the unit of failure, p99 rather than the mean is what the application feels. Patching, versioned upgrades and rollback stop being someone else's ticket queue and become a change-management problem with the customer's name on it. And moving data residency into a private datacenter brings the backup, key management and audit burden along with it.
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 instead of feature parity, is the cheap" way to evaluate the offering.