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.
The engineering is the part Google describes most plainly. 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 cheapest way to price that trade.
Google's own documentation supports that reading. Because Spanner Omni runs on customer-managed infrastructure, Google does not provide availability SLAs, 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.
The operational load lands in the tooling too. Routine maintenance, version upgrades and infrastructure monitoring move in-house, with monitoring through Prometheus alerts and Grafana dashboards rather than Cloud Monitoring, and a diagnostics command that collects logs, traces and thread stacks.
Two other boundaries matter at evaluation time. Integrations that depend 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. The documentation lists Google Cloud and Amazon as supported public clouds, alongside on-premises and laptops; Azure is not mentioned.
What does carry over is the database itself. Spanner Omni supports GoogleSQL, PostgreSQL and Spanner Graph Language, and combines relational, graph, key-value and vector models with full-text search and a columnar engine. Model Context Protocol support through MCP Toolbox lets agents inspect schemas and use the database as an operational memory layer across deployments. General availability adds TLS encryption, authentication and authorization, audit logging, backup and restore, and worker nodes, stateless compute that offloads background operations from the primary servers.
Licensing has two tiers. The Developer Edition is free for non-production use, with a 90-day default license that excludes backups and worker nodes, though a single-server deployment of 4 vCPUs or fewer does not expire and includes backup and restore. Above that, extending beyond 90 days requires a Google form. The Commercial Edition is a vCPU-based annual subscription with no published price.
The deployment patterns Google reports from early adopters match the operational framing. One runs managed Spanner as the primary database with Spanner Omni elsewhere as hot-cold failover. Another standardizes one database layer across environments. A third modernizes on-premises systems on existing hardware. Google also names multi-regional high availability in jurisdictions where it operates only one data center but data sovereignty is required.
Mercado Libre, which built an internal developer gateway offering a NewSQL service powered by Spanner, gave the resilience argument when the preview launched in April. Senior technical manager Diego Oscar Narducci said the company had long remained vigilant about insider threats, ransomware, and cloud outages, and that Spanner Omni enables cross-cloud resilience that would be significantly more complex to implement with other cloud providers.
If that reaction is representative, the decision is not Spanner Omni against another database. It is Spanner Omni against managed Spanner, priced in tail latency and operational toil rather than in features.
One practical note. The Spanner Omni overview in Google's documentation was last updated on September 28, two days before the announcement, and still carries a Preview banner with limitations the release removes, including no TLS encryption, no backups or restores, and deployments that stop accepting writes after 90 days.