"Oracle support costs have increased again." "We want to optimize SQL Server licenses without taking our core systems down." Consultations regarding core database reassessments, particularly in finance, manufacturing, and the public sector, have risen noticeably in 2026. A new contender in this landscape is Spanner Omni, released in preview by Google Cloud. By allowing Spanner—previously a cloud-only, large-scale distributed RDB—to be installed on local machines on-premises or in other clouds, it has become a pragmatic option for core systems in hybrid or isolated network environments.
This article organizes design guidelines and data migration steps for adopting Spanner Omni in client projects aimed at phased legacy replacements from Oracle and SQL Server.
Why an on-premises Spanner was needed
Historically, Spanner was a closed service operating exclusively on Google Cloud. However, enterprise client projects consistently run into the following blockers:
| Constraint | Context |
|---|---|
| Data export prohibited | Regulations in finance, healthcare, and public sectors |
| Remaining datacenter depreciation | Recouping hardware investments |
| Isolated network requirement | Only private network connections allowed |
| Multi-cloud strategy | Wanting to use the same DB on AWS / Azure |
These constraints led to the recurring conclusion: "We want Spanner, but we cannot adopt it because it's cloud-only." Spanner Omni was created to eliminate this cloud-only limitation. Positioned as an extension of the Google Distributed Cloud (GDC) family, it allows teams to deploy Spanner clusters directly on on-premises or multi-cloud infrastructure.
Architectural overview: 3 deployment patterns
In client development, we choose from the following three patterns based on requirements:
Pattern A: Pure on-premises deployment
- Build Spanner Omni clusters inside company datacenters
- Zero data leaves internal infrastructure
- Complies with strict finance, healthcare, and public sector regulations
- Operated by in-house teams (or custom development contractors)
Pattern B: Hybrid deployment
- Core transactional data sits in on-premises Spanner Omni; analytics run on GCP Spanner / BigQuery
- Replicate only the last N days of data to the cloud
- Leverage cloud compute resources for heavy aggregations
Pattern C: Multi-cloud deployment
- Install Spanner Omni on VMs across AWS or Azure
- Leverage existing cloud contracts and Reserved Instances while benefiting from Spanner capabilities
- Functions as the core unified DB in a multi-cloud strategy
During initial discovery, we always determine which constraint is primary: data export prohibitions, cloud analytics for recent data, or a multi-cloud strategy. This decision dictates the deployment pattern and the subsequent migration plan.
Phased migration steps from Oracle / SQL Server
Replacing legacy core systems must always be done incrementally. Big bang cutovers present unacceptable technical and organizational risks. Here are the five standard steps we follow in client development:
Step 1: Schema and SQL audit
- Extract all DDL and classify unsupported features (PL/SQL stored procedures, triggers, complex recursive CTEs, etc.)
- Perform static analysis on application queries to evaluate compatibility with Spanner's SQL dialect
- Create separate rewrite plans for stored procedures that must be retained
Step 2: Dual writing (shadow write)
- Applications write to the existing DB while simultaneously writing to Spanner Omni
- Detect consistency discrepancies via daily batch reconciliations
- Spend 1–2 months flushing out logic bugs on the application side
async function createOrder(order: Order) {
await tx(async () => {
await oracleRepo.insertOrder(order);
try {
await spannerRepo.insertOrder(order);
} catch (e) {
logger.warn({ err: e, order }, "shadow write failed");
}
});
}Dual writing must be architected so that Spanner failures never take down the application.
Step 3: Shadow reading
- Applications read from both databases, compare results, and log discrepancies
- Trigger alerts only when mismatches occur
- Fine-tune Spanner query performance using real production workloads
Step 4: Canary traffic migration
- Shift primary traffic to Spanner incrementally: 1% → 5% → 25% → 100%
- Fail back immediately to Oracle if issues arise
- Design canaries across combinations of features, tenants, or read/write splits
Step 5: Decommissioning Oracle / SQL Server
- Terminate licenses after confirming stable standalone Spanner operation for 30 days
- Retain backups in separate storage (retained for 7 years if regulatory compliance requires)
The principle of prioritizing business continuity outlined in our Guidelines for phased core system replacements applies equally to database migrations.
Spanner design essentials: 4 critical points for client projects
1. Primary key design dictates overall performance
Because Spanner is a distributed database, primary keys that cause hotspots throttle overall throughput. Use UUID v4 or reversed timestamps + sequence numbers as the baseline, avoiding monotonically increasing IDs like AUTO_INCREMENT.
2. Accelerate JOINs with interleaved tables
For parent-child tables (e.g., Orders → OrderItems), configuring them as interleaved co-locates them physically on the same split, drastically reducing JOIN overhead. This optimization is frequently missed when naively migrating Oracle schemas.
3. Global consistency is a trade-off between cost and latency
Spanner's TrueTime consistency is powerful, but in multi-region topologies, write latency depends directly on inter-region round-trip times (RTT). With Omni, consistency levels and region topologies must be tailored to the deployment pattern on a per-project basis.
4. Cap monitoring thresholds at 65% CPU utilization per node
Spanner latency spikes sharply when CPU utilization exceeds 65%. Apply this same rule to Omni by incorporating automated horizontal scaling upfront via Kubernetes custom operators.
Vendor coordination and contract alignment
A surprisingly heavy aspect of database replacements is communicating with existing vendors, including Oracle, Microsoft, and incumbent system integrators. Key discussion points to align with clients include:
| Discussion point | Alignment perspective |
|---|---|
| Phased license reductions | Running both systems concurrently inflates transition costs |
| Existing support contracts | Determining what post-cutover issue coverage to retain |
| Data retention obligations | How many years legacy DBs must be archived for compliance |
| Knowledge transfer | Handing off operational expertise from incumbent SIs to Spanner teams |
The boundaries of responsibility addressed in our Enterprise client project design guidelines with Salesforce Headless 360 provide a useful framework here as well.
Conclusion
Spanner Omni brings global distributed RDB capabilities to on-premises, isolated, and multi-cloud core systems previously locked out of cloud services. Keep these five principles in mind for client development:
- Categorize deployments into pure on-premises, hybrid, or multi-cloud
- Execute phased migrations: shadow write → shadow read → canary
- Ensure performance through primary key design and table interleaving
- Automate scaling capped at a 65% CPU ceiling
- Agree on responsibility boundaries with incumbent vendors early in the contract
At GleamHub, we design and evaluate core replacement projects from Oracle and SQL Server, including Spanner Omni as an architectural option. If you previously gave up on Spanner due to cloud constraints, reach out to explore your options.
