Databases

AI Studio unlocks full-stack vibe coding with Cloud Run, Firebase, and Cloud SQL, no credit card required

Thu, 21 May 2026 16:00:00 +0000

At Google I/O 2026, we announced updates to the integration between Google AI Studio and Google Cloud:

New users can deploy up to two full-stack applications to the Google Cloud Starter Tier, no billing account required
An expanded choice of databases: Firestore for non-relational data, and Cloud SQL as a new relational database option
Tight integration with Google Workspace tools like Sheets, Calendar, and Gmail using Firebase Auth as the single user login flow

This is an update to the integration we announced in March, which included support for vibe-coded full-stack app deployments from AI Studio powered by Cloud Run, Firestore, and Firebase Auth.

With this expanded integration, you can use AI Studio to build a broader set of applications, using either a relational database with Cloud SQL or a non-relational database with Firestore. You don’t even need to specify a database — the AI agent can infer the right database for your app or feature.

Get started today in AI Studio at no cost with Cloud Run, Cloud SQL for PostgreSQL (coming next month), Firestore, and Firebase Auth for Starter Tier.

Publishing a full-stack app from AI Studio to Cloud Run with a single click

An easy on-ramp: The Google Cloud Starter Tier

You can build applications in AI Studio and deploy your prototypes directly to Cloud Run, authenticate via Firebase Auth, and store your data in a Firestore or Cloud SQL database. No credit card, no Google Cloud account, no friction — just prompt and launch.

If you don’t have an account, AI Studio uses the Google Cloud Starter Tier to create resources for you. You can deploy up to two full-stack apps. If you outgrow the limits of the Starter Tier, you can upgrade to a standard Google Cloud project with a billing account. All your resources will be transferred to your billable Google Cloud project, so that your application can scale as it grows.

Powering full-stack vibe coding with Cloud SQL

We’re introducing an intelligent, automated data foundation that makes it easy for developers to focus on their applications, not their infrastructure.

AI Studio integration with Cloud SQL includes:

An instant on-ramp: Go from prompt to a fully-deployed PostgreSQL database rapidly with instant provisioning.
Zero-cost startup: Try Cloud SQL for the Google Cloud Starter Tier at no cost, without needing a credit card or Google Cloud account.
Flexible cost control: The AI agent uses a new Cloud SQL for PostgreSQL developer edition, which enables the backend to scale to zero automatically, so you only pay while you’re using the app.
Agent-driven experience: To update your application, enter new prompts and the AI Agent automatically creates the schema and executes SQL statements in the database.
Global scalability: While the interface is simple, your app runs on Google Cloud’s robust, highly-reliable, and securely designed infrastructure that can scale to support millions of users.

Creating an app powered by Cloud SQL for PostgreSQL developer edition

Full-stack vibe coding with Firestore and Firebase Auth

When you’re building an app in AI Studio, the agent proactively detects if you need data storage and authentication based on your prompt, and offers to set up a database and user authentication. For apps that benefit from a document database, the agent shows a card to turn on Firestore and Firebase Authentication with your approval.

Enable Firebase for your application when prompted by the agent

By clicking “Enable Firebase,” the agent automatically:

Provisions Firestore, enables authentication, and connects your app to the database
Creates your web app’s sign-in page and configures authentication with Google Sign In
Generates the Firestore code in your app so you can sync data across sessions and devices
Drafts and deploys Firestore Security Rules based on your app’s logic (but you should always double-check these rules before sharing or deploying your app!)

With Firebase Auth, you can:

Connect your apps to Google Workspace using natural language: When you ask for a feature involving Workspace (e.g. Sheets, Calendar, Gmail), the agent implements a “Sign in with Google” flow, powered by Firebase Authentication, designed to securely grant Google AI Studio access to your data.

Connect your app to Google Sheets, powered by Firebase Authentication

Check out more details on the What’s New from Firebase at Google I/O blog.

Getting started in AI Studio

Going from idea to app is now a reality. You can build a full-stack application at no cost using the following steps:

Log into AI Studio: Access the platform to begin your project.
Build with prompts: Start building your application using natural language prompts. For example, “Build an expense tracker app.”
Enable the database: Prompt “Add a database” and AI Studio intelligently provisions a database through an "Enable" widget. You can explicitly ask for a relational database if you’d like to make your preference clear.
Set up the system: Select “Enable” and agree to the terms.
Start sharing: Deploy and share the application through the “Publish” button.

Get started today in AI Studio to turn your ideas into live applications in seconds.

Urban Outfitters achieves major cost savings by moving Sterling OMS to AlloyDB for PostgreSQL

Wed, 20 May 2026 16:00:00 +0000

Editor’s note: Urban Outfitters, Inc. (URBN) recently completed a major infrastructure upgrade, migrating its IBM Sterling Order Management System (Sterling OMS) from an Oracle database to Google Cloud's AlloyDB for PostgreSQL. This strategic move, a testament to the growing partnership between Google Cloud and IBM, delivers significant benefits for URBN, paving the way for increased efficiency, reduced costs, and a future-proofed technology landscape. This success story showcases how businesses can leverage AlloyDB for PostgreSQL to modernize their databases and unlock new levels of performance and scalability.

In the fast-paced world of retail, order management is the backbone of a seamless customer experience. Urban Outfitters, Inc. (URBN) relies on IBM Sterling Order Management System (Sterling OMS) as the nerve center of its global ecommerce operations, orchestrating everything from order capture and real-time inventory tracking to fulfillment optimization and post-purchase logistics. This system helps ensure that URBN can efficiently process millions of transactions across its global network of stores, warehouses, and digital channels, delivering on customer expectations for fast, accurate, and flexible order fulfillment.

However, the foundation of this critical system — a massive 11TB Oracle database — was increasingly becoming a bottleneck. High licensing and maintenance costs, growing operational complexity, and the constraints of proprietary technology posed significant challenges to scalability and long-term innovation. To maintain Sterling OMS's high availability, performance, and transactional integrity, URBN needed a modern database solution that could:

Reduce total cost of ownership (TCO): Lower licensing, operational overhead, and infrastructure expenses while maintaining reliability.
Ensure business continuity: Support high availability, rapid failover, and disaster recovery to prevent disruptions in order processing and customer transactions.
Embrace open standards: Transition from proprietary technology and embrace open, flexible, and future-proof solutions.
Maintain feature parity: Ensure a seamless migration without disrupting Sterling OMS functionality, keeping all mission-critical capabilities intact.

For a retail enterprise like URBN, even minor disruptions to order management can have significant financial and operational consequences. A failed transaction, an inventory miscalculation, or a delay in fulfillment can directly impact customer satisfaction, brand reputation, and revenue. Because Sterling OMS is so mission-critical, URBN required a migration approach that was as technically robust as it was precise — demanding a transition with near-zero downtime, data loss, or performance degradation.

The solution: AlloyDB for PostgreSQL

The success of this complex transition hinged on a deep, ongoing collaboration between URBN, IBM, and Google Cloud. This partnership brought together industry-leading expertise and cutting-edge technology, with teams working in lockstep to ensure high-touch engagement throughout every phase. By embedding dedicated IBM and Google Cloud engineers directly with URBN’s technical staff, the teams were able to meticulously plan and optimize the migration of the massive database.

The project’s success was defined by several critical pillars:

First-tier database recognition and feature development: IBM and Google Cloud engineering teams collaborated to ensure that Sterling OMS fully recognized and supported AlloyDB for PostgreSQL as a first-tier database.
Enterprise-grade reliability with two read replicas: To enhance performance and provide high availability and scalability, the AlloyDB deployment architecture includes two read replicas, providing low-latency access to data for reporting and analytics and improving operational resiliency of the entire Sterling OMS application.
Extensive performance tuning: A dedicated performance engineering team from Google Cloud worked alongside URBN and IBM experts to fine-tune database queries and optimize configurations. This level of continuous, high-class support ensured AlloyDB not only met but exceeded the performance benchmarks of the previous Oracle database. This was essential to handle the high transaction volume of the Sterling OMS on AlloyDB for a very large retail customer, the size of URBN.
Rigorous switchover testing and risk mitigation: Google Cloud and IBM teams assisted URBN in a rigorous, iterative switchover testing strategy, which involved running the Sterling OMS system on AlloyDB for a full day before switching back to the Oracle database. This proactive testing allowed URBN teams to identify and resolve potential issues in a controlled environment, significantly reducing risks and increasing confidence in the migrated system.

aside_block: <ListValue: [StructValue([('title', 'Build smarter with Google Cloud databases.'), ('body', <wagtail.rich_text.RichText object at 0x7f051d8ef370>), ('btn_text', ''), ('href', ''), ('image', None)])]>

A transformative shift

The migration to AlloyDB has fundamentally reshaped URBN’s data strategy, delivering a more favorable TCO through an optimized storage and compute architecture, without sacrificing performance or reliability. Furthermore, the shift to AlloyDB, a PostgreSQL-compatible database, gave URBN the flexibility of an open-source ecosystem. This move not only provides freedom from vendor lock-in, but also connects URBN to a vibrant community and a vast array of modern tools, ensuring long-term technical agility.

Beyond cost and flexibility, the transition unlocked superior performance and scalability to support URBN’s mission-critical operations. The combination of an optimized database kernel and precise query tuning resulted in significant speed improvements, directly enhancing the responsiveness of the Sterling Commerce system.

A blueprint for success: Planning and testing

URBN’s successful migration of IBM Sterling OMS to AlloyDB serves as a blueprint for organizations looking to modernize their mission-critical infrastructure and future-proof their environment for AI expansion. This journey proves that even the most complex, mission-critical migrations can be achieved through deep cross-organizational partnership and a phased, risk-mitigated approach.

For any enterprise navigating the challenges of modernization, URBN’s experience offers a clear roadmap for success. The use of iterative switchover tests — running the system on AlloyDB and switching back — was the "secret sauce" that built the necessary confidence for the go-live. By prioritizing this level of rigorous testing, businesses can move toward a future of greater agility, efficiency, and innovation.

Learn more:

Discover how AlloyDB combines the best of PostgreSQL with the power of Google Cloud in our latest e-book.
Try AlloyDB at no cost for 30 days with AlloyDB free trial clusters!
Learn more about AlloyDB for PostgreSQL.

What’s new with Google Data Cloud

Thu, 14 May 2026 16:00:00 +0000

May 11 - May 15

Managed Service for Apache Airflow has launched a wave of new features, including the general availability of Airflow 3.1, AI-powered agentic troubleshooting, a new managed Airflow MCP Server for custom agent integration, and declarative YAML-based orchestration pipelines—discover all the details in the full blog post.

April 20 - April 24

Google-built ODBC Driver for BigQuery is now available in Preview
We are excited to announce the launch of the new, Google-built ODBC driver for BigQuery. This new open-source driver provides a direct, high-performance connection for applications to BigQuery and is developed entirely in-house by Google. Download a new driver and connect your application to BigQuery.

April 13 - April 17

We announced we are reintroducing Data Studio to play a significant role in the AI era, expanding from data visualizations and reports to host BigQuery conversational agents and data apps built in Colab notebooks.
We announced BigQuery Graph is now available in preview, offering an easy-to-use, highly scalable graph analytics solution, empowering data professionals to model, analyze and visualize massive-scale relationships in an entirely new way.

April 6 - April 10

We introduced Conversational Analytics for Looker Embedded environments, enabling users to add natural language experiences to their own custom data-driven applications, powered by Gemini.
We expanded Looker’s capabilities for faster ad-hoc analysis, with the introduction of self-service Explores, enabling you to bring your own data to Looker’s semantic layer and gain instant access to insights in a governed data environment.

March 23 - March 27

We showed you how you can scale your reads with Cloud SQL autoscaling read pools. This feature allows you to provision multiple read replicas that are accessible via a single read endpoint and to dynamically adjust your read capability based on real-time application needs.
Our customers are leveraging the full power of Conversational Analytics and Looker to drive major business and technical breakthroughs in the AI era. Companies like Telenor, Pet Circle, Fluent Commerce, Lighthouse Intelligence, Wego, and ROLLER are turning data into insights and actions, grounded by Looker’s semantic layer.

March 16 - March 20

We introduced an enhanced Gemini assistant in BigQuery Studio, transforming the agent from a code assistant into a fully context-aware analytics partner.

February 23 - February 27

We introduced managed and remote MCP support for Google Cloud databases, including AlloyDB, Spanner, Cloud SQL, Bigtable and Firestore, to power the next generation of agents. This announcement extends the ability for AI models to plan, build, and solve complex problems, connecting to the database tools our customers leverage daily as the backbone of their work environment.
We outlined how you can build a conversational agent in BigQuery using the Conversational Analytics API to help you build context-aware agents that can understand natural language, query your BigQuery data, and deliver answers in text, tables, and visual charts.

February 16 - February 20

Our customers are leveraging the full power of Looker to drive major business and technical breakthroughs. Companies like Arrive, Audika, Carousell, Framebridge, GumGum, Intel, Overdose Digital, Ocean Network Express, Subskribe and Promevo are leveraging Looker’s newest AI-driven capabilities, including Conversational Analytics, to transform data to insights and actions, and empower their entire organization with a single source of truth, powered by Looker’s semantic layer.

February 2 - February 6

Join us on March 4 for our webinar, Win Your AI Strategy with Cloud SQL Enterprise Plus, to learn how to power your generative AI workloads with 3x higher performance and 99.99% availability. Register today to discover how to build a scalable, enterprise-grade foundation for your most demanding AI applications.

January 26 - January 30

We introduced Conversational Analytics in BigQuery, which allows users to analyze data using natural language. Conversational Analytics in BigQuery is an intelligent agent that generates, executes and visualizes answers grounded in your business context directly in BigQuery Studio, making data insights for data professionals more conversational.
We outlined how data products have become the foundation for AI agents, providing the context needed to make autonomous agents reliable and trusted for real business use, backed by organized business logic and semantic understanding.
We highlighted how you can supercharge data analytics workflows, and outlined Google Cloud’s AI agent offerings for data engineering, data science, and development tools, so you can integrate agentic workflows in your applications, empower your teams and speed discovery.

January 19 - January 23

We have fundamentally reimagined Firestore with pipeline operations for Enterprise edition. Experience a powerful new engine featuring over a hundred new query features, index-less queries, new index types, and observability tooling to improve query performance. Seamlessly migrate using built-in tools and leverage Firestore’s existing differentiated serverless foundation, virtually unlimited scale, and industry-leading SLA. Join a community of 600K developers to craft expressive applications that maximize the benefits of rich queryability, real-time listen queries, robust offline caching, and cutting-edge AI-assistive coding integrations.
Introducing Google Cloud SQL on MSSQLTips: We are highlighting a new technical guide published on MSSQLTips titled "Introducing Google Cloud SQL." This article serves as an essential resource for SQL Server administrators and developers exploring Google Cloud's fully managed database service. It provides a detailed overview of Cloud SQL capabilities, including high availability, security integration, and the seamless transition of on-premises SQL Server workloads to the cloud, making it an ideal resource for those planning their migration strategy.
We are excited to announce the Public Preview of Microsoft Entra ID (formerly Azure Active Directory) integration with Cloud SQL for SQL Server. Designed to tackle the challenge of identity sprawl in multi-cloud environments, this integration allows organizations to govern database access using their existing Microsoft identity infrastructure. Key benefits include centralized identity management, enhanced security features like Multi-Factor Authentication (MFA), and simplified user administration through direct group mapping. This feature is available for SQL Server 2022 and supports both public and private IP configurations.

January 12 - January 16

Google-built JDBC Driver for BigQuery is now available in Preview
We are excited to announce the launch of the new, Google-built JDBC driver for BigQuery. This new open-source driver provides a direct, high-performance connection for Java applications to BigQuery and is developed entirely in-house by Google. Download a new driver and connect your Java application to BigQuery.
Troubleshoot Airflow tasks instantly with Gemini Cloud Assist investigations: Cloud Composer just got smarter. We are excited to announce that Gemini Cloud Assist investigations are now available directly within Cloud Composer 3. Instead of manually sifting through raw logs, you can now simply click "Investigate" on a failed Airflow task. Gemini analyzes logs and task metadata to identify failure patterns—such as resource exhaustion or timeouts—and provides actionable recommendations driven by Gemini Cloud Assist to resolve the issue. This integration shifts the debugging experience from manual toil to automated root cause analysis, significantly reducing the time required to restore your pipelines. Learn more about AI-assisted troubleshooting.

The power of LLMs on your data, more than two orders of magnitude faster and cheaper

Wed, 13 May 2026 16:00:00 +0000

Databases have introduced new AI-powered SQL functions which take natural language instructions as input and are evaluated using LLMs. They leverage the power of LLMs to answer new kinds of queries: Which product reviews are negative about durability? Which customer support tickets have been resolved by providing a workaround?

These new AI functions push the boundaries of what is possible in a SQL query engine by bringing the semantic understanding of LLMs to your data, thus enabling previously impossible analyses and applications. But, their cost and performance limited their applicability. LLM invocations add 10-100x to the overall query latency and ~1000x on cost. This is much too slow for operational databases. In analytics, a medium-sized query on 10-100 millions of rows would consume an amount of tokens that is prohibitively expensive for some applications.

Google Cloud has published a new paper at SIGMOD where we show how to accelerate and reduce the cost of LLM-powered AI functions by using proxy models. Proxy models are cost-optimized ultra-lightweight models tailored to a specific query (aka prompt) and tuned for your data. They replace the majority of LLM calls during query execution (thus the name proxy model) and can be trained on-the-fly or ahead of time. The fundamental ideas behind proxy models were proposed in Universal Query Engine (UQE) at NeurIPS 2024 by Google DeepMind.

Our paper shows that proxy models are automatically applicable in many (but not all) cases, sometimes with no loss of quality, sometimes with minor quality loss and a few times with a gain of quality. BigQuery and AlloyDB already implement this optimization under the optimized mode feature for AI.IF (BigQuery docs, AlloyDB docs) and AI.CLASSIFY (BigQuery docs). This article is a tl;dr of the SIGMOD paper and provides the key intuitions on three questions:

Why do proxy models work so accurately for so many cases, even though they are so much more performant than LLMs?
How do they work?
In which use cases do they deliver accurate answers? In which cases they fail and accuracy needs LLMs.

Why Proxy Models Work Accurately at Ultra Low Latency and Cost?

How can an ultra-lightweight proxy model, such as the logistic regression currently in use at BigQuery and AlloyDB, have the semantic understanding power of LLMs, which is required for accurate question answering? The key intuition is that these proxy models input rich embeddings of the data that they query. By default, we are using the Gemini embedding generators, which do the heavy lifting of bringing semantics to your data when the embeddings are generated.

Then the ultra low latency and cost are easy to see: Since embeddings are generated once and used many times, the cost of bringing semantics to your data is amortized; it now happens once as opposed to happening for each query. Furthermore, the proxy models run fast in the CPU — no need for dedicated hardware.

We hope that we gave you good intuitions for why proxy models work. But a word of caution is also needed: Proxy models are fundamentally an approximation technique more limited than LLMs. Proxy models perform well on some prompts but may be deficient to LLMs in others. Case in point, the SIGMOD26 paper shows that the proxy/LLM predictive performance (as measured by F1) ratio ranged from 90% to 116% in 10 benchmarks. For example, they might break down on problems that require reasoning to connect multiple semantic concepts. Rather, think of them as specializing the model to your query and your data.

The good news is that the query processors automatically check the effectiveness and feasibility of implementing AI Functions by proxies. Let’s see how they do it.

How Proxy Models Work?

Let’s go through a simple example of a semantic filter (AI.IF). Our taste in movies is very particular: We like movies with an interesting plot and great cinematography. The query below processes IMDB reviews to find such movies.

code_block: <ListValue: [StructValue([('code', 'SELECT\r\n DISTINCT t.primary_title\r\n FROM \r\n bigquery-public-data.imdb.reviews r, \r\n bigquery-public-data.imdb.title_basics t\r\n WHERE TRUE\r\n AND r.movie_id = t.tconst\r\n AND AI.IF("Is the plot interesting? Review: " || r.review, \r\n embeddings => r.review_embedded)\r\n AND AI.IF("Does the review praise the cinematography? Review: " || r.review, \r\n embeddings => r.review_embedded)'), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7f051da180d0>)])]>

The column review contains the free-form text of the review. The column review_embedded contains Gemini embeddings of the review text. When you run this query in BigQuery, the query engine will

For the first AI.IF, create a training samples’ set consisting of about one thousand rows of the input relation, the imdb.reviews table.
Use an LLM to label the first sample set, marking each review as either TRUE (yes, the plot is interesting) or FALSE (no, the plot is not interesting).
Train a proxy model for the first AI.IF using the labels computed at the previous step.
Create a test sample set of rows for the first AI.IF and evaluate the quality of the proxy model on this test set.
Based on the eval results, the optimizer adaptively decides to either perform inference using the proxy model or fall back to LLM inference for the first AI.IF
Repeat the above steps for the second AI.IF

In BigQuery, all steps happen on-the-fly during query execution. AlloyDB, being an operational database that targets sub-second latencies, avoids the online proxy model training and the online evaluation. Rather, the query’s proxy models are computed ahead of time in a PREPARE statement, thus moving the cost of sampling, labelling and training out of the critical query path. This enables the offline creation of a big pool of PREPARE statements, while the application chooses the proper PREPARE statement and executes it in the online path.

Let’s take a step back and look at what is really happening at step #3. The proxy model uses each dimension of the review embeddings (from review_embedded) as its features. Modern dense embedding models like Gecko or Gemini capture myriads of semantic notions. In our example with movie reviews, at a high level of abstraction, relevant notions would include: “aesthetic”, “thought-provoking plot”, “underwhelming plot”, or perhaps “boring movie”. We stress the “high level of abstraction” because, in the binary “language” of foundation models, all these notions (and many more) are spread in the numbers of the dense embedding. Do not expect to spot a dimension that corresponds directly to cinematography. Importantly, the embedding space contains many more notions that are irrelevant to our task. The training of the proxy model essentially weighs heavily relevant notions and discards irrelevant ones.

A proxy model (green plane) isolating relevant semantic notions by cutting the embedding space (blue sphere)

Now, let’s enter the details of the particular proxy model, which is used by our current version: logistic regression. To visualize what is happening, think of embeddings as unit vectors forming a (hyper)sphere. For a binary classification task, the proxy model essentially cuts the sphere in two halves. In our example “aesthetic” and “thought-provoking plot” would fall on one side of the plane, whereas “underwhelming plot” and “boring movie” would be on the other side. Conceptually, the orientation of the plane determines which semantic notions are more relevant.

Importantly, the proxy model is tuned for your data and your question: The training of the proxy used a high quality LLM to label a sample from your data for the particular question.

Revisiting when Proxy Models Work

We can now see more clearly what distinguishes cases that proxy models work from cases they don’t: proxy models work well for prompts that can be decided by detecting semantic notions in the embedding space. They will fail for complex prompts that require forms of reasoning that go beyond detecting patterns in the embedding model.

The good news is that, in practice, we have observed that proxy models work for a large class of AI+SQL queries. The SIGMOD26 paper provides a comprehensive evaluation, showing that proxies worked in 11 benchmarks. Specifically, in 10 benchmarks the ratio of proxy F1 to LLM F1 ranged from 90% to 102% and in the 11th benchmark (Amazon Reviews) it was 116%. Notice that the proxy may even deliver better accuracy because it got the benefit of being trained by multiple samples as opposed to the LLM that addressed each row as a new problem.

There is a second limitation currently: extreme selectivities. Notice that Step 1 collects samples. It needs to collect many examples for TRUE and many examples for FALSE. Multiple sophisticated techniques are employed to achieve this, even when the TRUEs are many more than the FALSEs or vice versa. However, no purely sampling technique can confront cases of extreme selectivity, i.e., cases of very few TRUEs or very few FALSEs. This is the reason that the proxies will not be employed in such extreme selectivity cases. However, notice that this problem is fundamentally addressable by various techniques.

Why isn’t Vector Search Enough?

Proxy models appear … suspiciously close to vector search. After all, they also input vector embeddings. Why not just vector search? There are two reasons why vector search is not enough: The obvious one is that proxies are not rankers; they are classifiers: multiclass classifiers (AI.CLASSIFY) or binary classifiers (AI.IF). But, even if you narrow down to just AI.IF, an attempt to simulate AI.IF with vector search will be both hard-to-setup and will give suboptimal results. While proxy models are tailored to your data and your prompts, vector search is based on generic distance functions (such as cosine).

Experimental Results

We present here a subset of characteristic benchmarks from the SIGMOD26 paper. We compare the accuracy of proxy models with using LLM inference on all rows. In terms of quality, the relative accuracy varies from 0.92 (lowest) to 1.16 (highest), which means that for some tasks, proxy models perform slightly better than straight LLM inference.

Dataset	Prompt	F1 (Proxy)	F1 (LLM)	Relative (Proxy/LLM)
Amazon Reviews 10k	Review is {sentiment label}	0.860	0.739	1.163
Banking77	Is intent {intent label}? Think step-by-step: {CoT instructions}	0.700	0.707	0.990
California Housing	Location in Latitude & Longitude belongs to Southern California	0.953	0.953	1.0
FEVER	Is the claim supported by the text?	0.782	0.853	0.917

In terms of scalability and costs, the architectural differences between BigQuery and AlloyDB lead to slightly different results for each system. At a high-level, proxy models move parts of the computation from specialized hardware used by LLM inference services to ordinary database workers. This results in a large reduction in costs and in query latency. In the online training case, employed by BigQuery, for a typical one million row query, proxy models consume about 400x less tokens, and the latency goes down by 30x-100x. In AlloyDB’s case the LLM costs of PREPARE, which are similar to BigQuery’s, can be amortized over arbitrarily many runs of the prepared statements that invoke proxy models.

The cost reduction (token consumed) and latency improvement (query speed up) for various table sizes.

Conclusion

AI functions calling LLMs are becoming commonplace in databases. Choosing the proper model for each AI function is an active area of academic research (e.g. BARGAIN). The key intuition is right-sizing models: Performant cheap models for “easy” problems, powerful reasoning models for the hard problems. Our work builds on the same principles, but while academic research has only used LLMs to navigate the performance spectrum, non-LLM proxy models push performance much further using ultra-lightweight and highly specialized models that deliver surprisingly good quality for many problems. Yet, we should not be surprised: After all, the proxy models feed on the rich semantics that foundation models bring to embeddings and they also feed on being trained by LLMs. As embedding models improve and extract increasingly richer and finer semantics from text and multimodal data (image, video), we suspect that non-linear classifiers will be useful to identify even more complex semantic patterns, further extend the applicability of proxy models (e.g. to AI joins also) and explore additional points on the performance/quality Pareto.

If you would like to learn more, our full paper dives into the differences between online vs. offline training, and compares the performance of different embedding models as well as various proxy models (linear regression, SVM, XGB).

You can try proxy models today in BigQuery (docs) and AlloyDB (docs), dramatically speed up the AI Functions of your SQL queries and reduce their token consumption.

_{We would like to thank Bo Dai, Yuchen Zhuang, Xingchen Wan, and Dale Schuurmans from Google Deepmind for developing the fundamental principles on proxy models in UQE and for their continuous guidance & support along our journey to bring them to Cloud customers. We also thank Yeounoh Chung and Fatma Özcan, our partners in the System Research Group, as well as the AlloyDB and BigQuery engineering teams.}

Meet the latest Database Center, now with Gemini-powered fleet intelligence

Mon, 11 May 2026 19:00:00 +0000

Managing a modern database fleet is both a scale and cognitive problem. As database estates grow, the effort required to monitor, troubleshoot, and optimize them often outpaces teams’ capacity, who find themselves fighting database issues in isolation, buried under a mountain of fragmented signals.

We designed Database Center as a single pane of glass that provides fleet-wide visibility across all Google Cloud managed database services. At Google Cloud Next ’26, we announced an AI-native manageability interface for Database Center powered by Gemini that is designed to reason across your entire Data Cloud. In this new era of database operations, Gemini acts as an expert teammate, replacing manual scripts and error-prone workflows with AI-driven observability. In this blog, we showcase several key innovations in Database Center that you can take advantage of today.

Gemini-powered enhancements

Fleet-level intelligence with Gemini-powered analysis: Go from reactive firefighting to proactive, fleet-wide AI analysis. Gemini correlates performance shifts across your estate, highlighting patterns and providing actionable insights with an option for detailed investigations for diagnosis and remediation. These features are in preview with select customers.

Generative views (coming soon): Database Center now offers a hyper-personalized, dynamic interface driven by natural language, moving beyond standard dashboards to surface only the most relevant insights. Users will also be able to iteratively update these views.

Integrating into developer workflows: Database Center APIs are now public and integrated with the Model Context Protocol (MCP), bringing fleet management directly to tools like VS Code and Gemini CLI, as well as enabling custom third-party dashboards.

Gemini-powered chat: A new conversational interface uses natural language to interact with the entire database estate, across services like Cloud SQL, Spanner, or Bigtable, for fleet-wide exploratory questions and contextual troubleshooting, including triggering Investigations for root-cause analysis and remediation.

Gemini-backed recommendation validation (coming soon): Trust is vital for AI recommendations. New Gemini-based recommendation validations are available for specific performance optimizations. Users can trigger a Testing agent to simulate impacts on latency, IOPS, or throughput before applying changes like new indexes or machine upgrades, enabling confident, automated optimization.

Other platform enhancements

There’s more to Database Center than just Gemini. Here are the other enhancements we’ve made to the platform.

BigQuery inventory and data affiliation: BigQuery reservations and datasets inventory are now integrated into Database Center. Reservations and datasets inventory provide a single unified view across Google Cloud Databases and BigQuery. Data affiliation, meanwhile,maps data flows between transactional databases and BigQuery, helping surface hidden dependencies for faster troubleshooting.

Fleet-wide slow query analysis: Instead of hunting through logs and multiple pages, Database Center now centralizes and explains slow queries across the entire fleet, helping you prioritize your remediation efforts with AI-assisted troubleshooting. You can sort query patterns across the organization based on CPU execution time, number of instances, average rows returns, etc., and investigate the most impacted queries first.

Observability for top resources: Instantly identify the top 10 resources by critical metrics (CPU, IOPS, latency, etc.) to jumpstart investigations before they impact users.

Intelligent maintenance policies: For Cloud SQL and AlloyDB, Database Center now provides a unified, intelligent view of fleet maintenance status and compliance across all resources. You can also receive maintenance window suggestions based on your unique usage patterns, preventing downtime during peak business hours.

Reporting: Configure Database Center to generate natural language summaries of fleet health and inventory, delivered directly to your inbox so stakeholders stay informed without ever needing to log into a console.

What are Database Center customers saying

“Database Center gives our teams a comprehensive view of our Google Cloud database fleet and enables proactive risk management across security, performance, and capacity. Some of our product teams are already integrating it into their daily standups to improve monitoring and response. With Database Center’s APIs and MCP tools, we will be able to embed real-time fleet health directly into application team workflows — combining Google’s signals with our internal context like team ownership and application mapping to make insights truly actionable. This reduces context switching, accelerates recovery times, and strengthens proactive ownership across our engineering teams. We’re excited to see how the product continues to evolve.” - Bogdan Capatina, Technical Expert in Database Technologies, Ford Motor Company

Get started with Database Center

The future of database management isn't just unified — it's intelligent. With these new Database Center features and capabilities, you can:

Reduce operational overhead: Eliminate management silos and the need for expensive third-party observability software.
Enjoy faster mean time to resolution (MTTR): Resolve cross-domain issues in minutes rather than hours through Gemini-led correlation.
Scale with confidence: End-to-end lineage monitoring and automated health checks minimize blind spots, so that your AI and apps are powered by fresh, reliable data.

You can access Database Center from Google Cloud managed database services console for Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore and Memorystore. Database Center is enabled by default for users with the necessary IAM permissions at the desired hierarchy. It is available at no cost, although certain premium features, including Gemini-backed fleet performance/ inventory insights, cost recommenders and natural language chat require Gemini Cloud Assist. Advanced security and compliance monitoring requires a Google Security Command Central (SCC) subscription.

Get started with Database Center today:

Future-proof your data strategy: AlloyDB adds PostgreSQL 18 and new Extended Support

Mon, 11 May 2026 16:00:00 +0000

As you look out at your 2026 infrastructure roadmap, your goal is to balance the need for rapid innovation with operational stability. You shouldn't have to choose between adopting the latest database features and maintaining a secure, supported environment for your workloads. Today, we are announcing the general availability of PostgreSQL 18 in AlloyDB and the introduction of Extended Support for older major versions. These updates give you the flexibility to build with the most advanced open-source tools while providing a reliable, long-term safety net for your existing applications.

Maintain stability with Extended Support

Moving production workloads to a new major version is a significant undertaking that requires careful planning and testing. To provide you with the flexibility to upgrade on your own schedule without compromising security, we are introducing Extended Support for AlloyDB.

This new offering bridges the gap between community end-of-life (EOL) dates and your upgrade timelines, ensuring business continuity for your most critical applications.

Key timelines

AlloyDB clusters are eligible for three years of Extended Support and are automatically enrolled according to the following timeline:

PostgreSQL 14: February 1, 2027 through February 1, 2030.
PostgreSQL 15: February 1, 2028 through February 1, 2031.
PostgreSQL 16: February 1, 2029 through February 1, 2032.
PostgreSQL 17: February 1, 2030 through February 1, 2033.
PostgreSQL 18: We will announce the Extended Support timeline at a later date.

What’s included

During the Extended Support period, Google Cloud provides:

Critical security patches: Protection against all High and Critical severity common vulnerabilities and exposures (CVEs)
Proactive bug fixes: Resolution of issues within AlloyDB-maintained code
SLA coverage: Continued availability protection for clusters that meet eligibility criteria.
New cluster creation: The ability to provision new clusters on Extended Support versions

Managing your transition

Extended Support will be available for an additional fee. You’ll be able to opt out at any time by simply upgrading your clusters to a major version in regular support. We'll announce extended support with updated pricing later this year.

Speed up development with PostgreSQL 18 on AlloyDB

PostgreSQL 18 (PG18) introduces features designed to make your applications faster and your development process more intuitive. When you choose PG18 for your AlloyDB clusters, you gain immediate access to performance improvements and modern data handling:

Faster queries with B-tree skip scans: The engine can now bypass index entries that don't match your query, accelerating data retrieval.
Parallel GIN index usage: You can speed up full-text and JSON searches by utilizing multiple CPU cores.
Virtual generated columns: You can use columns that are computed on-the-fly, providing the same easy API as stored columns without using extra disk space.
Native UUIDv7 support: You can build distributed applications with UUIDv7, which offers better sortability and indexing efficiency than traditional random UUIDs.

Proven reliability: UKG modernizes the data foundation

Upgrading a production system at scale can be complex, but Google Cloud makes the process simple for PostgreSQL in AlloyDB, automating many of the pre- and post-upgrade tasks. UKG, a provider of HR and payroll solutions, recently upgraded its AlloyDB clusters to PostgreSQL 17 to power new features for their near-real-time data foundation, People Fabric. Managing a high-density, multi-tenant architecture with a massive number of database objects presented a significant challenge. By using in-place major version upgrades, UKG minimized risk and avoided impact to their users.

"Upgrading a multi-tenant environment with thousands of objects usually introduces significant risk, but AlloyDB’s in-place upgrade path allowed us to modernize our fleet without the typical downtime or performance regressions," said Rajiv Jain, Sr Director, Engineering, Data Platform, UKG. "This enabled us to hit our targets for our latest release of People Fabric and put the power of new PostgreSQL features to work for our customers."

In-place major version upgrades allow you to modernize your database without moving data or changing connection strings, reducing upgrade time to minutes. This streamlined path applies to all target versions, including PostgreSQL 18, so that even massive, multi-tenant fleets can adopt the latest features with minimal downtime. When paired with query plan management, this process provides a fast, predictable, and low-risk transition to the newest PostgreSQL releases.

Maximize performance with database-aware storage

AlloyDB builds upon the innovations of PG18, extending its capabilities with a specialized architecture. By separating compute from storage, we offload heavy database operations to a dedicated, intelligent layer. This has the following advantages:

Database-aware offloading: AlloyDB delegates logging and maintenance tasks to a dedicated service. This frees your primary database instance to focus entirely on processing transactions.
Horizontal scaling without data duplication: You can add read-only replicas in seconds. Because every replica attaches to the same distributed storage, you avoid the cost and lag of managing multiple copies of your data.
Better price-performance: Recent benchmarks show that AlloyDB provides up to 2x better price-performance than self-managed PostgreSQL. Even with half the compute resources of a self-managed environment, AlloyDB delivers higher transactions per minute by using its kernel more efficiently.
Pay only for what you use: AlloyDB storage is elastic. You don't need to specify a storage size; the system grows and shrinks automatically based on your data.
Predictable throughput: Many cloud databases require you to buy more storage just to get higher performance. AlloyDB does not limit speed based on storage size — you get full performance from day one, paying only for the data you store.

Get started

Create a PostgreSQL 18 instance: Visit the AlloyDB console.
Plan your upgrade: Review our major version upgrade documentation.
Check support dates: See the Extended Support docs and our updated version support policy.

New Bigtable in-memory tier for sub-millisecond read latency

Thu, 07 May 2026 16:00:00 +0000

In the high-stakes world of digital infrastructure, speed isn't just a metric — it’s currency. At Google Cloud Next ‘26 we announced the Bigtable in-memory tier, a breakthrough for our fully managed cloud database service that delivers:

Sub-millisecond read latency for time-sensitive data
~10x higher point read throughput per dollar, dramatically reducing TCO
Hotspot resistance, supporting up to 120,000 queries per second on a single row without breaking a sweat.

For more information see Bigtable performance documentation. Now, let's look at the impact Bigtable in-memory tier can have on your workload performance and operational processes.

The cache-miss nightmare: A familiar story

Imagine it’s 2:00 AM. Your promotional campaign just went viral, and traffic is spiking. Your database architecture, meanwhile, is a house of cards: a primary database struggling to keep up and a separate caching layer acting as a shield.

Suddenly, you're hit with a hot key problem: everyone is trying to access the same viral content. Your cache node saturates. You’re forced to upgrade to larger nodes or add read replicas. You and your team are exhausted. Not only are you managing two different systems, maintaining a complex cache-aside logic (and praying the data in the cache stays in sync with the database), but you also need to respond to the actual incident. To do so, you overprovision CPU to handle the peak, and add more RAM so that everything fits in memory, as well as to avoid cache-aside complexity. Now you’re paying premium prices for warm data that doesn't actually need to be in memory. And while your hypothetical throughput-per-dollar looks great on paper, 90% of your resources sit idle most of the time.

Enter Bigtable’s in-memory tier

The Bigtable in-memory tier ends this cycle. By bringing data tiering across RAM, SSD, and HDD into a single, unified service with a hybrid storage architecture, we've removed the middleman.

The result? You get the raw throughput and speed of a cache with the durability and scale that Bigtable was designed for. When that viral spike hits, Bigtable automatically moves hot rows into memory to handle the load. No CPU spikes, no performance degradation. If the traffic grows, so does your Bigtable cluster by giving you more in-memory read capacity. You no longer need to overpay for idle RAM or cache nodes; Bigtable intelligently manages your data, keeping only the hot data in memory and ensuring data consistency between in-memory tier and SSD storage.

The TCO benefits are tangible, but maybe the most important part is the peace of mind that comes with it — and that’s priceless.

A peek behind the curtain

Almost every database server uses memory to give CPU fast access to latency-sensitive, frequently accessed data such as indexes and Bloom filters. You might be wondering, what makes this announcement different?

The secret lies in Remote Direct Memory Access (RDMA), a high-performance networking technology that allows computers to transfer data directly from one machine's memory to another without involving either the system's operating system or CPU. Our architecture uses RDMA to provide a high-speed, direct path to server memory, and as a result, throughput and latency of in-memory tier isn’t bound by server CPU, translating to impressive benefits. Much like Data Boost enables direct disk access for heavy workloads such as ML training, RDMA provides high-speed, direct memory access for real-time processing.

Imagine you’re running a popular social media site where 98% of users have fewer than 250 followers, while your most popular users have over 100 million. 60% of users post less than once a week, and the top 10% of users generate 80% of the content. And while a typical post receives 500 impressions, popular ones receive tens of millions.

To efficiently address this use case you will want data tiering that will likely look like this:

Memory: Content from profiles of users with large followings
SSD: Recent content, active user profiles
HDD: Older content, inactive user profiles

Luckily this is very easy to accomplish in Bigtable. Simply enable in-memory for your cluster and use a memory-enabled application profile when issuing your database requests to automatically manage the hot data lifecycle. You can also set an age-based policy to tier cold data to infrequent access. With this setup, when a piece of content is read, it gets promoted to the memory tier from persistent storage and stays there until it is evicted to make room for more recently read items. It is hands-free; even if a post from 5 years ago makes a viral comeback all of a sudden, you don’t have to worry about it.

But let’s say you want more fine-grained control of what you cache. You have a list of popular content creators and want to limit memory usage to only that small subset of their posts. Simply route the traffic for those users via the memory-enabled app profile, and for the rest of the content use an app profile that isn’t memory-enabled.

The cache-miss nightmare, revisited

Let’s rewind and replay our cache-miss scenario, but with Bigtable’s in-memory tier enabled. It’s 2:00 AM Sunday morning. Your promotional campaign just went viral, and traffic is spiking, you need to serve an additional 80K reads per second for the next hour. You don’t get paged. You wake up at 11 AM to the sound of birds chirping and enjoy a peaceful breakfast. It’s a beautiful day. The only sign that traffic spiked between 2-3 AM is that your bill shows an extra $0.40 charge.

Power laws govern distribution of requests for applications in a wide range of industries so scenarios like this are not limited to social media. For example, stock exchanges trade several thousands of securities but the top 30 most active stocks typically represent more than 40% of the total daily trading volume. At the same time, the most recent data points (last trade, ask/bid price) are requested frequently with an expectation of low latency responses, while historical data is accessed much less frequently, and has a rather forgiving latency budget. Let’s break down this example into Bigtable data tiers:

Memory: Most recent price of securities for most sought out stocks
SSD: Recent history, aggregated metrics (hourly, daily, monthly etc.)
HDD: Older data, raw events like individual trades

The list of possible use cases for this capability is long. Automated trading systems access latest prices from memory, while retail investors build their candlestick charts from data on SSD, and quants access historical data on HDD using Data Boost to backtest their models. All in one database, without interfering with each other. You can replace financial time series with telemetry data, sensor networks, digital twins and the story wouldn’t be much different.

Nor does using Bigtable’s in-memory tier interfere with other enterprise features like high availability, scaling, auditing, governance, and access controls, which typically introduce significant overhead. Achieving sub-millisecond latency despite these enterprise requirements is extremely impressive. By optimizing our clients and network, we’ve also successfully reduced p50 SSD latencies to below 2 milliseconds.

Get started with Bigtable Enterprise Plus

The Bigtable in-memory tier is available exclusively as part of the new Bigtable Enterprise Plus edition, which offers many additional features and is designed for organizations that demand the highest levels of performance, and management efficiency.

Elevate your stack to Bigtable Enterprise Plus and in-memory capabilities today so you can stop managing infrastructure and start building the future!

Learn more

Learn more about Bigtable Enterprise Plus edition and its capabilities beyond the in-memory tier. Try it out by heading over to Google Cloud console and creating new clusters upgrading existing ones.
If you’re new to Bigtable, you can now experience Google’s pioneering NoSQL database with the new Bigtable Free Trial. Get a dedicated Enterprise Edition node, 500GB storage, and a guided tour of Bigtable.
For more detailed information on getting started, technical specifications, and regional availability, visit the official Bigtable product page.

Firestore at Next '26: Unlock agentic development, search and MongoDB compatibility

Mon, 04 May 2026 16:00:00 +0000

In the era of AI agents, the distance between a big idea and a working application has never been shorter. As we lean more heavily on agents to help us build applications, a critical question remains: can your database infrastructure keep up?

With its virtually limitless scalability and high availability, Firestore, Google Cloud’s fully managed document database, is a great fit for emerging agentic applications. And at Google Cloud Next ‘26, we leveled up Firestore for AI-driven apps even further, with:

Tighter agentic AI integrations: New native integrations with AI Studio and third-party coding agents mean your LLMs and database now speak the same language.
Full-text search and expressive queries: Differentiated search capabilities and pipeline operations mean agents and users are able to find exactly what they need within your data.
Enhanced MongoDB compatibility: Now it’s easier than ever to bring existing MongoDB workloads into the Firestore ecosystem.

In this blog, we’ll take a closer look at our announcements from Next ‘26. But first, here’s a Firestore refresher.

The case for Firestore

Whether you’re an enterprise leader looking to empower your workforce to build their own productivity tools, or a founder sketching out the next big thing on a napkin, you need to be able to prototype at the speed of thought, pivot the moment you get user feedback, and do it all without breaking the bank — or the database.

When it comes to selecting a database, you need to worry about:

Scaling: Can the database survive a viral traffic spike?
Budget efficiency: Does the solution scale to zero during inactivity to reduce your costs?
Iteration speed: Will frequent tweaks in your agent prompts be slowed by expensive database schema migrations to fulfill those requests?

We designed Firestore to address these exact concerns. Firestore has always been an easy way to achieve rapid, automatic, elastic database scaling, with its serverless architecture that also provides sub-second provisioning. Meanwhile, Firestore’s document model makes it easy and fast to iterate on your data structures — no breaking schema changes, no downtime, just flow.

At the same time, accelerating development velocity shouldn’t mean compromising on enterprise governance. Firestore offers an industry-leading 99.999% SLA and ACID-compliant transactions, all while benefiting from the rigorous security and privacy oversight, fundamentally inherent to Google Cloud.

Companies like FlutterFlow are already reaping the benefits.

“As an AI-native company dedicated to democratizing web and mobile development, Firestore has served as the foundational database powering FlutterFlow as we scaled from zero to over 3 million users across more than 150 countries. Over the past five years, we have experienced zero outages while serving more than 750 billion reads and 75 billion writes. We are true believers in Firestore.” - Abel Mengistu, CEO and Co-founder, FlutterFlow

With that background, here’s what’s new in Firestore from Next ‘26.

1. Accelerating application development through agentic AI integrations

We embedded Firestore directly into the AI creative process. Through new native integrations with AI Studio, developers can now build and provision fully functional full-stack applications with an integrated Firestore database and added authentication from a single natural language prompt. This integration is driving incredible momentum on Firestore, bringing the overall Firestore developer base to 750,000 monthly active developers and over 10M hosted databases.

With just one natural language prompt, developers can now leverage Gemini through AI Studio to create and set up full-stack apps equipped with Firestore as the database.

We also enhanced the ability to integrate Firestore with preferred third-party AI agents, including Claude Code, Cursor, and Codex. With the general availability of Firestore Skills and Firestore remote MCP service, connecting to popular external agents is even more straightforward.

To further enhance productivity, we introduced natural language querying in the Google Cloud console, in preview. This leverages Gemini Code Assist to convert simple natural language queries into complex, MongoDB-compatible queries.

Write queries in natural language using Gemini Code Assist.

2. Differentiated search and queries

Building sophisticated, data-rich AI agents requires a database with modern search and query capabilities. Our reimagined query engine on Enterprise edition, featuring pipeline operations, is now generally available, and delivers hundreds of new query capabilities, positioning Firestore as a premier service for expressive applications.

A major addition is built-in full-text search, now available in preview. Firestore full-text search leverages Google search technology, ensuring users who perform a search receive precise results using high-quality relevance models that support more than 40 languages. Moreover, alternative hybrid database and search setups can produce search results that aren’t reflective of actual database data, because their search indexes only use eventual consistency. In contrast, Firestore search indexes are strongly consistent with transactional data, for more accurate search results. Crucially, this native functionality inherits Firestore’s serverless architecture, drastically reducing the operational friction of managing separate search infrastructure.

Integrate full-text search capabilities into your applications with the new search() stage, leveraging your existing Firestore document data.

We also introduced geospatial queries capabilities in preview, enabling developers to build location-aware applications that can easily find nearby points of interest.

code_block: <ListValue: [StructValue([('code', "// Find nearby restaurants\r\nfirestore.pipeline().collection('restaurants')\r\n .search({\r\n query: field('location')\r\n .geoDistance(new GeoPoint(38.989177, -107.065076))\r\n .lessThan(1000 /* m */)\r\n });"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d922f70>)])]>

This release also includes the highly requested JOIN functionality, in general availability. Implemented via subqueries, pipeline operations enable lookups across diverse collections. Additionally, we launched a preview of built-in data manipulation operators to facilitate the bulk normalization, sanitization, and backfilling of documents within your collections.

code_block: <ListValue: [StructValue([('code', '// Retrieve all reviews less than 2 stars for a given restaurant\r\nconst pipeline = db.pipeline()\r\n .collection("restaurants")\r\n .define(field("__name__").as("restaurant_id"))\r\n .select("__name__", db.pipeline().collection("reviews")\r\n .where(field("parent_restaurant_id").equals(variable("restaurant_id"))\r\n .where(field("rating").lessThan(2))\r\n .select("review", "rating"))\r\n .toArrayExpression()\r\n .as("negative_reviews"));'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d922a90>)])]>

We're also provided deeper observability insights through enhanced usage monitoring, including usage by collection through a new Usage Insights feature in preview.

Debug Firestore usage with a breakdown by collection using Usage Insights.

Finally, Firestore will soon be integrated with Knowledge Catalog, providing you with deeper insights into how your data models evolve at the collection level.

3. Enhanced MongoDB compatibility and scalability

We continue to broaden Firestore’s appeal for enterprise workloads with enhanced MongoDB compatibility, making it easier for you to migrate and build on Firestore.

To boost MongoDB compatibility, Firestore now supports larger documents up to 16MiB, removing traditional barriers for complex data migrations and high-volume workloads.

To enable real-time data movement, we launched highly scalable change streams to synchronize changes from Firestore to services like BigQuery at scale. This feature is built to handle virtually any volume of read and write operations, giving you the piece of mind that change streams will seamlessly scale alongside database production traffic.

Easily create a new MongoDB compatible change stream to listen to data changes in a collection or database in real-time.

We also improved data lifecycle management, giving developers the ability to efficiently manage data deletion by dropping a collection and using more flexible time-to-live (TTL) time offsets for automatic data expiration — all while ensuring these administrative operations never impact the database's production traffic.

code_block: <ListValue: [StructValue([('code', 'db.receipts.drop();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d91ffd0>)])]>

Get started on Firestore

These new capabilities are now available with the Firestore Enterprise edition, available in both Native and MongoDB compatibility modes. Developers can begin incorporating these advanced capabilities into your intelligent, agentic applications today.

UKG unlocks real-time workforce intelligence at scale with the Agentic Data Cloud

Wed, 29 Apr 2026 16:00:00 +0000

At UKG, we’ve spent years building and expanding our human capital management (HCM) and workforce management (WFM) solutions with new products, capabilities, and a series of acquisitions. Our cloud platform includes a suite of connected systems that support every corner of the employee experience, including scheduling and workforce operations, HR and payroll, and culture and engagement tools.

These connected tools offer customers incredible depth, but it also means our backend reflects years of evolution. We have 126 application teams, dozens of tech stacks, and more than 12,000 database instances inherited through acquisitions and product growth. And each product carries its own schema and operational footprint.

Previously, data moved through bespoke pipelines not built for real-time use. As AI advanced, expectations did too. Customers wanted instant insights across HR, time, pay, culture, and operations, and those insights increasingly needed to drive automated workflows and intelligent applications.

Internally, teams needed consistent, high-performance access to shared data to innovate faster and modernize our architecture. We needed a unified foundation for the next generation of intelligence across our suite. That’s why we built People Fabric, our new data and intelligence platform powered by AlloyDB for PostgreSQL and the just-announced Agentic Data Cloud.

Unifying the systems behind the suite

People Fabric started with a simple need: bring the full UKG suite onto one real-time foundation. Getting there started with defining a single canonical data model for the entire suite. This would serve as the shared language for people, work, pay, and culture data — consistent no matter where the information originated.

We needed an operational database that could ingest changes quickly and scale horizontally. That’s why we chose AlloyDB as the core of People Fabric. It gives us millisecond-level read-after-write behavior, high-throughput ingestion, scalable read pools, and native vector capabilities to support AI.

With the model defined and the operational store selected, the next step was building the pipeline that feeds the platform. We created a custom change data capture (CDC) framework to extract changes from our existing operational databases inherited over the years. Those changes flow through Dataflow, where they’re transformed into the canonical structure that AlloyDB for PostgreSQL expects.

Once in AlloyDB, that data becomes the real-time backbone of the platform. Applications use it for near-instant queries. AI agents rely on it for cross-domain decisions, and vector search engines use it to power natural-language and similarity-based experience layers.

For larger analytical workloads, the same data flows into BigQuery, which gives our teams and our customers the ability to perform organization-wide reporting and analysis without straining the system. Cloud SQL holds the metadata and tenancy context that govern who can see what and how different parts of the suite interact with People Fabric. From there, the system runs continuously. Data enters through streaming ingestion and gets modeled once in AlloyDB for PostgreSQL to make it available everywhere.

aside_block: <ListValue: [StructValue([('title', 'Build smarter with Google Cloud databases!'), ('body', <wagtail.rich_text.RichText object at 0x7f0524106d60>), ('btn_text', ''), ('href', ''), ('image', None)])]>

Bringing people intelligence to intelligent people

With the architecture in place, People Fabric gives us something we never had before: a complete and consistent view of people, work, pay, and culture data that’s updated continuously and ready for AI to use in real time.

That unified context is what powers our assistive experiences, including conversational reporting and natural-language interactions. Leaders can ask questions in plain English and get answers that reflect the full picture — not just a single system’s slice of it.

With the power of Google’s Agentic Data Cloud, our platform unifies analytical and transactional data to power real-time AI. This allows agents to reason over live workforce signals and trigger immediate actions. Because this data is governed and modeled from the start, our agents can reliably handle multi-step workflows across HR, payroll, and timekeeping.

Whether they're identifying pay discrepancies, adjusting schedules, or flagging compliance risks, they operate with the same shared semantics and security model that guides our applications. It’s the difference between AI that reacts and AI that can truly assist.

Driving impact across every layer

For engineering teams, People Fabric acts as a database-as-a-service that removes the need for each microservice to manage its own datastore or pipelines. This accelerates development and supports modernization without customer disruption.

AlloyDB for PostgreSQL delivers millisecond read-after-write behavior, zero replication lag, and near-real time ingestion latency, enabling real-time workloads with far less complexity. Migrating core person and employment data off our on-prem monolith has generated cost savings significant enough to fund half of People Fabric.

Real-time operational data now gives managers a live view of staffing, pay, and workforce activity. More than 1,000 organizations are already on the platform, with another 1,000 in progress.

As we continue expanding People Fabric, we’re laying the groundwork for deeper agentic automation, more responsive analytics, and a growing set of AI-driven capabilities — all on a trusted, scalable foundation built for what’s next.

Learn more

UKG’s success illustrates how leveraging AlloyDB for PostgreSQL and the Agentic Data Cloud allows organizations to unify operational and analytical data, creating the essential foundation for real-time, agentic AI.

Learn more about AlloyDB for PostgreSQL and get started with a free trial today!
Sign up for a strategy workshop today on how to get your data ready for the agentic era!

What’s new with Databases: Powering the agentic future

Wed, 22 Apr 2026 12:00:00 +0000

In the agentic era, the role of enterprise data is shifting from a passive resource to a dynamic System of Action. That’s why we announced the Agentic Data Cloud — a unified architecture that integrates models, analytics, and operational databases into a single, AI-native system. This allows organizations to unlock the full potential of their data, ensuring every AI application and agent is grounded in truth and is capable of taking real-time action without costs spiraling.

Today, we’re moving the needle by:

Embedding AI across the entire data stack for an unmatched, optimized developer experience.
Unifying transactional and analytical worlds, to eliminate the friction of manual integration.
Simplifying enterprise-grade deployments with industry-leading, open databases that are easier to manage and faster to deploy.

Embed AI into every layer of the data stack

We continue to enable smooth connections between AI agents and enterprise databases, making your database experience effortless and agent-driven. From vibe coding tools for citizen developers, to high-scale vector search for the enterprise, we know that databases are one of the primary components of agentic workflows.

Key launches include:

Vibe coding integrations for databases with AI Studio: To enable creators, we are launching an integration with our leading vibe coding platform Google AI Studio. This agent-led, automated workflow allows you to create a live application from a simple text prompt in seconds, that connects the application to trusted database services like Firestore, with support for Cloud SQL for PostgreSQL coming soon.
Tools for Data Agents (Preview): These are the modular building blocks developers use to give their custom AI agents direct, secure access to database capabilities. Available for AlloyDB, Cloud SQL, and Spanner, these tools provide ready-to-use functions — like the QueryData tool for high-accuracy text-to-SQL— that allow any agent to query, understand, and interact with your data reliably. These tools for Data Agents in AlloyDB, Spanner, and Cloud SQL provide near-100% text-to-SQL accuracy.
Database onboarding and observability agents (Preview): The new Database Onboarding agent takes the guesswork out of database selection and deployment. By evaluating your stated requirements — from simple use case descriptions, to complex enterprise needs — it recommends the ideal Google Cloud database and guides you through provisioning. Additionally, the new AI-powered Database Observability Agent proactively monitors performance and health across AlloyDB, Bigtable, Cloud SQL, and Spanner. It identifies root causes of potential issues and delivers accurate remediations for troubleshooting.
AlloyDB AI-powered search at scale (Preview): We are introducing unprecedented scale and performance for enterprise search. AlloyDB can now scale to 10 billion vectors using Google’s ScaNN index, and offers up to 6 times faster vector queries than the HNSW index in standard PostgreSQL. Additionally, our HNSW index, accelerated by the Columnar Engine, now outperforms standard PostgreSQL by 4 times. We're empowering developers to build the ultimate hybrid search engine by pairing high-speed vector retrieval with industry-standard full-text search, optimized by native BM25 support coming soon.

AlloyDB vector search innovations

New and optimized AI functions for AlloyDB (Preview): AlloyDB AI functions allow you to integrate enterprise data with the power of LLMs like Gemini. For example, the ai.if function can replace custom logic to determine if user transactions are fraudulent. Joining our existing suite, ai.if, ai.rank, ai.generate, and ai.forecast, are two new additions: ai.analyze_sentiment and ai.summarize. We also now have an optimized mode for ai.if, which delivers superior cost and performance boosts.
Managed, remote MCP servers for databases (GA): We’re announcing managed, remote Model Context Protocol (MCP) servers for AlloyDB, Bigtable, Cloud SQL, Firestore, and Spanner, alongside a preview for Memorystore, Database Migration Service, Datastream, Database Center, and Oracle AI Database@Google Cloud to achieve MCP coverage across our portfolio. By fully managing the infrastructure required to connect AI models securely to your data, we are eliminating the operational burden of hosting, securing, and scaling MCP servers yourself. This ensures your AI models can reason and act upon your most up-to-date enterprise data with production-grade reliability.
Open-source MCP Toolbox for Databases (1.0): Supporting over 40 databases with contributions from 10 vendors, the open source, industry-standard MCP Toolbox for Databases has achieved a major stability milestone with this release. By guaranteeing the API will not break without a major version bump, we are giving you the confidence to build production applications, delivering a highly reliable foundation for both developers and autonomous AI agents.

Break down walled gardens with lakehouse integrations

To build real-time AI applications, developers need to combine live transactional context with massive historical insights at sub-millisecond latencies. Today, 98% of our largest data cloud customers are running their operational and analytical workloads on Google’s Agentic Data Cloud.

We’re announcing:

Lakehouse federation for AlloyDB (Preview): AlloyDB customers can now access live data from Iceberg and BigQuery from the PostgreSQL data plane. Users can discover and search for any BigQuery or Lakehouse for Apache Iceberg table directly from the AlloyDB Studio UI and begin querying immediately, with pushdown to BigQuery for filters and aggregations. This allows live joins between AlloyDB's transactional data and historical insights in BigQuery or Iceberg without any data movement.
Reverse ETL for BigQuery (Preview): Many customers use BigQuery and Lakehouse to combine structured warehouse data with rich context from the data lake using tools like Apache Spark or BigQuery ML. Now, with our new one-click Reverse ETL, customers can activate these insights and sync data from the lakehouse to AlloyDB with a single click. AlloyDB acts as a high-concurrency, low-latency serving layer, optimized to meet the needs of real-time and agentic applications. Excellent serving performance is powered by AlloyDB’s unique columnar engine and ultra-fast cache, available at no additional cost.
Seamless ongoing replication with Datastream (GA): To close the data loop, Datastream now allows users to replicate data continuously to BigQuery and, importantly, to Iceberg tables directly from AlloyDB. This ensures operational changes are quickly reflected in the analytical environment, crucial for real-time ML feature engineering. Datastream is simple to set up, fully serverless, and offers a free tier for AlloyDB to BigQuery streams.
Knowledge Catalog, formerly Dataplex (Preview): The Knowledge Catalog is a universal context engine which maps and infers business meaning across your entire data estate, using a rigorous framework of aggregation, continuous enrichment, and search. It works by aggregating native context across your Google and partner data platforms, semantic models, and third-party catalogs, unifying them into a single, governed source of truth. Governance is consistently applied, access controls are managed centrally, and full visibility and security are maintained across the entire data lifecycle.
Spanner Columnar Engine (GA): This capability accelerates analytical queries by speeding up scans up to 200 times on live operational data. By storing data in a columnar format alongside traditional row-based storage, Spanner can execute complex queries automatically using vectorized execution — processing batches of data at once rather than row-by-row. Spanner also now supports Iceberg tables, continuous reverse ETL from BigQuery, and accelerated federated queries — all using the Spanner columnar engine.
Database Center with BigQuery (Preview): Database Center now supports BigQuery alongside operational databases and self-managed databases on Google Compute Engine. You can now monitor your entire data estate — from the databases running your critical applications to the warehouses analyzing your business — from a single, intelligent management plane. Additionally, Gemini-powered fleet analytics now proactively surfaces performance optimization opportunities across your environment. And with our new API and managed MCP support, you gain the freedom to stream these rich fleet metrics directly into your preferred third-party tools and custom dashboards.

“Our partnership with Google Cloud is focused on building a smarter, faster exchange. Google’s Agentic Data Cloud allows us to dismantle the legacy silos and technical debt that once slowed us down. By integrating the operational reliability of Cloud SQL with the deep reasoning of BigQuery, we’ve created a data ecosystem where our developers and AI agents can validate, optimize, and innovate in real time.”
—Kristofer Shane Sikora, Executive Director, Cloud Data Engineering, CME Group

Commitment to open data and multi-cloud flexibility

We recognize how critical databases are for the day-to-day operations of all your applications. We continue to innovate on industry-leading reliability, price/performance, and scale, while maintaining a focus on open source and open data formats like Iceberg, MySQL, PostgreSQL, and Valkey.

To simplify enterprise-grade deployments, we’re announcing:

Spanner Omni (Preview): A new downloadable edition of Spanner that extends the industry’s leading distributed database beyond Google Cloud. Spanner Omni empowers organizations to use Spanner’s unparalleled scalability, high availability, strong consistency, enterprise-grade security and fully interoperable, multi-model capabilities for AI-enabled applications in their own data centers, across clouds or even at the edge.

What makes Spanner Omni unique

Bigtable in-memory (Preview): Bigtable is evolving its architecture and now delivers sub-millisecond read latency with the new memory tier. Available as part of Bigtable’s new Enterprise Plus edition, the new nodes with hybrid storage architecture spanning RAM, SSD and HDD, integrate frequently accessed data in-memory with long-term archival storage — all within a single, fully-managed service. Complete this form to express interest.
Memorystore for Valkey 9.0 (GA): Demonstrating our strong commitment to open source, this milestone anchors our focus on simplifying adoption and delivering enterprise-grade performance. We are introducing a managed migration path from self-managed Redis and Valkey to Memorystore, making it easier than ever to modernize. We’re also adding new smaller and larger node sizes for better price-performance, support for the Valkey-bloom and Valkey-json modules, and enterprise-grade security featuring Access Control Lists (ACLs), token-based authentication, and Flexible Certificate Authorities.
Oracle AI Database@Google Cloud: We are expanding to 20 regions, and are adding Oracle GoldenGate Service support, near real-time data replication to BigQuery, and integration with Knowledge Catalog (formerly Dataplex) and Database Center.
Move-to-managed migrations (Preview): This new experience augments Database Migration Service by embedding discovery and management directly into Cloud SQL, AlloyDB, and Database Center. For PostgreSQL, it introduces powerful new capabilities like parallel consolidation of multiple sources into a single, live destination and support for migrating tables without primary keys. These enhancements allow you to move your database workloads to managed services with minimal effort and downtime.
Firestore full-text and geospatial search (Preview): Google’s industry-leading search technology is now natively integrated into Firestore, creating a differentiated, unified serverless database and search offering. This offering allows developers to execute high-relevance keyword, phrase, and geospatial queries, while ensuring that search results remain consistent with the underlying database data to significantly reduce operational overhead.

Mercado Libre: “Mercado Libre built Fury, our in-house developer gateway. Through Fury, we offer a NewSQL service powered by Spanner, leveraging its unmatched scalability, resilience, and consistency. While we are a cloud-native company, we have long remained vigilant regarding risks like insider threats, ransomware, and cloud outages. Spanner Omni enables true cross-cloud resilience, providing a robust and differentiated strategy that would be significantly more complex to implement with other cloud providers."
– Diego Oscar Narducci, Sr Technical Manager, Mercado Libre

Get started today

To learn more about our full portfolio please visit https://cloud.google.com/products/databases. To get started with migration and modernization initiatives, get started with our RAMP offer.

Announcing Spanner Omni: Your infrastructure, Google’s innovation

Wed, 22 Apr 2026 12:00:00 +0000

Today, we announced the preview of Spanner Omni, a downloadable version of Spanner, that expands its industry-leading distributed database capabilities beyond Google Cloud. This enables enterprises to run Spanner in their own data centers, across clouds, or on a laptop — bringing its virtually unlimited scalability, high availability, strong consistency, enterprise-grade security, and multi-model capabilities to AI-enabled applications wherever they operate.

Why Spanner Omni is a big deal

Over a decade ago, Google pioneered the distributed SQL market with Spanner. It offered the "holy grail" combination: the horizontal scalability of NoSQL with the ACID (atomicity, consistency, isolation, durability) compliance and strong consistency of a traditional relational database. Since then, Spanner has evolved into an interoperable multimodal database, incorporating SQL, graph, key-value, full-text search, vector search, and analytical processing with columnar engine. This evolution offers the capabilities needed for the AI era and promises an opportunity to simplify and consolidate customers’ workloads — an advancement that has delivered significant value to our customers.

Customers often navigate across a range of IT environments, from public cloud and hybrid cloud to air-gapped deployments. Spanner Omni meets them where they operate to address the evolving needs of modern enterprises, including:

Business continuity: Mission-critical workloads often need truly resilient, high-availability architectures that extend beyond the edge of the cloud. These workloads need to keep running even when business conditions or world events compel changes in their cloud posture.
Regulatory compliance: Customers in highly-regulated industries, like financial services, must meet regulatory requirements like data sovereignty. While many still maintain large on-premises footprints to stay compliant, they’re eager to modernize for the agentic era.
Application portability: For SaaS providers and other independent software vendors (ISVs), growth depends on meeting customers wherever they are — whether in different clouds or a private data center. They want a consistent technology stack across those environments to minimize development and operational overhead without having to compromise on advanced features for innovation.

Introducing Spanner Omni

Spanner Omni delivers the same core capabilities as our fully-managed Spanner service, with the added freedom to deploy it wherever needed. It provides flexible configuration options ranging from virtual machines (VMs) and Linux containers to Kubernetes clusters. Customers can also run Spanner Omni in a wide range of configurations — on-premises, multicloud, multi-region and hybrid (within reasonable latency topologies), air-gapped, or connected — scaling from a single machine to clusters of thousands of servers. Our internal benchmark tests confirm that Spanner Omni processes millions of queries per second (QPS) across petabytes of data in a single regional deployment.

What makes Spanner Omni unique

Spanner Omni opens the door to new possibilities. Through our work with early adopters, we have observed three popular architectures for deploying Spanner Omni:

Hybrid and multicloud resilience: Customers are running their Spanner managed service in Google Cloud as their primary database while deploying Spanner Omni in a secondary cloud or on-premises data center as a hot-cold failover site. This primary-secondary architecture provides a critical safety net and helps organizations meet disaster recovery and business continuity requirements, especially in regulated industries. Our customers can also deploy multi-regional HA in jurisdictions where Google Cloud only has one data center, but data sovereignty is a requirement.
Unified tech stack across environments: For organizations with a multicloud or hybrid strategy, Spanner Omni provides a "write once, run anywhere" application building experience across environments. By standardizing on a single database layer, teams can drastically reduce their operational overhead and achieve true application portability across any environment, while tapping into cutting-edge database technologies.
On-premises modernization: Organizations with substantial on-premises commitment or preference to self-manage are no longer locked out of cloud-native innovation. With Spanner Omni, they can build or rewrite next-generation AI applications with Spanner’s multi-model capabilities on existing hardware infrastructure using Spanner’s innovative technology to achieve scale insurance, high availability, global consistency, and much more.

The tech behind Spanner Omni

Our vision is simple: If you have compute and a database-grade local file system, you should be able to run Spanner Omni. To make this a reality, we have made a series of innovations to remove Spanner’s dependency on Google. We took the core technologies of Spanner, such as the Paxos consensus, automatic sharding, synchronous replication, and replaced Google-dependent components like Colossus and TrueTime with new creative and innovative solutions.

For distributed storage everywhere, Spanner Omni replaces Spanner’s reliance on Colossus, Google’s distributed file system, by introducing a "Colossus-like" abstraction layer. This layer writes to attached local file systems and makes them available across the network to other nodes. The software automatically handles shard splitting and rebalancing to balance storage across all available servers to ensure peak performance. While Spanner Omni’s file layer isn’t Colossus, it’s a sufficient stand-in to allow Spanner Omni to perform comparably to the Spanner managed service for most workloads.

We also reimagined TrueTime, one of Spanner’s most well known technologies, which uses atomic clocks and GPS to synchronize time globally. For Spanner Omni, we developed a software-based TrueTime alternative, which — like TrueTime in Google Cloud — provides highly reliable, error-bounded time synchronization across servers in a Spanner Omni deployment. While Spanner depends on time synchronization to achieve strong external consistency, its ability to overlap time uncertainty waits with other database work allows Spanner to tolerate weaker uncertainty bounds than TrueTime provides in practice. TrueTime uses this flexibility to provide timekeeping across diverse and heterogeneous environments without limiting Spanner’s availability or performance.

aside_block: <ListValue: [StructValue([('title', 'What customers are saying'), ('body', <wagtail.rich_text.RichText object at 0x7f051d99ea00>), ('btn_text', ''), ('href', ''), ('image', None)])]>

Where you can get access

Spanner Omni’s developer edition is available today in preview (download). This edition includes Spanner’s core capabilities — suited for developing and testing in non-commercial, non-production environments. While it excludes enterprise security features, it’s the ideal sandbox for your next project. For early access to the commercial edition with full features, please reach out to us at https://cloud.google.com/consulting/spanner-omni

Converging operational and analytical data for AI transformation

Wed, 22 Apr 2026 12:00:00 +0000

To act at the speed of business, AI agents must operate in fast and trusted reasoning loops. They need to “think” by reasoning across both your historical context and your live operational reality. Only by understanding this complete, real-time picture can they “do” — taking immediate action.

For decades, data architectures have been built with a structural wall that breaks this loop, separating the platforms that generate insights from the platforms that manage actions. This latency means insights are gleaned after the critical window for an agent to take action has closed. Achieving true AI transformation requires organizations to move from a passive system of record to a proactive System of Action, built on a closed-loop architecture that converges operational and analytical data.

At Google Cloud Next, we announced new unifying capabilities that drive our Agentic Data Cloud, eliminating silos and enabling 98% of our largest data cloud customers to run operational and analytical workloads in a unified data platform. By operating AlloyDB, BigQuery and Spanner together, we are delivering an AI-native architecture that unlocks the full potential of your data for real-time, agentic applications.

Flexible, real-time data agents

To act effectively, agents require both operational and historical signals for sound decision-making. Our Agentic Data Cloud bridges the gap between the operational "now" and analytical history by handling the complex plumbing for you. We provide diverse integration models across data federation, reverse ETL, and real-time ingestion to the lakehouse, empowering your agents to make high-stakes decisions with both live context and historical depth.

For example, sometimes an agent driving a live operational application needs to pull historical context on demand. Through Lakehouse federation for AlloyDB (Preview), agents can access Lakehouse data directly from AlloyDB itself. This allows frontline systems to instantly query extensive historical data without relying on brittle data movement pipelines.

In other scenarios, the challenge is reversed: deeply complex historical insights have already been calculated in the data warehouse, but an agent needs to deliver them to millions of users at conversational speeds. Reverse ETL for BigQuery (Preview) provides a one-click solution to push these heavy analytical insights back into AlloyDB, Bigtable, or Spanner, enabling agents to serve them with sub-millisecond latency.

One-click reverse ETL

Teams running real-time analytics on live operational data typically have to move that data into analytical systems — an error-prone process that introduces lag. With Spanner Columnar Engine (GA) users can perform analytical queries that run up to 200 times faster with zero impact on production transactional workloads.

Finally, the reasoning loop is not complete until an agent’s real-time action is captured for downstream analysis. To close this loop, Datastream for Lakehouse Apache Iceberg tables provides real-time Change Data Capture (CDC) from AlloyDB, Cloud SQL, Spanner, and Oracle directly into the open Lakehouse. This process streams every operational change as an append-only event into Lakehouse tables, making that data immediately available in BigQuery for ML model training, feature engineering, and real-time analytics.

"AlloyDB, along with other Google Cloud products like BigQuery, provides the agility and performance needed to continually enhance our platform's capabilities and help us anticipate emerging trends rather than merely reacting.” - Javi Fernández, CTO, Loyal Guru

Grounding agents in a unified governance foundation

Inconsistent definitions and unclear data ownership across operational and analytical systems can cause agents to hallucinate. To address this, we are extending Knowledge Catalog (Preview), formerly Dataplex, with new integrations for AlloyDB, BigQuery, Bigtable, Cloud SQL, and Spanner to provide a unified map of your data landscape. Integrations with Oracle AI Database@Google Cloud and Firestore are coming soon. The Knowledge Catalog works by aggregating native context across your Google and partner data platforms, semantic models, and third-party catalogs, unifying them into a single, governed source of truth needed to build and scale reliable agents.

"Seven-Eleven Japan created “Seven Central,” a scalable data platform that uses Spanner and BigQuery to provide real-time insights and support the company’s digital innovation strategies. We collect data from all 21,000+ stores, and in anticipation of a future expansion in business operations, we have designed a system that can scale up and run without issue, even if we were to have 30,000 stores, with 1,000 customers per store per day."
-Izuru Nishimura, Executive Officer and Head of ICT Department, Seven-Eleven Japan

Unified engines for deep reasoning

To move beyond simple Q&A chatbots to autonomous agents, AI must reason across every dimension of your data estate. Historically, combining keyword search, semantic understanding, and relationship mapping meant moving data out of operational databases and into specialized, siloed search engines — introducing latency and complexity.

Google’s Agentic Data Cloud eliminates these silos. By embedding native vector and full-text search directly into operational databases like AlloyDB, Bigtable, Cloud SQL, Firestore, and Spanner, agents can execute highly accurate hybrid searches combining keyword relevance and semantic intent.

We’re also bringing together graph and vector support across BigQuery and Spanner. With graph federation, an agent can match live user intent in Spanner and immediately trace that intent through historical graph relationships in BigQuery Graph — accelerating autonomous decision-making without moving the data. This multi-model approach powers advanced GraphRAG patterns, equipping agents with the rich, interconnected context required to accelerate autonomous decision-making.

“To deliver AI that actually works across HR, payroll, and workforce operations, you need a consistent, real-time data layer. With the power of Google’s Agentic Data Cloud, People Fabric is the backbone of UKG’s Workforce Operating Platform — turning fragmented systems into a single source of truth that powers intelligent, agent-driven experiences.”
-Radhi Chagarlamudi, Group Vice President, Product Engineering, UKG

Built for performance at agent scale

Our Agentic Data Cloud delivers the closed-loop architecture required for the AI era without compromising operational performance. Built on open standards like Iceberg and PostgreSQL, and governed by universal semantics, Google Cloud provides the speed, throughput, and trusted context needed to build the next generation of conversational and autonomous applications.

Build: Explore the AlloyDB AI documentation to start grounding your agents.
Connect: Visit the BigQuery Console to set up your first federated query to Spanner.
Govern: Opt-in to the Knowledge Catalog for unified visibility.

What’s new in the Agentic Data Cloud: Powering the System of Action

Wed, 22 Apr 2026 12:00:00 +0000

Companies are shifting from gen AI that simply answers questions to autonomous agents that perceive, reason, and act on their behalf. Attempting to scale these agents on legacy stacks exposes structural failures that can lead to fractured governance, a persistent trust gap, and broken reasoning loops, all while causing costs to spiral.

To solve this, we’re introducing the Agentic Data Cloud: an AI-native architecture that evolves the enterprise data platform from a static repository into a dynamic reasoning engine. It closes the gap between thinking and doing, allowing AI agents to act on your business data and context. While last-generation systems of intelligence were built only for human scale, the Agentic Data Cloud is a System of Action, built for agent scale.

Leading organizations are already using the Agentic Data Cloud to deliver tangible value:

Vodafone has launched hundreds of agents to deliver uninterrupted service to their customers, which is expected to save them millions of euros every year.
American Express is moving a core on-premises data warehouse and hundreds of production applications to BigQuery to power trusted agentic commerce at scale.
Virgin Voyages is using over 1,000 specialized AI agents, including one that slashes mass itinerary rebooking from six hours to just 11 minutes.

Today, we’re announcing three new innovation areas powering our Agentic Data Cloud:

A universal context engine that provides agents with trusted business context to drive higher accuracy.
Agentic-first practitioner experiences to evolve the role of data practitioners and developers as orchestrators of agents.
An AI-native, cross-cloud lakehouse that eliminates data silos by connecting your entire data estate.

Enabling agents with a universal context engine

AI is only as smart as its context. If an agent doesn't understand your definition of "margin" or the intricate relationships in your supply chain, it’s forced to guess. In the age of the agentic enterprise, data alone is not enough, and the old model of governance is insufficient. This is why we evolved the Dataplex Universal Catalog into the Knowledge Catalog, which maps and infers business meaning across your entire data estate, using a rigorous framework of aggregation, continuous enrichment, and search.

Here’s how it works:

Aggregation: To build true context, you must bring it together from everywhere. We are aggregating native context across your Google Cloud and partner data platforms. This includes third-party catalogs, applications, operating systems, and AI platforms like Palantir, Salesforce Data360, SAP, ServiceNow, and Workday (Preview). By using our Lakehouse, your third-party data assets are automatically mapped to the Knowledge Catalog. For Google Cloud sources, we are automating business logic with the new LookML Agent (Preview) and BigQuery measures (Preview), which embeds that business logic natively into the platform.
Continuous enrichment: The Knowledge Catalog delivers continuous enrichment by analyzing usage logs across your organization and profiling data behind the scenes. It learns how your enterprise actually uses data, not just what it is. This extends to unstructured data. The moment a file lands in Google Cloud Storage, our Smart Storage (Preview) instantly tags and enriches images and, soon, PDF objects. The Knowledge Catalog also identifies useful collections of unstructured data and uses Gemini to automatically generate missing schemas, mapping complex relationships so your AI is no longer flying blind.
Search and retrieval: Creating a massive context layer is great, but in the agentic era, search has evolved to be the new query path. The hardest problems at enterprise scale are speed, relevance, global reach, and security. To solve this, the Knowledge Catalog uses a sophisticated hybrid search stack built on Google Search innovation. To deliver relevance, it combines semantic and lexical matching with intelligent, machine-learning-based re-ranking. To deliver trust, we are enforcing your security permissions natively with access-control-aware search, so agents can only retrieve and act on the assets they are authorized to see. This high-precision infrastructure instantly identifies trusted context and feeds it to specialized agents.

The Knowledge Catalog now powers the Deep Research Agent (Preview). Part of the suite of Google-made agents available in Gemini Enterprise, this agent can perform multi-step reasoning across Google Cloud data platforms, such as BigQuery, as well as internal documents and web assets to answer complex questions with citations and precision that previously required weeks of manual effort.

Agentic-first practitioner experiences

As we move to this new architecture, the data practitioner role shifts from writing manual pipelines to orchestrating intent-driven engineering.

We’re accelerating this transition with the Google Cloud Data Agent Kit (Preview). Rather than introducing a new interface, we are launching a portable suite of skills, tools, environment-specific extensions, and built-in plugins, that drop into the environments developers love. By meeting practitioners where they already build — including VS Code, Gemini CLI, Codex, and Claude Code — we turn your IDE, notebook, or agentic terminal into a native data environment. This enables your environment to autonomously orchestrate a wide range of business outcomes, automatically selecting the right frameworks (e.g., dbt, Apache Spark, or Apache Airflow) and generating production-ready code based on Google’s gold standards.

This kit doesn't just connect tools — it injects high-performance capabilities directly into the developer's flow, scaling to petabytes without moving data. In fact, the Data Agent Kit features the same skills and tools that power our own out-of-the-box agents, including:

Data Engineering Agent (GA): Builds complex pipeline transformations from scratch and enforces governance rules to keep bad data out of production.
Data Science Agent (GA): Automates the model lifecycle — from wrangling to training — scaling across BigQuery Dataframes and Serverless Apache Spark.
Database Observability Agent (Preview): Acts as a 24/7 guardian for your infrastructure, diagnosing root causes and executing database remediations.

To help ensure the smooth execution of agents, Google Cloud has fully embraced Model Context Protocol (MCP), which provides a secure, universal interface that allows any agent to discover and use your data assets across our core engines, including: BigQuery, Spanner (Preview), AlloyDB, Cloud SQL (GA), and Looker MCP (Preview). MCP for Google Cloud uses our security stack, governing agent interactions based on your existing IAM policies, VPC Service Controls, and data residency requirements.

We’re also reimagining the business user experience with Conversational Analytics, now supported across BigQuery (GA), Cloud SQL, Spanner, AlloyDB (Preview), and Looker (GA). Organizations can simply publish these custom analytical agents in Gemini Enterprise, enabling employees to chat with live data in a familiar interface. By removing the technical barriers, we’ve eliminated the weeks spent waiting for manual reports, allowing businesses to move at the speed of thought.

A cross-cloud foundation built for agentic scale

For an agent to act, it must have a fundamentally open foundation. If an agent is blocked by cross-cloud latency or trapped in a proprietary walled garden, its autonomy is broken. That’s why we are introducing a truly borderless, cross-cloud Lakehouse that liberates your data wherever it resides by:

Connecting analytical estates: We’re integrating Cross-Cloud Interconnect (CCI) directly into our data plane. By combining CCI’s dedicated, high-speed private networking with Apache Iceberg REST Catalog, we’re enabling connectivity across clouds that is low latency and eliminates massive egress fees. As a result, agents can use data across AWS and Azure as if it were local to Google Cloud with seamless cross-cloud access.
Ending proprietary silos: We’re championing open federation to end the era of proprietary catalogs by launching bi-directional federation (Preview). Powered by the Iceberg REST Catalog, engines can now read directly from Databricks Unity Catalog on Amazon S3 (Preview), Snowflake Polaris (Preview), and the AWS Glue Data Catalog on Amazon S3 (Preview). This is reinforced by enhanced Lakehouse Governance (Preview), which ensures your security policies and access controls apply instantly across this borderless environment.
Unlocking operational data: We’re announcing Spanner Omni (Preview), unchaining the most scalable, globally consistent database on the planet. For the first time, you can run the Spanner engine anywhere — across clouds, on-premises, or on your laptop — with the same capabilities used to run Google.
Bridging the insight to action gap: We’re also closing the gap between insight and action. Most "unified" data platforms force the creation of complex ETL pipelines that block agents from accessing your real-time data. With Lakehouse federation for AlloyDB (Preview), we’re removing these pipelines by providing protocol-level, zero-ETL synchronization to give agents access to deep analytical history with low latency in operational transactions.

Automating the future

Moving to agent scale generates orders of magnitude more workloads. To support this, we are announcing four major performance breakthroughs:

Lightning Engine for Apache Spark delivers up to 2x the price-performance over the proprietary market alternative.
Managed Lustre delivers up to 10 terabytes-per-second of throughput to make sure data moves quickly enough for demanding models.
Bigtable now supports an in-memory tier that delivers sub-millisecond read latency for real-time applications. This means you can finally eliminate separate, side-by-side caching layers.
BigQuery fluid scaling helps lower costs by up to 34% on average for autoscaling workloads, scaling up resources instantly when agents act, and scaling back when they don't.

Build your success on a System of Action

The era of passive observation is over. The future belongs to the System of Action, made possible by Google’s Agentic Data Cloud.

Ready to see what an Agentic Data Cloud can do for your business?
Sign up for a strategy workshop today on how to get your data ready to fuel autonomous agents through a System of Action.

Want to learn more about an Agentic Data Cloud?
Read our blueprint for turning passive data into proactive action.

Oracle AI Database@Google Cloud: The foundation for the Agentic Enterprise

Wed, 22 Apr 2026 12:00:00 +0000

For decades, many of the world’s most critical enterprise datasets have relied on the performance of Oracle databases. Today, we are bringing that reliability even closer to the cutting edge. By enabling customers to run Oracle AI Database services natively within Google Cloud, we’ve bridged the gap between foundational data and the modern AI stack.

With the latest wave of upcoming launches for Oracle AI Database@Google Cloud, we aren't just making it easier to migrate; we are building a direct pipeline from your Oracle systems of record to the insight layer of Google Cloud. By bringing mission-critical data easily and securely to Gemini models and BigQuery, customers can transform static records into autonomous, agentic workflows.

New capabilities announced at Next ‘26

Here is a breakdown of the key new features designed to strengthen your Oracle-to-agentic- AI strategy:

New regions launched: We have significantly expanded the availability of Oracle AI Database@Google Cloud, across 15 regions (and 20 sites) globally. The recent rollout included key global hubs such as Milan, Iowa, São Paulo, Tokyo, Sydney, and Mumbai, among others. With additional regions like Mexico and Turin coming soon, this expansion ensures higher availability and lower latency for your mission-critical workloads across the globe for our Google Cloud customers.
Enhanced AI capabilities: This is the foundation for agentic AI. We are introducing the preview of Managed MCP Server for Oracle workloads, which allows agents like Gemini to interact directly and seamlessly with your Oracle infrastructure. Building on this, the new Oracle AI Database Agent, available in the Google Cloud AI Agent Marketplace, lets you talk to your Oracle data directly from Gemini Enterprise — no custom chatbot or NL-to-SQL solution required.
Database Center integration (Generally Available): To move at the speed of AI, your infrastructure must be healthy and visible. Database Center now supports Oracle AI Database@Google Cloud, providing a "single pane of glass" for your entire data estate. Whether you are running Exadata or Autonomous Database, you can now monitor your inventory and streamline operations through a unified experience within the Google Cloud console.
Knowledge Catalog integration (Announcement): Data discovery is the first step toward intelligence. By extending the Knowledge Catalog to Oracle AI Database@Google Cloud, we are breaking down the walls between your Oracle systems and the Google Data Cloud. This allows for a unified governance and metadata layer, making it easier for customers to find, trust, and use Oracle data and provide context to AI agents.
OCI GoldenGate Service integration (Preview): Real-time data is the lifeblood of AI. This integration enables low-impact, continuous data movement, allowing you to streamline migrations from on-premises environments to Oracle AI Database@Google Cloud. In addition, it provides a live link to BigQuery, enabling operational data analytics that reflect the "here and now" of your business.
VPC Service Controls: Oracle AI Database@Google Cloud administrators can use VPC Service Controls to restrict access to the admin API and create databases within a service perimeter. VPC Service Controls protect businesses from unauthorized access outside the security perimeter, even if credentials have been compromised.

The agentic future

The goal of these integrations is simple: To make your data active. When your Oracle data resides natively in Google Cloud, Gemini doesn't just “talk about” your data — it can work with it. Whether it's an AI agent forecasting supply chain shifts in BigQuery based on live Oracle ERP feeds, or a customer service bot with real-time access to legacy account history, the data vault is more open, accessible, and valuable than ever (while remaining just as secure).

Hear directly from our customer, Banco Actinver, regarding the transformative impact of relocating their Oracle data to Google Cloud.

Get started

You can access Oracle AI Database@Google Cloud through the Google Cloud Marketplace using your existing Google Cloud account and billing.

For more information, visit:

Introducing BigQuery Graph: Unlock hidden relationships in your data

Tue, 14 Apr 2026 16:00:00 +0000

Today, we're thrilled to announce that BigQuery Graph is now available in preview. With BigQuery Graph, we’ve built an easy-to-use, highly scalable graph analytics solution for data engineers, data analysts, data scientists, and AI developers, empowering them to model, analyze and visualize massive-scale relationships in an entirely new way.

As data changes and grows, it’s important to understand how different entities such as people, places, and products relate to one another. After all, data is more meaningful when we know how entities are interconnected. With traditional SQL, to find a "friend of a friend of a friend" requires multiple nested JOIN operations, which are usually challenging to read and write, and the performance degrades exponentially at scale. Finding the "blast radius" of a supply chain disruption during a storm requires multi-hop traversals, a full-scale graph analysis. To better solve this challenge, data is often modeled as a graph representation of the physical world around us, which can be better at finding complex and hidden relationships than traditional relational data structures.

Graph challenges faced by enterprises across industries

Graph technology has been broadly used across industries for fraud detection, recommendation engines, supply chain management, knowledge graph applications, and many others. However, users face some major challenges in adopting graphs:

Data silos and maintenance overhead: Having to store and maintain graph data in a standalone graph database creates data silos, data inconsistency, additional cost — not to mention extra operational overhead.
Lack of graph expertise: Adopting graph technologies often requires learning a new language, paradigm, and potentially a new database. At the same time, organizations’ investment in SQL expertise are less relevant.
Performance and scalability concerns: Many standalone graph databases work well when traversing the graph from a handful of nodes, but struggle to scale to billions of entities as business demands grow.

BigQuery Graph addresses many of these challenges by supporting:

Built-in graph query experience: A more intuitive graph query language (GQL) allows you to find patterns and traverse relationships among disparate data sets, based on the newest ISO GQL standard.
Unified relational and graph data models: Tight integration between graph and relational data models allows you to choose the best tool to model the data on a single source of truth without data duplication or data movement. Full interoperability between graph queries and SQL allows you to continue to leverage existing SQL skills, while taking advantage of the expressiveness of graph queries.
Graph over structured and unstructured data: Rich AI functions, vector and full-text search capabilities are supported with BigQuery Graph, allowing you to use semantic meaning, keyword search on graphs, bridging the gaps of structured and unstructured data.
Graph visualization: You can easily explore, investigate, and explain how your data is connected in an intuitive graph format using BigQuery Studio notebook and Jupyter Notebook.
Industry-leading ease of use, performance and scalability: BigQuery Graph is built upon BigQuery's serverless, scalable, cost-effective and distributed analytics engine that can scale to billions of nodes and edges.
Integration with Spanner Graph: This provides a unified graph schema and graph query language that serve a full spectrum of real-time (Spanner Graph) and batch graph needs (BigQuery Graph). You can also build a virtual graph by combining the latest data from Spanner and historical data from BigQuery without data movement using federated queries.
Chat with your graph: Very soon, you will be able to chat directly with graphs with the Conversational Analytics Agent (stay tuned).

Common BigQuery Graph use cases

BigQuery Graph opens up a realm of possibilities across industries for building intelligent applications:

Financial fraud detection: Analyze complex relationships among users, accounts, and transactions to identify suspicious patterns and anomalies, such as money laundering and irregular connections between entities, which can be difficult to detect using relational databases.
Customer 360: Track customer relationships, preferences, and purchase histories. Gain a holistic understanding of each customer, enable personalized recommendations, targeted marketing campaigns, and improved customer service experiences.
Social networks: Capture user activities and interactions and use graph pattern matching for friend recommendations and content discovery.
Manufacturing and supply chain management: Use graph patterns for efficient stockout analysis, cost rollups, and compliance checks by modeling parts, suppliers, orders, availability, and defects in the graph.
Healthcare: Capture patient relationships, conditions, diagnosis, and treatments to facilitate patient similarity analysis and treatment planning.
Transportation optimization: Model places, connections, distances, and costs in the graph, and then use graph queries to find the optimal route.

BigQuery Graph in the real-world

Many customers across industries have leveraged BigQuery Graph to solve real-world business challenges. Here are a few examples of how they are putting these capabilities into practice:

BioCorteX: drug discovery

"Understanding disease isn't about collecting more data; it’s about understanding the relationships within that data. By leveraging pathway search in BigQuery Graph at a massive scale, reaching depths of 7+ hops, we are finally able to see more of the human metabolism map. This level of scale is what allows us to move beyond trial and error, identifying the precise biological levers that need to be pulled to cure complex diseases. We aren't just guessing anymore, we’re emulating life at the speed of compute." - Nik Sharma, CEO and Cofounder, BioCorteX

Curve: fraud detection

"By implementing BigQuery Graph, we have successfully moved away from the previous limited sql-based approach to a more scalable solution for fraud detection network analysis. This has allowed us to detect sophisticated fraud networks by uncovering hidden connections between seemingly unrelated accounts and transactions. This transition from traditional relational queries to graph-based analytics has showcased measurable business impact with ~£9.1M of savings. This shift has not only improved the precision of fraud detection but has also provided a scalable foundation for protecting the ecosystem without adding significant operational overhead." - Francis Darby, VP Data & ML, Curve

Virgin Media 02: fraud detection

"At Virgin Media O2, we are constantly evolving our defenses to stay ahead of increasingly sophisticated fraud networks. We’ve added a powerful new layer to our already robust fraud alerting system. Using BigQuery Graph, we can now execute complex 4-hop queries that map the hidden relationships between accounts, devices, and activities. This deeper visibility allowed us to identify networks of suspicious addresses. This doesn't just catch fraud; it acts as an early warning system, flagging new connections to known risk networks before they can cause damage." -- Jonathon Ford, Director Data Applications, Virgin Media O2

How to use BigQuery Graph

BigQuery Graph is more than just a new feature; it's a new way of thinking about data, empowering you to ask bigger questions, uncover deeper insights, and solve your most challenging problems.

You can get started in three simple steps:

Step 1: Create graph schemas on top of the relationship tables using DDL with a single copy of data.

Create a finance graph by mapping relational tables into “Account”, “Person”, "Loan" nodes and their relationships “Transfers”, “Owns”, "Repays" via edges.

code_block: <ListValue: [StructValue([('code', 'CREATE PROPERTY GRAPH graph_db.FinGraph\r\nNODE TABLES (\r\n graph_db.Account KEY(id),\r\n graph_db.Person KEY(id),\r\n graph_db.Loan KEY(id)\r\n) \r\nEDGE TABLES (\r\n graph_db.Transfers \r\n KEY (id, to_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Account (id)\r\n DESTINATION KEY (to_id) REFERENCES Account (id), \r\n graph_db.Owns\r\n KEY (id, account_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (account_id) REFERENCES Account(id),\r\n graph_db.Repays\r\n KEY (id, loan_id, timestamp) \r\n SOURCE KEY (id) REFERENCES Person (id)\r\n DESTINATION KEY (loan_id) REFERENCES Loan(id)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051dbaa280>)])]>

Step 2: Use intuitive SQL/GQL to traverse data relationships and find hidden connectivities.

Find the accounts owned by Jacob and the loans he repays from those accounts:

code_block: <ListValue: [StructValue([('code', 'GRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person {name: "Jacob"}) \r\n -[own:Owns]->(account:Account)\r\n -[repay:Repays]->(loan:Loan)\r\nRETURN\r\n account.id AS account_id,\r\n loan.id AS loan_id'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051dbaae50>)])]>

Combine vector search with graph traversals to find fraudster-like accounts and their transfer activities within 1-6 hops:

code_block: <ListValue: [StructValue([('code', "DECLARE similar_account_to_fraudster DEFAULT ((\r\n SELECT array_agg(base.id)\r\n FROM VECTOR_SEARCH(TABLE graph_db.Account, 'embedding',\r\n (SELECT * FROM graph_db.Account WHERE id=102), 'embedding', \r\n top_k => 6)\r\n));\r\nGRAPH graph_db.FinGraph\r\nMATCH\r\n (person:Person)-[own:Owns]->\r\n (account:Account)-[transfer:Transfers]->{1,6}\r\n (to_account:Account)\r\nWHERE to_account.id IN \r\n UNNEST(similar_account_to_fraudster)\r\nRETURN\r\n person.id AS person_id,\r\n account.id AS src_account,\r\n to_account.id AS to_account"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051dbaa3d0>)])]>

Step 3: Visualize graph results to detect connectivity of disparate data in a more intuitive way in BigQuery Studio notebook.

If you are looking for a specialized graph visualization tool, BigQuery Graph has integrated with industry leading partners including G.V(), Graphistry, Kineviz, Linkurious. They allow you to see a visualization of BigQuery Graph query results outside the Google Cloud console.

Ready to get started?

The future of data analysis is connected. With BigQuery Graph, you have the power to unlock that connectivity and transform your business into actionable insights grounded with your enterprise knowledge. Start exploring today and unleash the power of your data's interconnected relationships!

Visit the BigQuery documentation: find overview and quickstart guide.
Explore tutorials: get hands-on experience with BigQuery Graph through tutorials.
Share your feedback: join our community, and get your questions answered via bq-graph-preview-support@google.com.
Related blogs:

From operational to analytical: The unified Spanner Graph and BigQuery Graph solution

Tue, 14 Apr 2026 16:00:00 +0000

Understanding the relationships within your data is crucial for uncovering hidden insights and building intelligent applications. However, managing operational (OLTP) and analytical (OLAP) graph workloads usually means wrestling with disconnected databases, building brittle data pipelines, and managing complex integrations. This fragmentation creates data silos, increases operational overhead, and limits scalability.

Today, we're thrilled to introduce a unified graph database and analytics solution powered by Spanner Graph and BigQuery Graph. The solution consists of the two platforms, recommended blueprints for how to deploy them, and getting started guides for the most prominent use cases. In this blog, we review the solution’s components, provide an overview of the most common use cases, and hear from customers who have deployed the solution in the real world.

Spanner Graph for operational workloads

Spanner Graph reimagines graph data management, bringing together graph, relational, search, and generative AI capabilities into a single database. It is backed by Spanner’s signature unlimited scalability, high availability, and strong consistency.

With Spanner Graph, you get:

Integrated table-to-graph mapping: Define graphs directly over your existing Spanner relational tables, allowing you to view and query operational data as a graph without data duplication.
Interoperable graph and relational querying: Leverage an ISO-standard Graph Query Language (GQL) interface for intuitive pattern matching, and mix GQL with SQL in a single query to traverse both graph and tabular data together.
Advanced search and AI integration: Utilize built-in vector search, full-text search, and Vertex AI integration to retrieve data by semantic meaning and power intelligent applications directly within your database.

Customers are already using Spanner Graph to power high-throughput, low-latency applications - for identity resolution across millions of entities, identifying dependencies across vast complex environments, data lineage, customer 360 use-cases, and enhancing real-time fraud detection.

"Open Intelligence is our foundational intelligence layer that securely connects trillions of live data points from clients, partners and WPP in a privacy-first way and is now integrated and powers WPP’s agentic marketing platform, WPP Open. Enabled by Google Cloud's Spanner Graph, Open Intelligence is a significant advancement in AI-driven marketing and we are excited about extending the use case for analytical graph workloads on BigQuery Graph." - Rob Marshall, Head of Strategy, Data & Intelligence, WPP

BigQuery Graph for analytical workloads

While Spanner Graph handles your active operations, true large-scale analysis requires exploring relationships across billions of nodes and edges to identify patterns and query historical data. Just as SQL relies on distinct tools for databases and data warehouses, the graph landscape requires specialized tools for different workloads. That's why we built BigQuery Graph.

BigQuery Graph brings connected data analytics directly into your data warehouse. You can map existing BigQuery data to a graph schema and query it with SQL or GQL to uncover hidden relationships in massive datasets - without moving any data.

Key capabilities include:

Integrated table-to-graph mapping: Map your existing BigQuery tables to graphs instantly, uncovering hidden relationships in your data warehouse without building ETL pipelines or moving a single byte of data.
Interoperable graph and relational querying: Apply the same expressive pattern matching of GQL to massive historical datasets, and mix SQL with GQL in a single query to combine the familiarity of your data warehouse with powerful graph traversal.
Advanced search and AI integration: Leverage native integration with BigQuery AI for predictive analytics, alongside built-in vector search, full-text search, and geospatial functions to locate connected information across billions of records.

Spanner Graph and BigQuery Graph as a unified solution

While each platform is powerful on its own, their true value emerges when they are deployed together. By connecting your operational and analytical environments, you eliminate data silos and accelerate your time-to-insight without compromising database performance.

"Spanner Graph enables Yahoo to unify our data into a connected foundation at a global scale, powering real-time, intelligent decision-making across our agentic advertising platform. This enhances our AI-driven approaches that drive one of the largest digital advertising ecosystems, and we look forward to building on it with BigQuery Graph to unlock deeper analytics and predictive capabilities to power future innovation." - Gabriel DeWitt, Head of Consumer Monetization, Yahoo

Take financial fraud detection as an example: your application can use Spanner Graph to instantly identify a suspicious connection and block a transaction at checkout. Meanwhile, BigQuery Graph can analyze petabytes of historical transaction data to expose the complex, long-term fraud ring that initiated it.

Here is how these two engines integrate to create an end-to-end graph workflow:

1) A unified graph query and schema experience

A core advantage of this solution is the consistent schema and GQL shared across both platforms. This shared language reduces development time and minimizes the friction of context-switching.

For example, to find potential fraud rings originating from a specific account in real-time, you would use this Spanner Graph query:

code_block: <ListValue: [StructValue([('code', 'GRAPH FinGraph\r\nMATCH p=(:Account {id: @accountId})-[:Transfers]->{2,5}(:Account)\r\nRETURN PATH_LENGTH(p) AS path_length, TO_JSON(p) AS full_path;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d8e1130>)])]>

To run that same analysis to find all accounts involved in historical fraud rings, the BigQuery Graph query is nearly identical:

code_block: <ListValue: [StructValue([('code', 'GRAPH bigquery.FinGraph\r\nMATCH p=(:Account)-[:Transfers]->{2,5}(:Account)\r\nRETURN PATH_LENGTH(p) AS path_length, TO_JSON(p) AS full_path;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d8e1c10>)])]>

2) Query Spanner data in BigQuery Graph through Data Boost

With Data Boost, you can query Spanner Graph data directly from BigQuery without impacting performance of your transactional workloads. This allows you to build a "virtual graph" combining real-time operational data from Spanner with historical analytics in BigQuery - without moving any data.

For instance, you can combine real-time Account and User nodes from Spanner Graph with historical LogIn edges from BigQuery to identify suspicious login patterns across different devices.

To do this, you first connect BigQuery to Spanner using the CREATE EXTERNAL SCHEMA statement:

code_block: <ListValue: [StructValue([('code', "CREATE EXTERNAL SCHEMA spanner\r\nOPTIONS (\r\n external_source = 'google-cloudspanner:/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE',\r\n location = 'LOCATION'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d8e15e0>)])]>

Next, define a BigQuery Graph, incorporating tables from both Spanner and BigQuery:

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE PROPERTY GRAPH bigquery.FinGraph\r\n NODE TABLES (\r\n -- Account and Person are stored in Spanner,\r\n -- made available in BigQuery through the `CREATE EXTERNAL SCHEMA` statement.\r\n spanner.Account KEY (account_id),\r\n spanner.Person KEY (person_id),\r\n -- Media is stored in BigQuery.\r\n bigquery.Media KEY (media_id)\r\n )\r\n EDGE TABLES (\r\n -- Transfers and Owns are stored in Spanner.\r\n spanner.Transfers AS Transfers\r\n KEY (transfer_id)\r\n SOURCE KEY(account_id) REFERENCES Account\r\n DESTINATION KEY(target_account_id) REFERENCES Account,\r\n spanner.Owns AS Owns\r\n KEY (person_id, account_id)\r\n SOURCE KEY(person_id) REFERENCES Person\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n -- LogIn is stored in BigQuery.\r\n bigquery.LogIn AS LogIn\r\n KEY (login_id)\r\n SOURCE KEY(media_id) REFERENCES Media\r\n DESTINATION KEY(account_id) REFERENCES Account,\r\n );'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d8e1160>)])]>

Finally, execute a query on BigQuery Graph to access data across both Spanner (accounts, users, transfers, owns) and BigQuery (logins, devices), identifying potentially suspicious login patterns:

code_block: <ListValue: [StructValue([('code', 'GRAPH bigquery.FinGraph\r\nMATCH p=(owner:Person)-[:Owns]->\r\n (:Account)<-[login:LogIn]-\r\n (media:Media {blocked: true})\r\nRETURN TO_JSON(p) AS full_path\r\nORDER BY login.time\r\nLIMIT 20;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051d8e1520>)])]>

3) Export BigQuery data into Spanner Graph through reverse ETL

When you need to bring analytical data back into Spanner for low-latency, real-time querying, you can use reverse ETL without additional pipelines. For example, you can import historical device data (IP addresses, device IDs) from BigQuery into Spanner Graph to enhance your real-time fraud detection operations:

code_block: <ListValue: [StructValue([('code', 'EXPORT DATA\r\n OPTIONS (\r\n uri = \'https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE/databases/DATABASE\',\r\n format=\'CLOUD_SPANNER\',\r\n spanner_options="""{ "table": "Media" }"""\r\n ) AS \r\nSELECT * FROM Media;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f051daf44c0>)])]>

4) Visualize your graph data

Visualizing connected data is core to analysis, explorations and investigations. With Spanner Studio and BigQuery Studio (coming soon), you can instantly visualize your graph data without leaving your familiar environment or setting up external tools. For deeper programmatic exploration, you can also leverage Spanner Graph notebook and BigQuery notebooks to render query results directly within your existing data science workflows.

5) Graph visualization partner integrations

Spanner Graph and BigQuery Graph also integrate with leading graph visualization partners to provide a comprehensive suite of exploration tools:

Kineviz: Combines cutting-edge visualization with advanced analytics via GraphXR.
Graphistry: Extracts meaningful insights from large datasets using a GPU-accelerated visual graph intelligence platform.
G.V(): Offers a quick-to-install client for high-performance visualization and no-code data exploration.
Linkurious: Detects and analyzes threats in large volumes of connected data via the Linkurious Enterprise platform.

One unified solution for all your graph needs

Together, Spanner Graph and BigQuery Graph provide a unified solution for operational and analytical needs across various use cases:

Domains	Spanner Graph	BigQuery Graph
Financial Services	Instantly blocks anomalous, suspicious transactions.	Uncovers complex, long-term fraud rings.
Retail & E-commerce	Serves personalized product recommendations on the fly.	Analyzes vast purchasing histories to predict demand.
Cybersecurity	Isolates active threats and traces attack origins instantly.	Models historical vulnerabilities to strengthen defenses.
Healthcare	Powers clinical decision support systems at the point of care.	Analyzes population health trends and disease risk factors.
Supply Chain	Tracks goods globally and alerts teams to immediate disruptions.	Identifies systemic bottlenecks to optimize future routing.
Telecommunications	Creates a network digital twin for detecting anomalies, and root cause analysis in real-time.	Analyzes traffic patterns at scale to plan future infrastructure upgrades.

Get started with Spanner Graph and BigQuery Graph today

With Spanner Graph and BigQuery Graph, we’re excited to offer a unified graph data management experience across your operational and analytical needs.

Explore Spanner Graph's use cases and setup guide for your operational workloads, and the BigQuery Graph overview and creation guide for your analytical needs. To experience the full power of this combination, check out our unified solution guide and try the codelab.

QueryData helps agents turn natural language into queries for AlloyDB, Cloud SQL and Spanner

Fri, 10 Apr 2026 16:00:00 +0000

QueryData launches in preview today. It is a tool for translating natural language into database queries with near-100% accuracy. With QueryData, you can build agentic experiences across AlloyDB, Cloud SQL (for MySQL and PostgreSQL), and Spanner (for GoogleSQL). It builds upon Google Cloud’s #1 spot in the BiRD benchmark, one of the world's most competitive benchmarks for natural-language-to-SQL – as well as upon Gemini-assisted context engineering.

Developers are already seeing the benefits from QueryData, including Hughes Network Systems, a leader in telecommunications, that deployed QueryData in production. “We have transformed user support operations with Google Cloud’s data agents. At the heart of our solution is QueryData, enabling near-100% accuracy in production. We are excited about the future of agentic systems!" - Amarender Singh Sardar, Director of AI, Hughes Network Systems

The opportunity for agentic systems: from intent to action

Agentic systems are evolving from human-advisory roles into active decision-makers. To execute business actions accurately, agents require precise information from operational databases (such as pricing, inventory, or transaction records).

With requests expressed in natural language, bridging the gap between conversational input and database records is essential. High-quality natural language-to-query capability is a critical requirement for enabling agents to take actions.

The developer’s dilemma: why natural language for agents with databases is hard

Hurdles for agents querying enterprise data are threefold: accuracy, security and ease of use. QueryData addresses all three of them:

Accuracy – Inaccurate answers carry a risk of poor business decisions, disappointed end-users or financial losses. In many industries, translating text into SQL with 90% accuracy is simply insufficient for taking action.
Security – how to make sure that each person (or agent) only queries the data they are allowed to see? Enterprises need auditable, deterministic access controls. Relying on the LLM's judgement (aka “probabilistic” access controls) falls short of that. Even a low risk of security breaches means disproportionately high losses
Ease of use – Achieving high accuracy requires developers to provide extensive contextual information about their data. This can be a laborious task. Another example of developer friction is integration and maintenance of agentic tools

Understanding the accuracy gap

LLMs are really good at writing query code. However, to write accurate queries for a given database – it takes more than coding skills, and more than just parsing the schema:

Schemas can be unclear – developers often use shorthands or abbreviated names. For example: what does a column named “product” mean? A product category? A particular model…? It gets even worse with column names like “prod” or simply “p”
Values can be ambiguous – let’s take a column named “order return status”... where values are expressed as integers: “1”, “2” and “3”. Which of these represents “returned” or “return initiated”?
Schemas cover data structure, but not the business logic – Your business may define “monthly active users” as those who have posted at least once, not just logged in (but database may lack this nuance).
Underspecified queries – Natural language questions can be ambiguous, like “latest sales”.

How QueryData solves for near-100% accuracy

QueryData leverages the Gemini LLM, as well as context which describes your unique database.

Database context, which is essentially the code fueling QueryData, is a set of descriptions and instructions including:

Schema ontology – information about the meaning of the data. Descriptions of columns, tables and values. It helps QueryData overcome ambiguity by figuring out what data is needed to answer the question
Query blueprints – guidelines and explicit instructions for how to write database queries to answer specific types of questions. Templates and facets specify the exact SQL to write for a given type of question.

As a last resort, QueryData will detect when a clarifying question needs to be asked.

Deterministic security for your queries

Agentic applications require deterministic, auditable security. Developers can use Parameterized Secure Views (PSVs) to define agent access via fixed parameters, like user ID or region. By passing these security-critical parameters separately from queries, the application ensures agents can only access the authorized data. This prevents agents from querying restricted information, even if they attempt to do so.

Support for PSVs is available today in AlloyDB, and coming soon to Cloud SQL and Spanner.

Ease of use for quality hill-climbing and tool integration

Integration of QueryData into your agentic workflows is easy. The QueryData API can be used directly or exposed as a Model Context Protocol (MCP) tool via our popular open source MCP Server: MCP Toolbox for Databases. QueryData automatically works across different database dialects – no need for database-specific code, just one API to query them all.

Another area where QueryData makes things easier for developers – is context engineering. It is the process of iteratively evaluating and optimizing context. It is critical to QueryData’s ability to accurately query your database. Developers using QueryData enjoy support from a robust suite of tools:

Out-of-the-box context generation – upon configuring QueryData, the Context Engineering Assistant, a dedicated agent in Gemini CLI, will help you create the very first context set for your database.
Evals: Developers can use the bundled Evalbench framework to measure accuracy against a set of tests specific to your use case
Context optimization: the Context Engineering Assistant reviews eval results, recommends changes and then helps run evals again. Through this iterative process, you can reach near-100% accuracy.

What you can build with QueryData today

Developers are already building with QueryData. Examples include:

Customer-facing applications: a real estate search engine, where QueryData translates user prompts into database queries, and then schedules viewing appointments
Internal tools: an AI-powered staffing app querying human resources data and then enabling managers to assign workers to shifts
Multi-agent architectures: a trade compliance workflow where a top level agent asks a sub-agent to verify that an entity has appropriate KYC (“Know Your Customer”) status. The KYC agent queries a database to confirm the customer’s identity.

Next steps

You can have your agent start using QueryData as a tool for near-100% accurate database calls today. For more details, explore our technical documentation:

Check out the "Swiss property search" high-fidelity demo, pictured below (video walkthrough here). Note: This is an independent project (not maintained by Google Cloud) and is for illustrative purposes only: GitHub link

Near-100% Accurate Data for your Agent with Comprehensive Context Engineering

Fri, 10 Apr 2026 16:00:00 +0000

Agentic workflows are already used for initiating action. To be successful, agents typically need to combine multiple steps and execute business logic reflective of real-life decisions. But, as developers rush to deploy these autonomous agents, they are slamming into a wall: the compounding error problem of accuracy.

To understand why agentic workflows require near-100% accuracy on questions that are answerable by your database data, let’s look at the numbers: Assume an accuracy of 90% in a single-step AI process. You ask a question; you get a correct answer 90% of the time. But in an agentic workflow, the AI takes multiple dependent steps – and errors compound exponentially.

Let’s run the numbers on a 90% accurate agent:

One step: 90% success rate.
Two steps: 0.90 × 0.90 = 81% success rate.
Five steps: 0.90^5 = 59% success rate.

Now, imagine that same five-step workflow running on an 80% accurate agent. The success rate plummets to just 33%.

In a business context, even 90% accuracy is often insufficient. And 59% or 33% success rate is downright catastrophic. Indeed, in many industries near-100% accuracy is needed, because the agentic application is customer-facing and inaccuracies lead to loss of trust and loss of revenue. Furthermore, in many industries there are legal, safety and compliance requirements. In such industries, near-100% accuracy must be combined with explainability so that the human-in-the-loop can understand and verify the answers.

Example: consider a real estate agency using an AI workflow to handle new tenant onboarding in a five-step flow. The agentic flow must:

extract data from an application
run a background check via an API
query the database for available units
draft a lease, and
email the tenant.

If step three fails because the AI makes a mistake in the database query and pulls a unit for the wrong city – then, steps four and five will generate a legally binding lease for a property that doesn't exist, and then send it to the client. The cost of manual remediation, lost trust, and legal liability makes anything less than near-perfect execution completely unviable.

Agentic Tools: A Path to Accuracy and Explainability

To achieve the required accuracy and explainability when agents interact with enterprise databases, developers are turning to specialized tools. QueryData is such a tool for agents, designed specifically to offer near-100% accuracy for natural language-to-query. By enabling agents to retrieve correct data, QueryData ensures that agents are well-equipped to take action.

The Key Ingredient: Comprehensive Database Context

A Large Language Model (LLM) inherently knows many dialects of SQL, but it doesn't know your business logic and your database. Agentic tools use context to bridge that gap. Context is essentially the code which a tool like QueryData uses to guide the LLM towards correct answers. Crucially for achieving near-100% accuracy and explainability, the QueryData works with a comprehensive database context, organized into three main pillars: Schema Ontology, Query Blueprints and Value Searches.

1. Schema Ontology

Schema ontology is about understanding your database structure and semantics. This includes natural language descriptions of tables and columns. The QueryData LLM has a greater chance to translate the natural language question into the correct query using these instructions. You can think of schema ontology as a set of “cues” or “hints” – meant to steer the LLM into picking the right tables and columns and synthesizing them correctly into a database query. A couple of examples:

Here is what a database-level description could look like for a search engine of real estate listings:

“Listings, real estate agents and information about communities where listings are located – schools, amenities and hazards: fire, flood and noise”

The table description for property could look like this:

“Current real estate listing, including houses, townhomes, condos and land”

An example of column description that explains that the proximity_miles means

“property distance from the district’s school in miles”

For ease of use, you can autogenerate rich descriptions, which will typically include sample values of the column.

2. Query Blueprints

If ontology is the vocabulary, query blueprints are the way to introduce fine control of the generated SQL for important questions that must absolutely receive accurate and business-relevant answers. For example, consider the question “Riverside houses close to good schools”. The interpretation of “close” and “good” provided by Gemini is impressive- in a demo application it translated to

…WHERE city_name = 'Riverside' AND school_ranking <= 5ORDER BY proximity_miles ASC

But this interpretation still leaves much to be desired: Wouldn’t you drive one more mile for a school whose school_ranking is much higher than the Gemini-chosen cutoff? Of course you would! Both proximity and school ranking should affect the overall ranking. A no-cut-corners developer will take control of the interpretation of “close to good school” by introducing a sophisticated ranking function, which may be the result of continuous A/B experiments, along with sensible cutoffs.

Templates
In particular, she will use a template: A pair of natural language intent with its respective parameterized SQL translation.

parameterized_intent : “$1 houses close to good schools”,parameterized_SQL : “SELECT … FROM … WHERE city_name = $1 AND "school_ranking" <= 5 AND "proximity_miles" <= 2ORDER BY school_score("school_ranking", "proximity_miles")”– the school_score stored procedure combines school ranking and proximity into a single ranking

Such info can be given in a JSON file but, even more user-friendly, you can use Gemini CLI, prompt it with an example natural language question and your ideal respective SQL and it will produce the JSON for you.

Furthermore, templates enable the agent to explain how the question was interpreted. This mitigates the effect of the occasional remaining inaccuracies, allowing a human-in-the-loop or agent to understand what the answer of QueryData means.

Facets
While plain query templates provide highly accurate and explainable answers, they have low flexibility: they can only answer the specific critical question patterns that they were designed for. What if you wanted to combine the “close to good schools” with price conditions, square footage, bedroom conditions and more. The facets generalize templates to combine the best of both worlds: highly-accurate, explainable answers to large numbers of questions.

"parameterized_intent": "Property price between $1 and $2", "parameterized_sql_snippet": "T.\"price\" BETWEEN $1 AND $2"

Value searches
Some ambiguities in the NL question are rooted deep in the private data of your database and need a collaboration of the LLM with the database to disambiguate. Value searches solve the hard problem of correctly associating data values in the database with the “entities” that the question talks about.

For example, consider the question “Westwod''s sold properties in the last 1 month.” The first problem is that there is no “Westwod”; it is a misspelling of “Westwood”. Apart from the misspelling, there is a second problem - a deeper ambiguity in our sample database: “Westwood” appears as both the name of a real estate brokerage and as the name of a city. Value searches can utilize the built-in powerful vector+text search capabilities of Google Cloud’s AI-native databases. Here, value searches will enable QueryData to respond to the agent that this is likely a misspelling of ‘“westwood, which appears as both a real estate brokerage and a city name.

Accuracy As Foundation for Agentic Actions

Agentic workflows are poised to revolutionize operations, but they are unforgiving when it comes to accuracy. Through context engineering, businesses can mitigate compounding failures and start trusting their autonomous agents to deliver.

As a next step, you can explore how to create context sets across these databases:

And here – your “cheat sheet” for building blocks of context (courtesy by Nanobanana):

Spanner's multi-model advantage for the era of agentic AI

Tue, 31 Mar 2026 17:00:00 +0000

In the age of agentic AI, the role of databases is fundamentally changing. It’s evolving from a passive data repository into an intelligent, active context hub designed to ground generative AI foundation models and a reasoning engine that drives proactive actions. To power sophisticated AI and agentic workflows, a database must do more than store and query your data — it must facilitate reasoning, provide deep contextualization, and turn static intelligence into proactive action – all in a multiple data model environment.

Rather than manually orchestrating data across disparate silos, a multi-model database approach coalesces relational, vector, and graph data into a rich, unified knowledge base. This allows AI to leverage situational, semantic, and relationship context simultaneously. Spanner, Google Cloud’s globally consistent, scalable, fully managed database, is built for the AI era. It offers a unified approach to integrate your data and power sophisticated, agentic AI.

In this post, we’ll look at how Spanner is helping organizations achieve production-ready AI, and if you want more real-world examples, you can read this companion article. It covers four key areas — fraud detection, personalized recommendations, hybrid search, and autonomous network operations.

The Power of interoperable multi-model databases

Today’s common, fragmented, multi-database strategy introduces critical challenges:

Data inconsistency: The absence of a single source of truth forces developers to simulate consistency through brittle application code, leading to data duplication, stale data, and significant governance and security vulnerabilities. Your application's overall reliability is effectively capped by the database with the lowest SLA.
Operational and skill silos: Managing disparate systems creates massive operational overhead and fractures your team into skill-silos, imposing a "complexity tax" that directly inflates costs and drags down development velocity.
Unified intelligence blockers: Inherent data silos and the ETL latency create an architectural barrier, preventing the real-time, context-aware intelligence required to power cutting-edge AI applications.

Together, these challenges create a significant structural disadvantage in the AI era.

Spanner’s AI advantage

We’ve been constantly evolving Spanner over the years, to keep up with the most demanding cloud workloads and Generative AI offers some of the most unique and novel database challenges yet.

Building on its core foundation, Spanner introduced fully interoperable multi-model capabilities last year, allowing you to access and query your data using diverse models — including relational, key-value, graph, and vector —all within a single, highly capable database foundation. Each data model is powerful in their own right:

Relational: Spanner has pioneered the relational scale-out database, offering ANSI SQL with both Google SQL and PostgreSQL dialects that delivers 5 9s availability and strong consistency across the globe.
Key-value: Spanner also offers high-performance, key-value database capabilities. Its Cassandra native endpoint allows customers to easily lift and shift their Cassandra workload to Spanner without change to application codes
Graph: Built on the ISO standard GQL, allowing you to model data natively as a graph or as a simple overlay on top of relational data.
Vector: A fully integrated semantic search solution offering both KNN and ANN, with the latter built using Google's state-of-the-art ScaNN technology, capable of supporting indexes with over 10 billion vectors.
Full-Text Search: building on Google’s decades of search expertise that allows you to search for across structured and unstructured data with advanced information retrieval tools out of the box for 40+ languages
Integration with Data Warehouses: Seamlessly connecting transactional data with insights from analytical processes.

This unified architecture eliminates the need for complex data synchronization across multiple specialized databases, radically simplifying your environment and accelerating development. Customers can now leverage Spanner's interoperable multi-model capability to combine distinct data types seamlessly.

Companies making AI a globe-spanning success

MakeMyTrip is one of many companies putting AI into production in demanding real-world environments thanks to the multi-model capabilities of Spanner.

An India-based online travel company, MakeMyTrip has successfully consolidated four specialized databases into a single Spanner instance, significantly reducing operational complexity, while accelerating AI innovation and achieving high performant and high quality outputs.

Ravindra Tiwary, director of technology development at MakeMyTrip, saw multiple benefits to her organization’s Spanner migration: “We consolidated MongoDB, Neo4j, Elasticsearch, and Qdrant into one unified system, achieving a 75% reduction in operational complexity. This transition eliminated the friction of managing multiple database nuances and redundant synchronization pipelines.

The most transformative advantage is executing unified queries across lexical, keyword, and embedding searches in a single platform. This consolidation accelerated our feature innovation cycle by 30% to 50% for consolidated-view features and saved 5.5 to 9.5 operational hours per week, per destination.

With Spanner as our single source of truth, we eliminated data drift and ensured facts are updated atomically. This directly improved our answer-quality score by 9%. Spanner now provides the scalable, high-performance foundation essential for our 'Destination Expert' ecosystem (a homegrown GenAI-powered travel planner bot providing personalized travel recommendations) and future AI workflows.”

And they’re not the only ones who’ve reached new destinations on their AI journey. To learn how leading organizations like Target, Palo Alto Networks, and MasOrange are succeeding with Spanner, check out our next post.

To get started on your own AI journey with Spanner, visit our Spanner page to learn more and get started today.

Real-world success with Spanner’s fully interoperable multi-model database

Tue, 31 Mar 2026 17:00:00 +0000

In the first post on the power of multi-model databases to lay the foundations for gen AI, we highlighted how Google Cloud Spanner helps organizations overcome some of the challenges presented by traditional approaches to database architecture and management. In this post, we dive deeper on the specific examples, across four common use cases.

We are seeing customers increasingly choose Spanner's multi-model capabilities to address three key strategic goals:

A foundation of scale and reliability: Many specialized databases for graph, vector, or search, are built on traditional, single-machine architectures. As a result, they face fundamental challenges with scalability, availability, and consistency. We see customers migrate off these specialized systems because they have - or are about to - hit a wall. All Spanner’s data models are built on its tried-and-true platform offering 99.999% availability, automatic scaling, and limitless horizontal scale, and they can easily extend to new capabilities. For example, adding a vector embedding column to the existing graph schema.
Consolidating database sprawl and eliminating ETL: Managing, securing, and patching multiple disparate databases, each with its own data model, query language and backup policy can be an operational nightmare for users. Extract, transform, load (ETL) pipelines required to sync data, are especially frustrating as they often create inconsistency and delays. Spanner eliminates this complexity by offering multiple data models in a single unified database, eliminating extra data copies, inconsistency and management overhead. Moreover, Spanner’s interoperable multi-model capabilities allow a developer to write one SQL query that joins relational tables, traverses a graph relationship, and filters on a vector or text search function.
Future-proofing for evolving application needs: While many customers start with a simple application, they know it will need to get smarter and more complex over time. In Spanner, adding a graph-based recommendation or AI-powered vector search can be an afterthought. A developer can simply turn on graph or search capabilities on their operational data, with a simple data definition language (DDL) command. With Spanner, there is no painful migration, no complex re-architecturing and no growth ceiling. Instead, customers can build on a reliable relational database while seamlessly adding new, advanced data models as their application evolves.

Here’s how customers across industries are already leveraging Spanner's evolving multi-model capabilities to solve their toughest data challenges and achieve early success:

1. Fraud detection

Fraudsters often exploit complex, non-obvious patterns across multiple transactions and accounts. Traditional relational databases struggle to detect these intricate relationships in real-time. Spanner combines relational queries with graph analytics to enable real-time pattern recognition. This allows businesses to efficiently identify suspicious clusters or unusual connections that might indicate fraudulent behavior, significantly reducing financial losses and enhancing security.

DANA: Anti-money laundering for fast growing customer base

DANA, an Indonesia-based e-wallet app, offering payments and digital financial services including lending, insurance and investments, has adopted Spanner Graph to support its critical anti-money-laundering, or AML, efforts.

Challenge: With a massive and still rapidly growing user base, DANA struggled to scale and meet query performance SLAs using existing relational databases to detect money laundering patterns in transactions. Moving to do the analytics in graph databases was obvious, but many graph database providers in the market simply could not handle the scale.
Solution: Spanner was selected after an elaborate RFP process due to its high availability, virtually unlimited scale, and external consistency. The ability to use full-text search (FTS) and vector search directly within the Graph model were key differentiators.

Palo Alto Networks: Access graph for SaaS identity

Palo Alto Networks, one of the leading cybersecurity firms, leverages Spanner to provide insights into organizational identity posture, surfacing misconfigurations and over-privileged accounts, dormant accounts, unrotated credentials, over-privileged accounts, and accounts missing in the Identity Provider (IDP).

Challenge: The team needed to build a world-class agent security product for the AI era that could innovate quickly while ensuring highly scalability without creating data silos.
Solution: They built an "Access Graph" on Spanner to connect user identities, access permissions, and the associated user activities within the SaaS applications. Spanner allows them to achieve massive scale with a single schema for both graph and non-graph use cases seamlessly.

Verisoul.ai: Real-time fake user detection

Verisoul offers a unified AI-powered platform to detect and prevent fake users, ensuring accounts are real, unique, and trustworthy.

Challenge: Verisoul previously built and maintained 10 different independent services across Postgres, Cassandra, and Neo4j to handle a variety of types of data, such as network intelligence, device intelligence, behavioral and sensor data, email and multi accounting. This complexity made it difficult to provide zero-latency detection to counter the speed, scale and sophistication of modern-day fraud attacks,
Solution: By consolidating onto Spanner, Verisoul now can monitor hundreds of customers with millions of accounts in real time, capturing every login, page view, click, and mouse move. Spanner provided an all-in-one database for Graph, vector search, and seamless integration with BigQuery, allowing them to eliminate maintenance overhead while delivering unlimited throughput all with a simple architecture.

2. Recommendation engines

Personalized recommendations are at the heart of online consumer businesses. Building an effective recommendation engine requires analyzing vast amounts of user behavior data, product and service attributes, and historical interactions. Spanner’s interoperable queries allow you to combine user profiles (relational), interaction history (search), and product similarity (graph) to generate highly relevant recommendations in real time, driving better user engagement and improving conversion rates.

Target: Combining Vector and Graph Search for gift recommendations

Target sought to elevate the holiday shopping experience with a generative AI-powered Gift Finder for highly personalized gift recommendations.

Challenge: The application was run on a specialized search database, providing limited gift recommendations. To enhance and personalize the experience, Target needed a sophisticated upgrade.
Solution: Target selected Spanner Graph for its versatile hybrid query model. The solution blends graph traversals with vector search with their proprietary embeddings delivering intuitive, real-time product suggestions — all delivered just in time for the 2025 Black-Friday-Cyber-Monday shopping rush.

True Digital Group: Consolidating AI search

True Digital Group, Thailand's leading telecom-tech company, offers customers a wide array of high-quality digital services, encompassing both streaming and print media, along with customer loyalty tracking. Their AI-driven intelligent search feature ensures accurate content retrieval based on keywords and user intent.

Challenge: A fragmented stack with multiple databases resulted in outdated data, inconsistent tokenization, multiple query languages, and poor search quality, causing users to avoid the search feature.
Solution: True Digital consolidated all search functionality onto Spanner. By combining keyword and intent-based search results using SQL, they significantly improved search relevancy and accuracy, leading to increased customer engagement and satisfaction.

3. Hybrid search

Information retrieval is the critical bridge that grounds AI models in factual, up-to-date data and enables agentic workflow. Often, users must locate a specific needle in a haystack — searching through a massive corpus of legal documents, financial reports, or research papers. Interoperable multi-model Spanner empowers customers with hybrid search capabilities, ensuring AI models retrieve the most relevant context at any scale with pinpoint accuracy.

Rogo: Financial workflow automation

Rogo connects proprietary internal data with external financial sources like filings, PitchBook, LSEG, FactSet, and S&P Capital IQ to help finance professionals automate their workflows, from building pitch decks to drafting investment memos.

Challenge: Rogo needs to ingest and connect data from dozens of sources at once, across both structured and unstructured formats. Finding the right backend to support that wasn't straightforward.
Solution: Rogo chose Google Cloud Spanner for its high performance, scalability, and easy management. It lets them store and query both relational and document-based data in one place, which has made it easier to audit and maintain as the platform has grown.

Inspira: Streaming legal intelligence

Inspira, a leading legal tech company, provides AI-driven solutions tailored for legal research and general workforce optimization. Their platform serves law firms, corporations, and government entities, managing a massive repository of 75 million legal documents and 440 million vectors.

Challenge: Before migrating to Spanner, Inspira struggled with a complex, fragmented architecture, relying on a polyglot system consisting of Elasticsearch, BigQuery and Cloud SQL. This led to complicated data synchronization, and complex “two-stage” query filtering to combine keyword and vector searches. The team also needs a path to scale beyond 1 billion vectors without sacrificing latency and high read/write throughput.
Solution: To resolve these inefficiencies, Inspira consolidated their entire stack intoSpanner, drastically simplifying a 4.5 TB data pipeline into a unified, high-performance single-source of truth. Leveraging Spanner’s native support for both FTS and vector search, Inspira enabled single-stage filtering for hybrid queries and achieved high-precision snippets for LLM-based legal analysis with RAG workflow.

4. Autonomous network operations

Autonomous network operations (ANO) represents the transition from reactive maintenance to predictive, self-healing networks. By creating a comprehensive digital twin of the network topology and overlaying it with real-time operational data, telecommunications providers can automate root cause analysis, predict anomalies, and resolve network incidents without human intervention.

MasOrange: The digital twin

A temporal digital twin is at the heart of MasOrange’s ANO efforts, replicating its country-wide wireless network topology, alongside operations support systems (OSS), and business support systems (BSS) data.

Challenge: MasOrange needed a graph database that was highly available, infinitely scalable with zero RPO/RTO to serve as the foundation of its ANO stack. They required vector, and FTS capabilities without the operational overhead of managing multiple disparate solutions.
Solution: MasOrange chose Spanner for its ability to meet strict scalability and availability requirements while offering fully interoperable Graph, vector and FTS capability. Today MasOrange’s digital twin is live on Spanner, powering end-to-end anomaly detection and root cause analysis.

Looking Ahead

With the scale insurance, high reliability, global consistency, and versatility in handling different data models interoperably, Spanner is a future-proof database for your agentic workload.

We envision a future where the database becomes a simple implementation detail, allowing you to focus purely on accelerating developer productivity, improving operational efficiency and delivering your business goals. Visit our Spanner page to learn more and get started today.

Databases

AI Studio unlocks full-stack vibe coding with Cloud Run, Firebase, and Cloud SQL, no credit card required

An easy on-ramp: The Google Cloud Starter Tier

Powering full-stack vibe coding with Cloud SQL

Full-stack vibe coding with Firestore and Firebase Auth

Getting started in AI Studio

Urban Outfitters achieves major cost savings by moving Sterling OMS to AlloyDB for PostgreSQL

The solution: AlloyDB for PostgreSQL

A transformative shift

A blueprint for success: Planning and testing

Learn more:

What’s new with Google Data Cloud

May 11 - May 15

April 20 - April 24

April 13 - April 17

April 6 - April 10

March 23 - March 27

March 16 - March 20

February 23 - February 27

February 16 - February 20

February 2 - February 6

January 26 - January 30

January 19 - January 23

January 12 - January 16

What’s new with Google Data Cloud - 2025

The power of LLMs on your data, more than two orders of magnitude faster and cheaper

Why Proxy Models Work Accurately at Ultra Low Latency and Cost?

How Proxy Models Work?

Revisiting when Proxy Models Work

Why isn’t Vector Search Enough?

Experimental Results

Conclusion

Meet the latest Database Center, now with Gemini-powered fleet intelligence

Gemini-powered enhancements

Other platform enhancements

What are Database Center customers saying

Get started with Database Center

Future-proof your data strategy: AlloyDB adds PostgreSQL 18 and new Extended Support

Maintain stability with Extended Support

Speed up development with PostgreSQL 18 on AlloyDB

Proven reliability: UKG modernizes the data foundation

Maximize performance with database-aware storage

Get started

New Bigtable in-memory tier for sub-millisecond read latency

The cache-miss nightmare: A familiar story

Enter Bigtable’s in-memory tier

A peek behind the curtain

The cache-miss nightmare, revisited

Get started with Bigtable Enterprise Plus

Learn more

Firestore at Next '26: Unlock agentic development, search and MongoDB compatibility

The case for Firestore

1. Accelerating application development through agentic AI integrations

2. Differentiated search and queries

3. Enhanced MongoDB compatibility and scalability

Get started on Firestore

UKG unlocks real-time workforce intelligence at scale with the Agentic Data Cloud

Unifying the systems behind the suite

Bringing people intelligence to intelligent people

Driving impact across every layer

Learn more

What’s new with Databases: Powering the agentic future

Embed AI into every layer of the data stack

Break down walled gardens with lakehouse integrations

Commitment to open data and multi-cloud flexibility

Get started today

Announcing Spanner Omni: Your infrastructure, Google’s innovation

Why Spanner Omni is a big deal

Introducing Spanner Omni

The tech behind Spanner Omni

Where you can get access

Converging operational and analytical data for AI transformation

Flexible, real-time data agents

Grounding agents in a unified governance foundation

Unified engines for deep reasoning

Built for performance at agent scale

What’s new in the Agentic Data Cloud: Powering the System of Action

Enabling agents with a universal context engine

Agentic-first practitioner experiences

A cross-cloud foundation built for agentic scale