Google has announced general availability of Spanner Omni, which enables companies to run Spanner technology in their own data centers and on infrastructure outside of Google Cloud.
The September 30 release takes Spanner Omni out of preview and into software that’s built for commercial production workloads. Companies can run it in virtual machines or Kubernetes infrastructure in private facilities and other public clouds, and developers are able to run a smaller deployment locally during development and testing.
That changes where Spanner can go. Spanner has traditionally been used as a managed Google Cloud database. Spanner Omni decouples the database software from that hosting requirement, while maintaining the core of Spanner behavior, e.g., transactions distributed horizontally, ACID, strong consistency, and automatic distribution of data.
Now, for organizations that keep some applications close to private infrastructure, across multiple cloud providers, or with regional computing estates, the database can reside closer to certain applications without moving the entire application into Google Cloud.
One Spanner database spanning private infrastructure and other clouds
Spanner Omni can run on virtual machines, Linux containers, and Kubernetes clusters. Google outlines deployment options from a single machine to installations across zones, regions and clusters.
A software company could build against Spanner Omni on a workstation, run another instance in its own Kubernetes estate, and use managed Spanner for applications already hosted on Google Cloud. The common database model can help reduce the amount of rewriting of the application that is needed when the software must run in different locations.
This portability has real-world implications for companies with contractual data-location requirements, private computing estates, cloud-provider preferences, or applications that cannot be moved as one large migration project.
Google says the commercial version is available on an annual subscription basis by vCPU usage. For noncommercial development, testing and prototyping, there is also a Developer Edition.
Spanner Omni stores multiple data types in one database
The database supports relational records, key-value data, graph data and vectors. It also provides full text search and analytical processing. Support for GoogleSQL, Spanner Graph Language, and the PostgreSQL dialect.
That combination is useful when an app needs to use the same underlying information in multiple ways. For example, a customer application may maintain normal account records in relational tables, but use vector embeddings for semantic retrieval. You can query relationships between accounts, contacts or transactions as graph data without moving the records into a separate graph database.
Vector search can store and index embeddings along with transactional records. Spanner Omni supports KNN and approximate KNN queries, thus allowing semantic matching to be combined with SQL filters.
Spanner Graph extends the same database engine with property graph queries. An application can follow relations between entities and combine these relations with vector retrieval.
That can mean fewer separate databases to run for application teams when a product requires transactions, graph relationships, semantic retrieval and search against the same body of information.
Spanner Omni provides AI apps with a database that can remain close to private data
And Google is investing heavily in AI software that requires persistent operational data.
Spanner Omni supports the Model Context Protocol using Google’s MCP Toolbox. This connection allows applications using MCP to inspect database schemas, obtain information, and access records stored in Spanner Omni during the execution of application functions.
The company could host its application database in-house and an AI application could work through the interface with approved records.
In addition to normal transactional information, the database can also store vector embeddings. This is useful for applications that want semantic retrieval but cannot treat the vector store as a separate copy of the business database.
Insurance application may require customer records, policy relationships and embedding-based document retrieval. A commerce system may involve inventory tables, product relationships and semantic product matching. A service system could keep the account history, cases and vectorized knowledge close to the application that uses them.
These patterns do not require that all the AI workloads be hosted in the same public cloud as the database.
General availability adds features for production installations
The GA edition adds some things over the original preview.
Now TLS encryption is available for safe communication. Google also offers authentication, authorization and audit logging as security controls for commercial deployments.
Operational data can be protected and recovered through backup and restore capabilities to compensate for accidental deletion or corruption.
Worker nodes have also been added by Google. These are stateless compute nodes for background or resource-heavy work that otherwise would be competing with the primary Spanner Omni servers processing database requests.
Google Cloud Customer Care is available to commercial customers for Spanner Omni deployments.
These enhancements make the GA edition quite different from the preview that was announced at Google Cloud Next in April 2026 and was for evaluation and development purposes.
Attio is already running Spanner Omni next to managed Spanner
Google cited London-based CRM firm Attio as one of the companies using Spanner Omni.
Attio was already built on Spanner. It now runs its application environment across different infrastructure regions using the same database family, thanks to a containerized Spanner Omni deployment, combined with managed Spanner.
The arrangement allows Attio to use Spanner functions across its environments and to put workloads like Spanner queues into production, said Alexander Christie, co-founder and CTO at Attio.
The example is an early look at the operating pattern Google is after: managed Spanner where Google Cloud is a good fit for the application, Spanner Omni where the database needs to live somewhere else.
The self-managed model puts infrastructure teams in direct control
Spanner Omni is a self-managed offering.
The companies running it are responsible for routine maintenance, upgrades, infrastructure monitoring and the machines or Kubernetes clusters underneath the database. Google does not offer infrastructure availability SLA for customer-managed Spanner Omni installations. Google provides reference architectures for teams who need availability characteristics such as managed deployments.
This is an important difference from the managed Spanner service. For customers who want Google to run the underlying database service, Managed Spanner is the Google Cloud option. Spanner Omni is designed for use cases where control of the database location and infrastructure is part of the requirement.
Some integrations directly tied to Google Cloud are specific to managed Spanner. Google said that among the functions not included in the portable Spanner Omni package are native connections to services including BigQuery, Knowledge Catalog and Gemini Enterprise. Google says the other differences in features between the two products will be removed in later releases.
You can deploy to a laptop or to distributed clusters.
A developer can spin up Spanner Omni as a single-server deployment. Google also provides container images, standalone binaries, a command line interface, and Helm charts for Kubernetes installs.
For larger installations you can distribute the Spanner Omni servers across zones and clusters.
At its heart, it uses Paxos-based replication, automatic sharding and a software implementation of Google’s TrueTime API for its database. These mechanisms provide transactional consistency and allow data to be distributed between servers as the database scales up in demand.
Spanner Omni has a console dedicated to database health and operational data. Administrators can view CPU usage, memory, storage, latency, throughput and query activity.
This provides companies with several ways of inserting the same database technology into their existing infrastructure practices, rather than a single hosting model.
Spanner is no longer bound by a single cloud boundary
Spanner Omni tests the physical limits of one of Google’s most recognizable database technologies.
A database that was built for Google’s distributed infrastructure can now run inside infrastructure controlled by the customer, on another public cloud or in a hybrid deployment that includes managed Spanner.
The most compelling use cases are simple: apps that require strong transactional consistency but cannot move all workloads to Google Cloud; companies with private or regional computing estates; software vendors seeking a common database across customer environments; and AI apps that need SQL records, graphs, vectors and search features close to operational data.
Google announced Spanner Omni in preview on April 22, 2026. Five months later, the Sept. 30 GA release provides the commercial licensing, security controls, backup functions, support model and production tooling needed to take those installations beyond evaluation.
Spanner began as infrastructure that developers accessed through Google Cloud. Spanner Omni gives organizations yet another option: move the database to the infrastructure where the applications and data already reside.