Spanner Omni: When Portable Databases De-Risk a Migration

A database you can run anywhere sounds like optionality. In plenty of migrations, it becomes the reason the migration never finishes.

Google announced general availability of Spanner Omni, the deploy-anywhere, self-managed edition of Spanner, on September 30, 2026, about five months after its preview debut at Google Cloud Next '26 (GA announcement, preview post). It will start showing up on migration slides this quarter, usually in the box labeled "reduces risk."

Sometimes it genuinely does. Our take: a portable distributed SQL layer de-risks a migration when it answers an external constraint you can name. It postpones one, at a premium, when it answers an internal disagreement nobody wants to have.

What GA actually changed

What's the real difference between an engine you can download and one you can run in production at 2am? Preview was an engine you could run. GA is an engine you could plausibly operate. The release unblocks TLS encryption, authentication and authorization, audit logging, and backup and restore. It also adds dedicated stateless worker nodes, separate servers that absorb background and resource-intensive operations so they don't contend with your query traffic. Direct access to Google Cloud Customer Care comes with it too. Licensing arrives as well: a free Developer Edition for non-commercial, non-production use, and a paid Commercial Edition on a vCPU-based annual subscription, with a discounted proof-of-concept license for pre-production evaluation. No pricing figures are published in the announcement, so treat any number in a business case as something to get in writing.

Two caveats in Google's own text matter more than the feature list. Because Spanner Omni runs on customer-managed infrastructure, Google provides no availability SLA for it, and the customer owns day-to-day operations: routine maintenance and version upgrades. Spanner Omni also excludes managed-Spanner capabilities that depend on Google Cloud, such as native BigQuery integration.

Put those together and the honest summary is simple. You get the same engine everywhere. The platform around it stays behind in Google Cloud.

The good version of this decision

Google names three architectures it saw among early adopters. First, managed Spanner on Google Cloud as primary with Spanner Omni on-prem or in another cloud as a hot-cold failover site: a second site kept in sync but not serving traffic until the primary fails. Second, a single stack running across hybrid and multicloud. Third, on-premises modernization on existing hardware.

It also names a sovereignty case: multi-regional high availability in jurisdictions where Google Cloud has one data center but sovereignty rules apply. And it names a customer, Attio, a London-based AI-native CRM company, which migrated its agentic application environment to containerized Spanner Omni running alongside managed Spanner, with CTO Alexander Christie quoted on accelerated production velocity.

What those cases share is worth noticing. Every one is driven by a constraint that exists outside the engineering organization and won't dissolve because someone writes a better design doc. That's the test we'd apply:

• A legal or sovereignty requirement that pins data to a jurisdiction with limited regional coverage.
• A latency-bound system physically tied to a factory floor or a trading venue.
• Software you ship into other organizations' data centers, where the customer chooses the infrastructure.
• A genuine failover posture where the second site must exist somewhere you don't control.

The demand behind the first of those is rising. BARC's Data Sovereignty 2026 study of 320 companies, surveyed February through March 2026, found 51% rate data sovereignty as very important, up from 42% the year before. Legal requirements are the top external driver at 61%. Hybrid or on-premises strategies are a leading action area at 35%. Yet 40% aren't investing yet, and only 10% have a dedicated budget. The concern is ahead of the funding.

If your constraint is on that list, portability is the requirement itself, and Spanner Omni is a serious candidate for it.

The bad version: portability as a decision you didn't make

The failure pattern usually starts with a well-run architecture review. Everybody agrees the workload should move. Nobody agrees when the on-prem estate turns off. A portable engine lets the committee approve the move without settling that, so the hybrid phase gets an open-ended runway and the cutover becomes a future agenda item. It's the software equivalent of keeping the lease on the old office "just until we're sure." Nobody ever names the month the keys go back, and the rent keeps clearing.

The costs of that are well documented. The New Stack has analyzed multicloud portability. Building for workload portability, the analysis argues, "can dilute the usefulness of your chosen platform to the least common denominator." Contino makes the blunter version. When the goal is avoiding vendor lock-in, multi-cloud "really doesn't make sense," Contino argues, because "the costs almost always outweigh the benefits," and abstraction layers add cost and complexity of their own. OpenMetal's guidance on migration delays names the same failure mode: moving too slowly and "double-paying for two full environments indefinitely because the migration got more complex than expected and nobody forced the issue" (OpenMetal).

With Spanner Omni the least-common-denominator effect isn't hypothetical, because Google scopes it explicitly. Standardize on Spanner Omni to stay portable and you forgo the GCP-native integrations, BigQuery among them. The analytics and AI surface built around a managed-Spanner estate is exactly the part that doesn't travel, and re-adding it later is net-new work at the cutover you were already deferring.

Three costs to put on the slide before the vote

Operations, not licenses. No Google availability SLA means patching, upgrades, monitoring, and incident response become an internal line item. A production posture means multi-zone, a minimum of three zones, three servers per zone recommended, with 4 GB RAM per vCPU and dedicated SSD. Price the people who keep that patched. That's headcount and run-book maturity, quoted honestly against the managed alternative.

Dual-running spend, attributed. Dual-running, paying for the on-prem estate and the cloud target at the same time, is the phase nobody budgets past quarter two. Monthly billing exports hide it. You want per-project and SKU-level tracking, refreshed hourly rather than daily, so the real number stays in front of the architecture committee instead of surfacing at quarter-end. If nobody can say what the hedge costs per month, nobody will end it.

The rewrite you're already signing up for. Landing on Spanner is often an application-level redesign for teams coming from Oracle or PostgreSQL. Google's Oracle-to-Spanner migration guidance says you might need to redesign your application architecture, and Spanner doesn't run user code in the database. Stored-procedure and trigger logic has to move into the application.

One more piece of due diligence: GA-specific claims currently trace back to Google's blog and documentation, since the announcement is same-day. Competitors have an interested but on-the-record critique. Cockroach Labs calls Omni a "newer, more constrained offering" than incumbent self-hostable distributed SQL. The comparison page still describes Omni as an April 2026 preview, so treat its maturity claim as pre-GA. Either way, test parity against your own workload before you assume it. The discounted proof-of-concept license exists for exactly that.

The call

Portability is a hedge, and hedges have a price. Buy it when the constraint is external and durable enough to write on one line: a jurisdiction rule, or a customer's data center you don't control. Don't buy it as a substitute for a cutover date.

The practical version is a single rule we'd put in every migration plan that includes a deploy-anywhere layer: the hybrid phase gets an end date, an owner, and a monthly cost figure, all approved at the same meeting that approves the architecture. If the committee won't set the date, the technology isn't the problem, and no engine will fix it.

If you want that evaluation run properly, with the operations cost modeled, the hybrid spend attributed, and the proof-of-concept scoped against your actual workload, that's the kind of fixed-scope engagement our Professional Services team does.