Databases

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):

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

What’s new with Google Data Cloud

Thu, 02 Apr 2026 16:00:00 +0000

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.

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.

How ID.me Scaled to 160M Users While Reducing Operational Risk

Mon, 30 Mar 2026 16:00:00 +0000

Editor’s note: ID.me is transforming digital identity security, proving that establishing your identity can be easy. What's more, their platform has scaled to support 160 million members and can support up to 40,000 users per minute.To support services like tax filing that require massive scale and power real-time AI, the team migrated 50 terabytes of data from their legacy platform to Google Cloud, adopting a modern architecture on AlloyDB, Cloud SQL, and Vertex AI. This architecture resulted in faster development, more accurate fraud detection, and a 40% reduction in their data teams’ overall work completion time.

Phone, driver’s license, credit card – you probably don’t leave home without some form of ID. It proves who you are, and it works almost anywhere. But online, you’re made to prove your identity again and again, and create new logins for every new service or tool you use. At ID.me, we think people should be able to verify their identity once, securely, and bring that same credential everywhere they go online.

Our goal is to create the digital wallet for identity: a trusted sign-in that works across the public and private sectors. Today, we serve over 160 million members. As identity grows ever more essential to how we live and work, we’re scaling to make it as easy to prove who you are online as it is to flash your driver’s license in person.

But demand doesn’t wait

In the last few years, ID.me has gone from serving 50 million members to more than 160 million. We no longer track usage by the day, but instead monitor it moment-to-moment. At this stage, our platform is designed to support up to 40,000 members per minute. That kind of demand changes the equation. For ID.me members, access is everything. It’s not just about uptime; it’s about ensuring that when a member needs to prove who they are—whether for government benefits, healthcare, or exclusive offers—we verify them securely and instantly. As usage grew, we realized our infrastructure couldn’t scale the way we needed it to. We were reaching the limits of our architecture. So we made the decision to rebuild the ID.me data foundation on Google Cloud for our next phase of growth.

A new database for us and our 160 million closest friends

The first order of business was to select a database that could truly provide the massive scalability and reliability we needed. AlloyDB for PostgreSQL immediately stood out. It directly addressed the scaling bottlenecks and operational complexities we faced with our prior setup, allowing us to confidently handle our peak demands. This shift didn't just solve our technical hurdles; it dramatically improved our developer experience. Our teams now spend far less time on provisioning, maintenance, and patching, accelerating our development cycle from weeks to just days.

Over the last two years, we migrated more than 50 terabytes of data across 15 database instances to Google Cloud – with minimal downtime. We also introduced a two-tier architecture where Cloud SQL supports our smaller and more standard services, while AlloyDB runs heavier workforces that form the backbone of the ID.me platform. That way, we can move fast without sacrificing stability. It also frees up our teams to focus on the work that actually drives innovation, like making sure AI works for, not against, our identity efforts.

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

Training AI to fight . . . AI?

Of course, everyone is racing to use AI. At ID.me, it’s just as important to defend against its misuse. The threat landscape is evolving, especially as generative models get better at impersonating individuals and even creating synthetic identities. And since we’re in the business of verifying that people are who they say they are, that threat lands squarely on our doorstep.

One of the great things about AlloyDB is its ability to create multiple read pools. For us, those read pools have become data clean rooms that we can quickly share out with our data engineers and data scientists. Fraud analysts can go in, find what’s wrong, and either remediate or prevent it in real time.

Overall, AlloyDB AI has allowed us to scale our systems 10-20X of what we were able to handle – and with a decrease in price to boot. The impact of this is huge. ID.me has been recognized by the U.S. federal government for its role in preventing large-scale fraud within national systems. A crucial factor in this success was AlloyDB's built-in high availability and easy-to-scale read pools, which enabled the Internal Revenue Service (IRS)—the U.S. national taxing authority— to seamlessly process over 120,000 transactions per second during the last peak tax season without a blip. This effectively doubled their previous self-hosted PostgreSQL performance.

We’ve been playing with a lot of new capabilities, but the ones we’re most excited about are Gemini Enterprise and AlloyDB AI natural language as they represent a fundamental shift in how we build and interact with AI.

One login. Every system. Zero friction.

Our data teams are big fans of Google Cloud; it's made their work substantially easier. Since migrating, they can make changes much faster, leading to a 40% reduction in their overall work completion time. And across ID.me engineering teams, the developer experience has improved dramatically. Our teams can ship full product features in days instead of weeks, spending more time solving meaningful problems for our members.

We’ve been able to scale both our infrastructure and trust. With a platform that’s faster, smarter, and built to handle portable identity at massive scale, we’re one step closer to our goal: a secure, digital way to prove who you are, wherever you need it, that works everywhere you need it. You may never get asked security questions about your childhood pet again.

Learn more:

Learn more about the power of AlloyDB and AlloyDB AI.
Start your AlloyDB free trial today.
Learn how customers like Bayer and Character.ai are leveraging AlloyDB to transform their business.

Manhattan Associates powers over a billion daily API calls with Google Cloud databases

Thu, 26 Mar 2026 16:00:00 +0000

Editor’s note: Manhattan Associates, a global leader in supply chain and omnichannel commerce solutions, modernized its Manhattan Active SaaS platform by moving from legacy Oracle and DB2 systems to Google Cloud databases. With Cloud SQL and BigQuery, the company now processes over a billion API calls per day with average response times under 150 milliseconds, supporting hundreds of thousands of monthly active users across tens of thousands of stores and distribution centers.

From monolithic roots to cloud resilience

Our Manhattan Active SaaS platform supports global supply chains, requiring constant uptime and performance. Our legacy Oracle and DB2 infrastructure created operational drag through manual scaling, complex licensing, and high maintenance overhead. We needed a new database foundation that provided contractual SLAs for availability, automated resilience, and a predictable cost model.

We chose Google Cloud databases because they give us the right balance of flexibility, scalability, and operational simplicity needed to run Manhattan Active at global scale. With managed databases like Google Cloud SQL, we traded manual upkeep for built-in high availability, scalability, and cross-region disaster recovery.

Each capability of Manhattan Active now runs as an independent, containerized service orchestrated by Google Kubernetes Engine (GKE). Data streams through Pub/Sub into BigQuery for real-time analytics, while Cloud Logging and Cloud Monitoring deliver observability at scale. This microservices-first design, powered by Google Cloud’s managed services, gave us the agility to evolve faster and the confidence that mission-critical operations would remain resilient across regions.

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

Building resilience and speed into every transaction

With a new foundation on Google Cloud, we could rethink how our platform delivers value at scale. The Manhattan Active architecture works alongside managed databases to turn supply chain complexity into responsive, resilient systems.

The benefits show up across the platform. Cloud SQL powers the core of Manhattan Active, quickly and reliably running millions of supply chain transactions per day. Real-time analytics flow into BigQuery, giving retailers sharper forecasting and faster anomaly detection. Automated failover and cross-region replicas safeguard business continuity, so critical services stay available even when disruptions hit.

A modernized foundation: From database to intelligence

The move from legacy Oracle and DB2 systems to Google Cloud databases solved more than just a performance issue; it gave us a resilient foundation for what came next. That reliability and scale let Manhattan Associates bring generative AI directly into the supply chain.

Our Agentic AI suite includes prebuilt agents — like the Intelligent Store Manager and Labor Optimizer — that coordinate real-time decisions across store and distribution center operations. The Manhattan Agent Foundry also lets customers build custom AI agents using a low-code environment. That same foundation powers internal efficiency too, with use cases like real-time log analysis, developer code assistance, and scenario simulations.

Unprecedented speed, scale, and operational efficiency in practice

For retailers, the impact of this platform modernization is immediate: tangible speed and reliability.

With the help of Cloud SQL and BigQuery, Manhattan Active now supports an astounding number of API calls per day, with an average response time under 150 milliseconds. This speed supports hundreds of thousands of monthly active users across tens of thousands of stores and distribution centers, enabling real-time decision-making where it matters most.

Operationally, the platform has become more elastic and efficient. The system automatically handles hundreds of thousands of scaling events per day, ensuring performance remains consistent during peak surges without expensive overprovisioning. Database observability tools like query insights give engineers clear visibility, so we spend less time on database patching and reactive troubleshooting and more on feature development and performance tuning.

For Manhattan Associates, resilience is now a built-in capability. And for retailers depending on our software, that translates into supply chains that are smarter, faster, and ready for whatever comes next.

Learn more

Discover how Cloud SQL can transform your business! Start a free trial today!
Download this IDC report to learn how migrating to Cloud SQL can lower costs, boost agility, and speed up deployments.
Learn how Ford and Yahoo gained high performance and cut costs by modernizing with Cloud SQL.

Streamline read scalability with Cloud SQL autoscaling read pools

Wed, 18 Mar 2026 16:00:00 +0000

A common pattern for applications that read frequently from a database is to offload read-heavy workloads to a read replica. This allows applications to scale without impacting critical write operations on the primary database instance. However, these read-heavy workloads can easily exceed the capacity of a single read replica. While developers can manually implement multiple replicas behind a load balancer, this approach is complex and difficult to maintain and scale.

Cloud SQL provides a simplified, fully managed solution to scale your reads using read pools for MySQL and PostgreSQL. This feature allows you to provision multiple read replicas that are accessible via a single read endpoint, so you can easily add and remove read replicas without having to make any application changes. To further improve efficiency, we recently introduced autoscaling for Cloud SQL read pools, which dynamically adjusts your read capability based on real-time application needs. Read pools with autoscaling are now generally available under Cloud SQL Enterprise Plus edition. You can find more details in the MySQL and PostgreSQL documentation, as well as the release notes.

Why read pools?

When you create a read pool replicating from a primary instance, Cloud SQL automatically provisions multiple read replicas, referred to as read pool nodes, and creates a single load balancer (called the read endpoint) that dispatches queries to the nodes round-robin. A pool can contain anywhere from 1 to 20 nodes.

A read pool is managed as a single entity to reduce your operational burden. The pool represents a homogeneous set of nodes; whenever you make any configuration change such as updating database flags, the VM type, or other parameters, the change is automatically applied to all nodes in the pool. You can also scale out and in by adding or removing nodes from the pool at any time in response to changes in the workload. Since all queries flow through the read endpoint's load balancer, you don’t need to reconfigure your applications, even as the nodes in the pool are being updated, added, or removed.

Easier scaling with read pool autoscaling

Read pools truly shine in scenarios with variable workloads. With the general availability of autoscaling for Cloud SQL read pools, managing these fluctuations is even easier.

Key benefits of read pool autoscaling:

Manage traffic spikes automatically: Maintain application responsiveness during peak demand as the pool dynamically scales up to 20 nodes based on database connections or CPU usage.
Simplify operations: Because autoscaling is integrated with a single read endpoint, your applications stay connected to the same address even as underlying nodes are adjusted.
Optimize costs: Pay only for the resources you actually use by automatically scaling in during low-traffic periods, preventing the expense of over-provisioning.

How Cloud SQL improves availability with read pools

Engineered for mission-critical reliability, Cloud SQL read pools provide the foundation for your high-availability read workloads. By maintaining at least two nodes, your read pool is backed by a 99.99% availability SLA, which includes coverage for maintenance downtime. To do this, Cloud SQL intelligently manages your environment in the following ways:

When you add nodes to a read pool, existing connections continue without interruption on the preexisting nodes. New connections may be directed to the newly added nodes and the load shifts to be evenly balanced across the nodes as pre-existing connections finish their work.
For read pools containing two or more nodes, when you modify the VM type or database flags, or perform most other configuration updates, the read pool is updated with near-zero downtime.
As for any other Cloud SQL instance, Cloud SQL automatically detects and repairs issues with the underlying hardware for your read pool instances. Whenever a node is found to be unhealthy, it is removed from the load balancer rotation and a new node is created to replace it.

Enabling and using read pools with autoscaling

Read pools excel in environments with highly variable workloads. With Cloud SQL autoscaling, you can define minimum and maximum node counts while setting targets for key metrics like CPU utilization or database connections.

Retail is a prime example. Traffic often fluctuates based on daily cycles, seasonal shifts, or flash sales. By dynamically scaling out to meet these peaks and scaling once demand subsides, you provide a strong customer experience without the overhead of an over-provisioned environment.

If you've already created an Enterprise Plus edition instance, you can create a read pool that replicates from it. The following command creates a read pool with two nodes and enables autoscaling, configured to scale between 2 and 10 nodes based on keeping CPU utilization around 60%:

code_block: <ListValue: [StructValue([('code', 'gcloud sql instances create myautoscaledreadpool \\\r\n --tier=db-perf-optimized-N-4 --edition=ENTERPRISE_PLUS \\\r\n --instance-type=READ_POOL_INSTANCE \\\r\n --master-instance-name=myprimary \\\r\n --region=us-west1 \\\r\n --node-count=2 \\\r\n --auto-scale-enabled \\\r\n --auto-scale-min-node-count=2 \\\r\n --auto-scale-max-node-count=10 \\\r\n --auto-scale-target-metrics=AVERAGE_CPU_UTILIZATION=0.60'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679e5c1b50>)])]>

You can obtain the read endpoint's IP address by inspecting the instance in Google Cloud console or using the gcloud CLI. This IP address doesn't change for the lifetime of the pool.

If you have an existing read pool, you can easily enable autoscaling on it:

code_block: <ListValue: [StructValue([('code', 'gcloud sql instances patch myreadpool \\\r\n --auto-scale-enabled \\\r\n --auto-scale-min-node-count=2 \\\r\n --auto-scale-max-node-count=10 \\\r\n --auto-scale-target-metrics=AVERAGE_DB_CONNECTIONS=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679e5c1fa0>)])]>

This command configures myreadpool to automatically scale between two and 10 nodes, targeting a maximum of 100 database connections per node on average.

While autoscaling is recommended for most variable workloads, you can still manually scale your read pool if needed by updating the node count directly:

code_block: <ListValue: [StructValue([('code', '# Manually scale out to 4 nodes\r\ngcloud sql instances patch myreadpool --node-count=4\r\n\r\n# Manually scale back in to 2 nodes\r\ngcloud sql instances patch myreadpool --node-count=2'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679e5c1df0>)])]>

Get started today

By using read pools with new autoscaling capabilities, you can avoid the tedious tasks associated with managing a large set of read replicas, and give your applications the read capacity they need, when they need it, without overspending. To get started today, please refer to the following resources:

Cloud SQL documentation for read pools
- About read pools (MySQL, PostgreSQL)
- Creating and managing read pools (MySQL, PostgreSQL): includes example commands for gcloud CLI, Terraform, and REST API
- Read pool autoscaling (MySQL, PostgreSQL): includes example commands for gcloud CLI, Terraform, and REST API
Sign up for the new Cloud SQL free trial, a dedicated 30-day program designed to give both new and existing Google Cloud users hands-on access to premium, enterprise-grade features of Cloud SQL (PostgreSQL and MySQL).

Next-gen caching with Memorystore for Valkey 9.0, now GA

Wed, 18 Mar 2026 16:00:00 +0000

Backend developers and architects building high-throughput, low-latency applications increasingly rely on Valkey, an open-source, high-performance key-value datastore that supports a variety of workloads such as caching and message queues. At Google Cloud, we offer a fully managed version as part of Google Cloud Memorystore, and today, we’re excited to announce the general availability (GA) of Valkey 9.0, delivering both massive performance gains and powerful new developer capabilities.

During the preview, we saw remarkable uptake and excitement from customers who require the highest levels of performance. Organizations pushing the boundaries of scale and latency are putting Valkey 9.0 to the test for their most demanding workloads:

"A high-performance caching layer is critical to our infrastructure at Snap. We are excited to see the General Availability of Valkey 9.0 on Google Cloud Memorystore. The new architectural enhancements, including SIMD optimizations, offer strong performance benefits for throughput and latency. Having access to a managed service backed by an open standard gives us valuable flexibility in how we deploy and manage our caching workloads." - Ovais Khan, Principal Software Engineer, Snap

This need for uncompromising speed and flexibility extends beyond social networking infrastructure into the financial sector, where real-time transaction processing and reliability are non-negotiable.

"In the financial services sector, milliseconds matter and data reliability is paramount. By utilizing Memorystore for Valkey on Google Cloud in the critical GPay stack powering the UPI Acquirer Switch for Top Indian Banks, Juspay is proud to leverage Memorystore to handle high-throughput transactional data with exceptionally low latency.

We are excited about the GA release of Valkey 9.0. The performance gains from features like pipeline memory prefetching, combined with the assurance of a fully managed, truly open-source solution, provide us with the scale and reliability necessary to securely serve all our customers." - Arun Ramprasadh, Head of UPI, Juspay

Similarly, in the media and entertainment space, delivering uninterrupted experiences to massive audiences requires a caching layer capable of instantly absorbing traffic spikes.

"During the preview of Valkey 9.0 on Google Cloud Memorystore, we've experienced amazing performance and stability. Live streaming demands absolutely minimal latency and maximum throughput. The architectural enhancements in Valkey 9.0 allow us to scale our caching layer more efficiently to handle traffic spikes during major events. Relying on a fully managed, open-source solution ensures Fubo can deliver a seamless viewing experience to our audience." - Kevin Anthony, Platform Engineering Manager, Fubo

Performance at scale: Speed without compromise

Valkey 9.0 is engineered for raw speed. By building upon the enhanced IO threading architecture introduced in Valkey 8.0, Valkey can handle significantly higher throughput and reduced latency on multi-core VMs. The performance gains are driven by several architectural enhancements as highlighted in the official Valkey 9.0 release announcement on the Valkey blog:

Pipeline memory prefetching: This optimization increases throughput by up to 40% by improving memory access efficiency during pipelining.
Zero copy responses: For large requests, this feature avoids internal memory copying, yielding up to 20% higher throughput.
SIMD optimizations: By utilizing SIMD for BITCOUNT and HyperLogLog operations, Valkey 9.0 delivers up to 200% higher throughput for these common tasks.

(Note: The figures above are based on open-source benchmarks; actual performance improvements will vary depending on your specific workloads.)

The mechanics of throughput: Pipelining

In Valkey, latency is largely constrained by network round-trip-time (RTT). If an application waits for each response before initiating the next request, total throughput remains bound by this round-trip latency. Pipelining addresses this by disaggregating latency and throughput, allowing multiple requests to be sent over a single connection without awaiting immediate responses.

Most Valkey clients offer native support for pipelining, with some like valkey-go providing “auto-pipelining” capabilities that handle this optimization transparently for developers.

Valkey 8.0 unlocked significant performance leaps with background thread memory prefetching. This architectural optimization provides a hint to the hardware to move data from DRAM into CPU caches before the main thread requires it. While this allowed the main thread to execute operations with minimal delay, it was limited; in pipelined traffic, only the initial operation benefited from prefetching, leaving subsequent requests bottlenecked by CPU cache misses.

Building on this foundation, Valkey 9.0 re-architects command processing to specifically optimize for pipelined workloads. Rather than prefetching keys solely for the first operation, Valkey 9.0 prefetches all operations within a pipeline simultaneously.

While seemingly incremental, the impact is profound, given that CPU caches are typically dozens of times faster than DRAM access. By maximizing CPU cache hits on the main thread, Valkey 9.0 delivers up to 40% higher overall throughput.

New capabilities for modern developers

Beyond raw performance, Valkey 9.0 addresses top feature requests from the community with powerful new commands that simplify application logic and data management.

Granular hash field expiration

A frequent request for in-memory stores is the ability to expire individual fields within a hash rather than the entire key. Valkey 9.0 introduces this capability, allowing for much more flexible data lifecycle management.

Real-world example: Imagine managing a "User Session" hash where you store authentication tokens, temporary preferences, and long-term settings. With HEXPIRE, you can set a 30-minute expiration on a temporary_session_token field while keeping the rest of the user's profile data intact. This eliminates the need to break a single logical object into multiple keys just to handle different Time-To-Lives (TTLs).
New commands: This release adds full support for HEXPIRE, HEXPIREAT, HEXPIRETIME, HPERSIST, HTTL, and more.

Advanced geospatial and conditional logic

Polygon search for geospatial indices: You can now query location data by a specified polygon. For instance, a logistics application can define precise, non-circular delivery zones — like a specific neighborhood or industrial park — and query for all active assets currently within those exact boundaries.

To use this capability, simply add your coordinates to a geospatial index:

code_block: <ListValue: [StructValue([('code', '> GEOADD gcp:regions -121.1851 45.5946 "us-west1 (Oregon)" -118.2437 34.0522 "us-west2 (Los Angeles)" -111.8910 40.7608 "us-west3 (Salt Lake City)" -115.1398 36.1699 "us-west4 (Las Vegas)" -95.8608 41.2619 "us-central1 (Iowa)" -77.4874 39.0438 "us-east4 (N. Virginia)"\r\n\r\n(integer) 6'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6794392cd0>)])]>

Then use GEOSEARCH with the BYPOLYGON option:

code_block: <ListValue: [StructValue([('code', '> GEOSEARCH gcp:regions BYPOLYGON 5 -125.00 49.00 -125.00 32.00 -114.00 32.00 -109.00 42.00 -116.00 49.00\r\n\r\n1) "us-west2 (Los Angeles)"\r\n2) "us-west4 (Las Vegas)"\r\n3) "us-west3 (Salt Lake City)"\r\n4) "us-west1 (Oregon)"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6794392e80>)])]>

Conditional delete (DELIFEQ): This command deletes a key only if its current value matches a specified value. This is a game-changer for distributed locking. Now, a worker can safely release a lock only if it still holds the unique token it originally used to acquire it, ensuring it doesn't accidentally delete a lock that has already expired and been re-assigned to another process. Previously, this kind of operation was only possible using Lua scripting.

To understand the usefulness of DELIFEQ, suppose two processes (Process A and Process B) need exclusive access to the lock.

Process A executes the following to acquire the distributed lock for 30 seconds:

code_block: <ListValue: [StructValue([('code', '>SET distributed_lock process_A NX PX 30000\r\nOK'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f67943926d0>)])]>

If Process B attempts to do the same, it won’t succeed due to the NX option:

code_block: <ListValue: [StructValue([('code', '> SET distributed_lock process_B NX PX 30000\r\n(nil)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6794392d00>)])]>

When Process A finishes, it can safely remove the lock with the new DELIFEQ command:

code_block: <ListValue: [StructValue([('code', '> DELIFEQ distributed_lock process_A\r\n(integer) 1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6794392dc0>)])]>

Now, Process B is free to acquire the lock:

code_block: <ListValue: [StructValue([('code', '> SET distributed_lock process_B NX PX 30000\r\nOK'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6794392670>)])]>

Enhanced visibility and debugging

The CLIENT LIST command now supports robust filtering options. Platform engineers can now quickly isolate clients by flags, name, library version, or even specific databases. This makes it significantly easier to identify and troubleshoot legacy clients or specific application instances that may be causing performance bottlenecks in a complex microservices environment.

New filtering option	Description
NAME <name>, NOT-NAME <name>	Include or exclude clients by their specified name.
IDLE <seconds>	Include only clients that have been idle for over a number of seconds.
FLAGS <flags>, NOT-FLAGS <flags>	Include or exclude clients based on various flags (e.g., whether they are primary or replica connections).
LIB-NAME <name>, LIB-VER <version>, NOT-LIB-NAME <name>, NOT-LIB-VER <version>	Include or exclude clients based on their provided library version or name (e.g., only valkey-py version 6).
DB <db>, NOT-DB <db>	Include or exclude clients based on their current selected DB.
CAPA <flags>, NOT-CAPA <flags>	Include or exclude clients based on their declared capabilities (e.g., whether they support redirection or not).
IP <ip>, NOT-IP <ip>	Include or exclude clients based on their IP address.
NOT-ID <id>, NOT-TYPE <type>, NOT-ADDR <address>, NOT-LADDR <local address>, NOT-USER <username>	Many existing filters now support an inverse option.

The extended CLIENT LIST capabilities are available in Memorystore for Valkey out of the box.

Enterprise-ready features

With this release, we are also introducing the clustered databases configuration, which facilitates complex use cases like blue-green caching patterns. This allows multiple services to utilize numbered databases to efficiently partition data and maintain logical namespace separation. You can now configure up to 100 numeric databases for namespacing your keyspace even when in cluster mode.

Configuration example: When creating your instance via the Google Cloud CLI, you can specify the number of databases:

code_block: <ListValue: [StructValue([('code', 'gloud memorystore instances create my-valkey-instance \\\r\n--engine-version=VALKEY_9_0 \\\r\n--replica-count=1 \\\r\n--shard-count 10 \\\r\n--engine-configs=cluster-databases=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6794392af0>)])]>

The clustered databases configuration lets you efficiently partition data across various services or environments within a single, scalable clustered instance. This provides the logical organizational benefits of multiple databases while leveraging the massive scale of a cluster. For many customers currently constrained by legacy non-clustered Redis instances, this capability removes the friction of complex application re-architecting, making it easier to modernize workloads that rely on multi-database structures.

Seamless upgrades

Existing Memorystore for Valkey customers can take advantage of these new features immediately through a simple, no-downtime, in-place upgrade path. As of today, Valkey 9.0 is available for both cluster-enabled and cluster-disabled instances, ensuring a smooth transition to the latest engine.

Looking ahead

The general availability of Valkey 9.0 represents a significant milestone in the evolution of open source databases. But we’re just getting started. We’re already hard at work engineering the next wave of innovation and will be unveiling even more enhancements for the Valkey ecosystem at Google Cloud Next 2026.

Ready to build?

The best way to experience the power of Memorystore for Valkey 9.0 is to try it out. Get started with the documentation or deploy your first Valkey instance. Don't let having to self-manage Redis hold you back. Experience the simplicity and speed of Memorystore for Valkey today and see how it can power your applications, so you can focus on what matters: innovating and creating impactful applications for your business!

PayPal's historically large data migration is the foundation for its gen AI innovation

Thu, 26 Feb 2026 17:00:00 +0000

With the dawn of the gen AI era, businesses are facing unprecedented opportunities for transformative products, demanding a strategic shift in their technology infrastructure. A few years ago, PayPal, a digital-native company serving hundreds of millions of customers, faced a significant challenge. After 25 years of success in expanding services and capabilities, we’d created complexity in our data analytics infrastructure. Some 400 petabytes of data was spread across a dozen siloed systems due to limitations of scale and acquisitions of companies like Venmo, Braintree, and others.

Our very success in growth and innovation had created complexity that threatened our next evolution.

To continue leading the next wave of innovation in financial services, we knew we had to modernize our data foundation. Today, we’re proud to share how PayPal successfully completed what’s arguably one of the largest data migrations in history, culminating with the move of our analytics to BigQuery, Google Cloud’s enterprise data warehouse. This effort marks a significant leap in creating the robust data framework we’ll need to expand and advance our business priorities and meet the ever-evolving financial needs of our customers.

This migration was essential, but the scale was daunting. In fact, by some measures, such as our now sunset Teradata system, we believe this was one of the biggest data migrations in history. Befitting of such history, we wanted to offer some insights into how we tackled this migration and what others might consider when undertaking a significant migration of their own.

Untapped potential of data

As one of the original digital payment pioneers, PayPal processes billions of transactions, and houses decades of valuable customer insights. We have a mountain of data — really a mountain range — that had developed over decades without being fully leveraged in the service of our customers and merchants.

Each acquisition and new service added valuable capabilities but also introduced new data challenges. For example, a small business owner might use PayPal for online sales and Venmo for local transactions. However, providing a unified view of their business required complex processes that were costly and slow.

The fragmentation of data limited our ability to offer personalized experiences to consumers, thereby reducing the potential to maximize the value of their money and hindering our ability to gain deeper insights from the data.

As the gen AI era dawned, our digital fragmentation was becoming more than just a technical inconvenience. With AI becoming a transformative force in financial services with huge potential ROI, we knew fragmented data would severely limit our ability to create the intelligent experiences customers have come to expect. These could run from further strengthening our industry-leading fraud detection models to providing a best-in-class commerce platform for merchants to help them succeed in the competitive global economy.

To get there, we had to get our disparate data platforms in order, first.

Legacy systems, modern ambitions

The scope was massive. We needed to consolidate multiple data platforms, including what’s believed to be the world’s largest Teradata deployment, along with Hadoop clusters, Redshift, Snowflake, and various other systems processing petabytes of transaction data. This migration also had to be executed while maintaining the uninterrupted security and reliability our customers depend on.

As a technology company, PayPal has considerable internal resources, so we first had to decide whether to tackle this challenge ourselves. We weighed the costs and benefits and decided that if we were to unify and scale our on-premise infrastructure to meet our future needs, the cost and time-to-complete would have been prohibitive. Plus, the innovations in AI were happening at a rapid pace in the cloud. To truly leverage the power of our data, we needed to be where that innovation is happening.

We assessed various data warehousing solutions and chose BigQuery due to its numerous advantages. It is a fully managed, cloud native platform with disaggregated compute and storage that can scale independently. It has powerful capabilities at the scale and performance we needed, and a familiar SQL interface meant a gentler learning curve for our developer community.

Most importantly, BigQuery’s native integrations with AI enable seamless and efficient data analytics.

The journey to unified data

After choosing Google Cloud as our data partner, we embarked on our historic data migration. This may sound hyperbolic, but when you consider the scale of PayPal’s business, the geographies across which we operate, the regulations within each, the sensitive and quite literally valuable nature of this data, the scope of the challenge starts to be clear.

With the help of partners and experts from Google Cloud Consulting, we migrated more than 300 petabytes of data and streamlined operations, decommissioning around 25% of workloads. And we managed this all while maintaining zero downtime of our business operations and with no impact to customers. Here are some key factors that contributed to our success.

Alignment: The first hurdle in achieving transformations at scale is aligning stakeholders on a shared goal. So, we made it an enterprise-wide priority.

Discovery and analysis: Detailed inventories of data, workloads and inbound/outbound data streams is crucial for defining scope, effort and forecasting budget. Establishing lineage allowed us to trace the origins and relationships of various components, thereby providing a clear and comprehensive view of the dependency graphs.

Strategy: It is crucial to establish fundamental principles for the migration process, such as deciding between lift-and-shift versus modernization, defining security principles, setting governance guardrails, and determining how consumption will be tracked.

Execution: We automated every possible task and developed live dashboards to continuously monitor the progress of migrations. FinOps was integrated through the migration process with clear visibility of consumption and performance.

Benefits from BigQuery and beyond

We’ve achieve faster insights. Queries are 2.5x to 10x faster, including complex queries used by data scientists. This unlocks real-time insights, enabling PayPal to personalize product recommendations, offers, and customer support.

We’ve built new AI foundations. Data accessible for model training is 16x fresher. Feature engineering, a crucial step in AI development, is improved by instant access to clean, governed data. This accelerates the development personalized financial guidance, and predictive analytics for both consumers and businesses.

We’ve optimized operations. By migrating to BigQuery Data infrastructure vendors were reduced from four to one, streamlining operations and reducing complexity. Data duplication between platforms was entirely eliminated.

Our new unified data platform in BigQuery has become the source for PayPal's next wave of innovation, enabling us to create more intuitive, personalized experiences across our entire ecosystem and to leverage the power of gen AI.

AI-powered innovation unleashed

Looking ahead, we're exploring how this unified data platform will enable us to deliver AI-powered experiences that weren't possible before, including:

Predictive fraud prevention that spots potential issues before they affect our customers.
Personalized financial insights that help merchants optimize their businesses.
Seamless payment experiences that adapt to each customer's preferences and patterns.
More intelligent risk assessment that could help expand financial access to underserved communities.

Agentic commerce and future possibilities we are now able to imagine.

Lessons for the AI era

While our migration may be extraordinary in its scale, we are not alone in our needs or ambitions. There are ample considerations for companies within and well beyond financial services who may be pondering their own data foundations at this time.

First off, do not underestimate how under-utilized your data may be, and how unorganized.

Making sure your data is centralized, accurate, and consistent paves the way for AI experimentation and deployment. Organizations that spend time cleaning up their data fabric will be able to bring machine learning and generative AI applications to market more quickly, and do so at scale.

Second, ensuring data is accessible to everyone within your organization, with the proper controls, unlocks so much potential. Data orchestration and enterprise search, coupled with generative AI, has the potential to break down longstanding organizational silos and speed up decision-making across your organization. It’s one of the most promising applications of AI.

The financial world will continue to evolve, driven by new technologies and changing customer expectations. PayPal’s data transformation shows how even established companies can reinvent themselves to stay ahead of this change — provided they're willing to tackle the fundamental challenges that stand in their way.

In doing so, we've not only preserved our position as a digital payments pioneer but set ourselves up to continue leading the next wave of innovation in digital commerce.

Serving data from Iceberg lakehouses fast and fresh with Spanner columnar engine

Thu, 26 Feb 2026 17:00:00 +0000

The divide between data in operational databases and analytical data lakehouses is disappearing fast. As businesses increasingly adopt zero ETL lakehouse architectures, the challenge shifts from simply storing data in an open data format such as Apache Iceberg to serving it with the low-latency performance and speed that modern applications and AI agents require. Whether it’s a cybersecurity provider like Palo Alto Networks requiring real-time threat detection insights, or a telecommunications giant like Vodafone looking to reimagine data workflows for better customer experiences, organizations need to serve precomputed insights and AI models at scale.

To help, today, we are excited to announce the preview of the Spanner columnar engine, which allows you to serve your Iceberg lakehouse data with the scale and low latency of Google’s Spanner.

Uniting OLTP and analytics: The Spanner columnar engine

Traditionally, organizations had to choose between the high-performance transactional capabilities of an OLTP database and the analytical power of a columnar warehouse. Spanner’s columnar engine ends this trade-off by uniting these two worlds in a single, horizontally scalable system.

The columnar engine uses a specialized storage mechanism designed to accelerate 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. Most importantly, this performance boost can be isolated from critical transaction workloads, so that customer-facing applications remain responsive while you gain real-time insights from your operational datastore.

New features

Since we first announced Spanner columnar engine, we’ve added several new capabilities to accelerate performance and enhance usability. These include:

Vectorized execution: The engine supports faster columnar scans and aggregations using vectorized execution to process data more efficiently.
Automatic query handling: Spanner automatically redirects large-scan analytical queries to the columnar representation, speeding up analytical queries without affecting concurrent transactional workloads, allowing for true hybrid processing.
On-demand columnar data conversion: In addition to automated columnar data conversion, a new major compaction API helps accelerate the conversion of existing non-columnar data into the columnar format.

Why Iceberg data needs a fast, low-latency serving platform

Apache Iceberg has become the standard for open lakehouse architectures, providing a robust way to manage massive open format datasets in cloud-based storage. However, while lakehouses are excellent for large-scale analytics, they aren’t usually designed for the sub-second, high-concurrency "point lookups" or aggregated serving that live applications require.

This is where Spanner provides a unique value proposition. By moving curated, processed data from your lakehouse into Spanner — a process known as reverse ETL — you transform "cold" analytical data into "hot" operational data. Spanner provides the global consistency and high availability that applications require, making your Iceberg data accessible via low-latency APIs for real-time decision-making and agentic AI features.

Benchmarking Spanner columnar engine

To demonstrate Spanner’s new serving capabilities, we used a leading industry benchmark for web analytics and real-time dashboards — the exact scenarios where low-latency serving is critical.

Our benchmark results with a single Spanner node showcase the power of the columnar engine:

Benchmark query	Spanner columnar engine speedup
Simple count of all records	46.3×
Basic aggregation with filtering	32.7×
High selectivity scan	46.7×
Global aggregation	58.6×

These results represent the acceleration of real world workloads on Spanner columnar engine and show that Spanner can take complex, scan-heavy queries and return results in milliseconds, making it a great choice for powering real-time dashboards and user-facing features. Spanner is now a high-performance engine capable of delivering complex analytical results at the speeds required by modern digital experiences.

Universal reverse ETL: Serving data from all lakehouses

Spanner is designed to be the serving layer for your entire data ecosystem. Whether your lakehouse lives in BigQuery, Snowflake, Databricks, or Oracle, Spanner offers an integrated pathway for high-speed serving.

Through our latest reverse ETL workflows, you can easily bridge the gap between your analytical and operational worlds:

BigQuery: The tight integration between Spanner and BigQuery provides a powerful, bidirectional bridge for managing Iceberg data across both operational and analytical environments. You can perform federated queries on BigLake Iceberg and Spanner tables using BigQuery external datasets for Spanner, allowing for real-time analysis without moving data. When you need to serve curated BigQuery insights at scale, reverse ETL workflows can push data from BigQuery and BigLake Iceberg tables directly into Spanner. Furthermore, you can capture live operational changes in Spanner and stream them into BigQuery and BigLake Iceberg tables using Datastream, ensuring your lakehouse remains synchronized with your transactional data from Spanner for agentic AI and real-time decision-making.
Databricks: Using Databricks' Universal Format (UniForm), you can generate Iceberg metadata for your Delta Lake tables automatically. This allows Spanner to ingest your processed Databricks data via BigQuery or Dataflow, so that your "curated" datasets are ready to power applications with minimal engineering overhead.
Snowflake: You can export Iceberg tables to Google Cloud Storage and use BigQuery BigLake as a zero-copy intermediary to push that data directly into Spanner via EXPORT DATA commands. Alternatively, for simpler migrations, you can export Snowflake data as CSVs and use Dataflow templates for high-throughput ingestion into Spanner.
Oracle Autonomous AI Lakehouse: Oracle Goldengate 26ai now allows you to replicate your Oracle Autonomous AI Lakehouse data into Spanner to serve insights generated from Oracle’s data ecosystem with Spanner’s scale and consistency.

Get started today

It’s time to stop waiting for your lakehouse queries to finish and start serving your data hot, fresh, and fast with Google Spanner powered by Spanner columnar engine. The Spanner columnar engine is now in preview. You can enable it on your existing Spanner tables today with a simple DDL change.

You can see the performance acceleration of Spanner columnar engine by running the analytics benchmark queries on Spanner available on Github for yourself.

To help you get started, here are codelabs to build reverse ETL pipelines to Spanner from

Databricks:

and

Snowflake:

Decommission your legacy Apache Cassandra stack and build for the future with Spanner

Thu, 19 Feb 2026 17:00:00 +0000

An increasing number of customers are migrating to Spanner from legacy NoSQL environments like Apache Cassandra. The strategic drivers are evident: a markedly lower total cost of ownership (TCO), elastic scalability, and near-zero maintenance overhead.

With the general availability of the native endpoint enabling Cassandra Query Language (CQL) APIs on Spanner, your existing Cassandra applications can now leverage Spanner’s enterprise foundation, featuring strong consistency, virtually limitless scale, and 99.999% availability — all while utilizing familiar CQL.

Better yet, migrating your application to Spanner with the CQL interface typically requires only a one-line code change, as your existing CQL statements remain valid. Combined with our integrated, high performance bulk and live migration tools, your transition from Cassandra to Spanner is simple.

Beyond NoSQL: Strategic solutions for Cassandra Users

While the CQL API facilitates the move, Spanner addresses the fundamental data integrity and operational constraints inherent in traditional Cassandra architectures:

Global ACID transactions: Minimize concerns regarding eventual consistency. Achieve comprehensive global ACID transactions to help ensure data integrity at any scale.
Powerful indexing: Strongly consistent secondary indexes support complex query patterns with built-in optimization and no integrity risks.
Rich SQL: Utilize a sophisticated SQL interface that supports joins and aggregations.
High reliability: Benefit from 99.99% availability in regional setups and 99.999% in multi-regional configurations.
Compliance and latency: Simplify data residency compliance with geo-partitioning, delivering low-latency local reads and writes to a global user base.
Built-in observability: Access a suite of performance metrics and charts directly in the Google Cloud console at no additional cost.

The native CQL endpoint provides a clear pathway to decouple your existing Cassandra applications and modernize them using the full power of Spanner. Let’s look at the next steps after migrating your data and applications from Cassandra to Spanner.

Tweak Spanner for your specific workload

Following your migration, here’s how to optimize your Spanner environment for your workload.

1. Optimize costs and operational efficiency

Workload Characteristics	Recommended Solution	Primary Benefit
Write-intensive traffic	Throughput-optimized writes	Up to a 6x increase in write throughput via request bundling (with minimal latency impact).
Variable or fluctuating traffic	Autoscaler	Automatically aligns capacity with demand, eliminating over-provisioning costs.
Steady-state, baseline capacity	Committed use discounts (CUDs)	Secure up to 40% savings on steady-state operational costs.
Storage-intensive workloads	Tiered storage (HDD)	Utilize cost-effective HDD storage for a significant reduction in long-term storage expenses.

2. Achieve low latencies
We continuously enhance Spanner's performance to support mission-critical, high-concurrency workloads.

Single-digit millisecond performance: Spanner consistently delivers under 5ms latency for both read and write operations.
Repeatable read isolation: This feature utilizes optimistic concurrency to reduce latency and transaction aborts in read-heavy, low-contention scenarios.
Read leases: Enable strongly consistent reads in multi-region instances without cross-region coordination, maximizing node efficiency and performance.

3. Prepare for peak traffic surges
For planned events like marketing launches or massive data ingestions, you can proactively manage capacity:

Manual split APIs: While Spanner handles data partitioning automatically, the pre-splitting capability allows you to exactly define how your database distributes data ahead of peak loads. This helps ensure immediate utilization of new capacity for stable performance.

4. Isolate operational and analytical pipelines
Prevent resource contention by isolating BI and ETL processes from core operations:

Dedicated resources: Leverage read-only replicas and directed reads to achieve workload isolation.
Advanced analytics: Spanner provides high-performance operational analytics through its columnar engine, and integrates with BigQuery via Data Boost, reverse ETL, and continuous queries.

Deconstruct your Cassandra ecosystem

Migrating from Apache Cassandra to Spanner is a strategic opportunity to decouple your architecture from a complex web of sidecar utilities. While the Cassandra-compatible API serves as the entry point, the true value lies in collapsing the operational "Cassandra tax" into a unified, managed multi-model ecosystem.

Here’s a quick guide to drastically lowering your TCO while significantly boosting performance.

1. Transition easily via connectors

Minimize initial friction by leveraging the Spanner Cassandra Adapter and connectors to port management and application layers with near-zero code modifications:

Orchestration: Maintain your existing Airflow DAGs by redirecting to the Spanner proxy.
Application frameworks: Transition from Spring Data Cassandra to Spring Data Spanner, preserving established repository patterns while unlocking a superior transaction model.
Data processing: Continue leveraging Apache Spark by connecting to Spanner’s native CQL endpoint or using the specialized Spanner Connector for Spark.

2. Retire sidecars via native integrations

Cassandra demands a "babysitting" layer that Spanner automates. Decommission legacy maintenance tools and unlock Spanner’s advanced capabilities:

Anti-entropy: Decommission Cassandra Reaper. Spanner’s Paxos-based replication manages consistency natively, removing the need for manual repair cycles.
Data protection: Replace Medusa with Spanner-native backups. Move away from fragile SSTable snapshots to reliable, Point-in-Time Recovery (PITR).
Observability: Swap complex JMX exporters for Cloud Monitoring. Focus on high-value metrics like Query Insights and Lock Statistics rather than maintenance debt.
Integrated search: Replace external Elasticsearch sidecars and complex ETL pipelines with Spanner full-text search to eliminate indices-synchronization issues.
Modern streaming: Swap legacy CDC for Spanner change streams, providing native integration with Dataflow and Kafka.
Graph analytics: Port JanusGraph to Spanner Graph to run openCypher queries directly on operational data without complex ETL processes.
Query federation: Replace Trino/Presto with BigQuery Federation via Data Boost. Join real-time transactional data with massive data lakes without impacting production I/O.

Build the future with Spanner’s multi-model advantage

Spanner is the definitive always-on database that integrates relational, key-value, graph, search, and vector search capabilities into a single, interoperable platform. By transitioning to Spanner, you eliminate the overhead of managing fragmented databases and unlock the ability to develop innovative applications on a unified data foundation. Build new applications or modernize your legacy applications to take full advantage of Spanner.

Get started today

Ready to refocus on building rather than managing? Initiate your migration today and experience the power of Spanner with your existing Cassandra Query Language.

Codelab: Gain practical experience with the native CQL endpoint.
Free trial: Explore Spanner for 90 days or start for as little as $65/month for a production-ready instance that scales without disruption.
Migration guide: Access deep technical documentation and comprehensive migration resources.

Powering the next generation of agents with Google Cloud databases

Wed, 18 Feb 2026 18:00:00 +0000

For developers building AI applications, including custom agents and chatbots, the open-source Model Context Protocol (MCP) standard enables your innovations to access data and tools consistently and securely. At the end of 2025, we introduced managed and remote MCP support for services like Google Maps and BigQuery, establishing a standard method for AI to connect with tools, and effectively creating a universal interface for applications. Today, we are expanding this offering to include PostgreSQL with AlloyDB, Spanner and Cloud SQL, as well as Firestore and Bigtable for high-performance NoSQL workloads, and introducing a new Developer Knowledge MCP server, which presents an API to connect IDEs to Google’s documentation. These servers run in Google Cloud, providing a secure interface for Gemini and other MCP-compliant clients to easily interact with data and infrastructure.

With the launch of Gemini 3, developers gained advanced reasoning capabilities to plan, build, and solve complex problems. But for an AI model to function as a useful "agent," it must reliably interact with its environment. Today’s announcement extends these capabilities more broadly to the database tools our customers leverage daily as the backbone of their work environment.

To connect your agents to these servers, you don’t need to deploy infrastructure. Just configure the MCP server endpoint in the agent configuration and immediately gain access to your operational data, backed by enterprise-grade auditing, observability and governance. With no infrastructure management, you can scale your agentic workloads without incurring operational overhead.

Bringing operational data to agents

These new managed servers enable agents to access specific capabilities across our portfolio:

AlloyDB for PostgreSQL: Agents can interact with PostgreSQL workloads, enabling tasks such as schema creation, diagnosing complex queries for slowness and performing vector similarity search.
Spanner: With unified multi-model capabilities in Spanner such as Spanner Graph, agents can model and query complex relationships directly alongside relational and semantic data using standard (SQL and GQL) queries. This allows agents to quickly uncover deep insights (like identifying fraud rings or generating product recommendations) using the MCP tools at its disposal.
Cloud SQL for PostgreSQL, MySQL and SQL Server: Developers and database administrators can use the Cloud SQL MCP Server across MySQL, PostgreSQL, and SQL Server fleets for natural language interactions with the database, AI-assisted app development, query performance optimization and database troubleshooting via agents.
Bigtable: Bigtable’s flexible schema and high-throughput ingestion capabilities are commonly used for building digital integration hubs and managing time series data. MCP simplifies automating operational workflows and developing agentic customer support, CRM, human resources, IT operations, supply chain and logistics applications with this data.
Firestore: Focused on mobile and web development, the Firestore MCP server enables agents to sync with live document collections. This supports dynamic interactions such as checking user session states or verifying order statuses via natural language prompts.

Managing applications and infrastructure

Beyond data retrieval, we are enabling agents to help build and manage applications. The Developer Knowledge MCP server connects IDEs to Google’s documentation, allowing agents to answer technical questions and troubleshoot code with relevant context.

Security and governance

Connecting an agent to a database requires robust security and governance. These servers are built on Google Cloud's standard identity and observability frameworks:

Identity-first security: Authentication is handled entirely through Identity and Access Management (IAM) rather than shared keys. This ensures agents can only access the specific tables or views explicitly authorized by the user.
Full observability: To track agent activity, every query and action taken via these MCP servers is logged in Cloud Audit Logs. This provides security teams with a record of every database interaction, maintaining visibility alongside ease of access.

Demo: From local code to managed data

Let’s see these new MCP servers in action.

Imagine an agent designed to automate the migration of a full-stack event management platform for fitness communities. Through a series of natural language instructions in the Gemini CLI, the agent utilizes the Cloud SQL remote MCP server to provision a managed PostgreSQL instance, apply the correct schema, and securely migrate your local data. You don't need to master complex gcloud commands or become a Cloud SQL expert; the agent handles the heavy lifting. This transition is architected in real-time by the Developer Knowledge MCP server, which references official documentation to guide the agent through best practices — easily upgrading your application's backbone from local storage to a fully managed enterprise database.

Support for third-party agents

Because these servers follow the open MCP standard, they also work with your favorite AI agents. You can easily connect clients like Anthropic’s Claude by adding a Custom Connector in the settings. Simply point it to your Google Cloud database MCP endpoint, and you are ready to start building — no complex configuration files required.

What’s next

We’ll continue to expand this ecosystem in the coming months with managed MCP support for Looker, Database Migration Service (DMS), BigQuery Migration Service, Memorystore, Database Center, Pub/Sub, Kafka and more.

To start building secure, data-driven agents, explore our guides for AlloyDB, Spanner, Cloud SQL, Bigtable, and Firestore. You can also check out these codelabs for Cloud SQL and Spanner, along with this demo video walking through the app migration to Google Cloud.

Google (Spanner) Ranks #1 for Lightweight Transactions Use Case in Gartner® Critical Capabilities Report

Wed, 18 Feb 2026 17:00:00 +0000

For the second consecutive year Google (Spanner) has been recognized by Gartner in the Critical Capabilities for Cloud Database Management Systems for Operational Use Cases report, where it ranked #1 in the Lightweight Transactions Use Case. In our opinion, this is a testament to its efficiency, low latency, and high-performance consistency. It was also ranked #2 in the OLTP Transactions Use Case in the latest rankings. We feel this shows that its "infinite" horizontal scale doesn't come at the cost of traditional transactional performance. To us, this back-to-back recognition underscores a theme of sustained excellence and continuous innovation for the world’s most demanding data environments

Check out the full Gartner report.

A look at operational performance

Looking at the Critical Capabilities Ratings, we believe Spanner’s performance is why it continues to be recognized across a variety of categories:

#1 in Lightweight Transactions Use Case (second year in a row): As microservices and event-driven architectures become the norm, the ability to handle high-frequency, low-latency transactions is paramount. We feel Spanner’s #1 ranking shows it is the most efficient engine for these modern workloads.
Distributed Transactions Support (Score: 5.0/5.0): Spanner is the only service to receive a 5.0 for the ability to support distributed transactions across multiple nodes, regions and geographies.
AI/Machine Learning and GenAI (Score: 4.6/5.0): We believe this score is the result of the massive wave of innovation we undertook in 2025 to integrate AI directly into Spanner.
Transactional Consistency (Score: 4.9/5.0): Spanner offers external consistency at planet-scale, helping ensure that every transaction is globally accurate, every time.
#2 in OLTP Use Case: Spanner is increasingly being used for traditional, high-volume transactional workloads, thanks to, in our view, its "infinite" horizontal scale, which makes it a top-tier choice for legacy migrations.

These positionings, to us, signal that Spanner has evolved from a specialized solution for global scale into the most technically capable database suitable for nearly any mission-critical application.

The foundation for the agentic enterprise

In 2025, Spanner became the "brain" of AI agents, driven by a number of new capabilities:

Spanner Graph (now GA): A unified graph and relational experience. With Spanner Graph, you can traverse complex relationships using ISO-standard GQL alongside SQL. This is critical for building knowledge graphs that ground AI agents in real-world facts.
Integrated hybrid search: Generally available since 2025, Spanner supports high-scale full text and vector search directly within its SQL and Graph modalities, allowing for integrated, low-latency retrieval-augmented generation (RAG) at scale.
Spanner columnar engine: This architectural breakthrough enables analytical queries to run up to 200× faster on live operational data served from Iceberg tables, providing agents with the real-time context they need without the "ETL tax."
Expanded interoperability: With new Cassandra-compatible APIs, we've made it easier than ever to bring scale-out workloads to Spanner with zero code changes, so that your legacy data can participate in the AI revolution.

A blueprint for tomorrow

In our opinion, the Gartner recognition validates our belief that the future of data is unified, open, and inseparable from AI. Every day, we see customers leveraging Spanner’s recent innovations:

Palo Alto Networks: As a global cybersecurity leader, Palo Alto Networks relies on Spanner to be the heart of its multi-tenant architecture. By leveraging Spanner’s 99.999% availability and Spanner Graph, they have unlocked crucial access-control use cases at planet-scale. This integrated approach allows them to secure AI at scale, stitching together a cohesive architecture that manages critical customer workflows without the need for specialized graph database silos.
Mercado Libre: The Latin American e-commerce and fintech giant uses Spanner for its foundational consistency and scale. By integrating Spanner with their internal "Fury" platform, they manage millions of daily financial transactions with near-perfect uptime. They leverage Spanner data boost for real-time analytics without impacting transactional performance, and they are now using Spanner as the reliable memory store for their next generation of AI-driven financial agents.
Unico: This leading IDTech company prevents billions in fraud by facilitating over 1.2 billion digital identity authentications, since 2021. Spanner’s integrated vector search allows Unico to perform complex 1:N facial biometric searches across billions of vectors with high precision and low latency. This eliminates the need for a separate vector database, so that their "Identity Network" remains fast, accurate, and maintenance-free.

Ready to see why Spanner was recognized?

The future of data is unified and built for AI. By ranking #1 in Lightweight Transactions and we believe Spanner is the premier choice for your mission-critical applications.

Read the full 2025 Gartner® Magic Quadrant for Cloud DBMS.
Explore the 2025 Gartner Critical Capabilities for Operational Cloud DBMS.
Try Spanner for free and start building your AI-ready applications today.

_{Critical Capabilities for Cloud Database Management Systems for Operational Use Cases, By Ramke Ramakrishnan, Masud Miraz, Xingyu Gu, Henry Cook, Aaron Rosenbaum, November 19, 2025.}

_{GARTNER and MAGIC QUADRANT are registered trademarks and service marks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.}

_{Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.}

_{This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Google Cloud.}

Spanner in 2025: Innovations powering intelligent, multi-model AI applications

Wed, 28 Jan 2026 17:00:00 +0000

For over a decade now, Google has relied on Spanner, an always-on, virtually unlimited database to power global-scale applications like Gmail, YouTube, and Google Photos. Today, Spanner handles over 6 billion queries per second at peak and more than 17 exabytes of data, with five 9s of availability, plus global consistency.

2025 was a big year for Spanner on Google Cloud, too, where it powers demanding workloads for customers like Walmart, Goldman Sachs, Palo Alto Networks, Shopify, and MercadoLibre. At the same time, in an era defined by artificial intelligence, the role of databases is undergoing a profound transformation. The database is evolving beyond its traditional function as a passive data repository, emerging instead as an intelligent context hub. Spanner now powers key use cases like product search and recommendations, fraud detection, identity resolution, and autonomous network operations (ANO).

As we gear up for an exciting 2026, let’s take a minute to review some of last year’s highlights. In a nutshell, in 2025, we:

Made Spanner a first-class citizen for AI workloads
Bridged the gap between operational and analytical data
Made migrations simpler
Raised the bar on price performance, and
Enhanced enterprise safety and data protection

Let’s review!

Spanner AI with multi-model support

To build truly intelligent generative AI applications, you shouldn't have to glue together multiple point solutions. This is why in 2024, we integrated vectors, graphs, and relational data to provide context for your AI models. In 2025, we expanded these multi-model capabilities, adding new functionality across graph, vector, text search, as well as Vertex AI integrations.

AI capabilities: We introduced multiple capabilities to make Spanner an AI-first database. This includes built-in AI integrations such as ML.PREDICT for natural language queries, MCP Toolbox for Databases, Spanner extension for Gemini CLI, conversational data agents, and Agent Development Kit for Spanner, which together, empower developers to build sophisticated, agentic applications with Spanner. We also extended our multi-model platform to power advanced AI use cases, such as using graphs with vector search for GraphRAG use-cases. Finally, Vertex RAG Engine now lets you use Spanner as a RAG-managed database for data indexing and retrieval operations.
Graph enhancements: Spanner Graph added support for schemaless data that enables iterative development and frequent updates without requiring schema changes. You can also now build graphs on named schema objects and on SQL views, organizing and encapsulating important aspects of your app.
Full text search: The enhance_query option provides automatic synonym matching and spell correction for a number of functions, reducing the manual tuning needed to improve recall.
Approximate Nearest Neighbor (ANN): ANN with Google's ScaNN is a fast, scalable vector search technique optimized for efficiency in high-dimensional vector searches, crucial for AI recommendation systems, image search, and semantic search. In 2025, we announced the general availability of ANN search to enable developers to perform fast similarity searches on vector embeddings, powering generative AI applications where consistency at scale matters.

AI-powered operations

In 2025, we delivered multiple AI powered improvements that make it easier for developers to leverage Spanner for their applications:

Spanner index advisor: Index Advisor analyzes your query patterns and proactively suggests new indexes (or identifies unused ones) to optimize performance and cost.
Schema recommendations (Preview): An intelligent tool that scans your schema design for anti-patterns — like hotspot-prone primary keys — and suggests improvements before they become production issues.
Spanner CLI: The new command line interface, bundled directly with gcloud, allows you to run SQL, manage sessions, and automate scripts within existing developer workflows.

Unified analytics: Minimize silos and complexity

Last year, we bridged the gap between operational and analytic data with multiple new capabilities:

Spanner columnar engine (Preview): This engine automatically lets you analyze vast amounts of operational data in real time, while maintaining Spanner's global consistency, high availability, and strong transactional guarantees — without impacting transactional workloads. Verisoul.ai, a provider of an all-in-one platform to automate fake account detection used Spanner and Spanner columnar engine to support low-latency transactional writes and rich analytics to provide fast responses to their users.
The "Better with BigQuery" ecosystem: We strengthened the integrations between Spanner and BigQuery to bring operational and analytical engines together to provide real-time insights:

Apache Iceberg support: With this capability, data analysts can join live Spanner data with Apache Iceberg tables on BigQuery, as well as export Iceberg data into Spanner. This allows you to query and combine your real-time operational data (from Spanner) with your curated data lakehouse (in Iceberg).
Spanner external datasets materialized views: We announced the general availability of Spanner external datasets in BigQuery that enable BigQuery users to query live operational data in Spanner with zero ETL requirements. We further extended this capability to integrate with BigQuery materialized views for ultra-fast reporting using pre-computed query results.
Continuous queries with Reverse ETL (BigQuery to Spanner): You can now combine BigQuery’s continuous query capabilities with reverse ETL to Spanner to stream computed insights — such as fraud alerts or dynamic pricing signals — from BigQuery into Spanner in real-time, for low-latency serving of these insights. Fastweb+Vodafone was able to do just that by leveraging this feature to use Spanner as their real-time serving layer with BigQuery.

Simplified migration

Customers frequently migrate to Spanner to benefit from five nines of availability, virtually unlimited scale, low operational overhead, and global consistency. In 2025, we made it it easier for them to migrate their Cassandra, and MySQL workloads to Spanner:

Cassandra interface: Spanner’s Cassandra interface lets you take advantage of Spanner's fully managed, scalable, and highly available infrastructure using familiar Cassandra tools and syntax. Lift and shift existing CQL applications with virtually no changes.
MySQL interoperability: You can now install a library of 80 MySQL functions to help reduce the application changes required to migrate your MySQL workloads to Spanner.

Performance and cost improvements

Continuously raising the bar on price-performance is a north star for the Spanner team. In 2025, we introduced multiple capabilities to help you improve query performance and reduce costs:

Repeatable read isolation (Preview): This new isolation level reduces locking overhead to improve latency for workloads that have low read-write contention.
JSON indexing: Using the same foundation as Spanner’s full-text search, JSON indexing accelerates common queries over JSON, without having to predefine anything about the structure or data. This gives developers flexibility without having to compromise on performance.
Read leases: Read leases can improve read latency for strongly consistent data in multi-region configurations by trading off some write performance for common read-mostly workloads.
Tiered storage: Tiered storage allows you to manage data lifecycle costs efficiently by using SSD and HDD storage within the same instance, all via configuration and without having to modify the APIs you use to access the data. This functionality moves older data to lower cost HDD storage (~80% cheaper) while automatically keeping new data on high-performance SSDs.
Managed autoscaler: We announced the general availability of managed autoscaler and enhanced it to allow scaling read-only replicas independently from the read-write replicas, thereby improving read performance while optimizing costs based on traffic patterns.
Manual split points: While Spanner automates sharding to distribute work across nodes in an instance, sometimes you know your traffic patterns better than we do. The new split-point API allows you to “warm up” or pre-split your data to handle anticipated spikes, like a flash sale or game launch, to handle traffic immediately.
Query optimizer: The new default query optimizer (version 8, for those counting at home) brings a host of automated enhancements, optimizing join strategies and index usage to improve query performance and predictability.
Multiplexed sessions and lazy decoding: We enabled multiplexed sessions by default across major SDKs (Java, Go), significantly improving throughput and resource utilization. We also optimized our client libraries with lazy decoding for partitioned queries, allowing your applications to handle massive datasets with a significantly lower memory footprint. Plus, new built-in client metrics give you granular observability into your application's database performance.

Raising the bar on enterprise safety

For our customers, especially in industries like financial services, retail, and healthcare, reliability is non-negotiable. This year, we introduced additional "safety nets" that further protect your data from the most unpredictable variable in any system: human error.

Drop protection: Accidental deletions can be catastrophic. We introduced schema object drop protection as a safeguard for your production environments to prevent the accidental deletion of critical tables, indexes, and columns, acting as a line of defense against operational mishaps.
Zero-touch compliance with default backup schedules: Data protection shouldn't rely on manual checklists. We introduced default backup schedules to ensure a recovery baseline the moment a database is created. This minimizes the risk of forgotten backups and so that your workloads adhere to your organization's governance and compliance standards from day one.

Awards and recognition

While we continue to enhance Spanner based on customer needs and industry trends, it’s always great to get industry recognition for our work. In 2025,

Spanner was recognized as a Leader in the Gartner Magic Quadrant for Cloud DBMS and ranked #1 for the Lightweight Transactions Use Case (and Top 3 in all categories) in the Critical Capabilities for Operational Databases report for 2025, beating AWS Aurora to take the #2 rank in “OLTP Transactions”
Beyond technical performance, a March 2025 Forrester Total Economic Impact™ (TEI) study validated the significant business value Spanner delivers, finding that a representative composite organization realized a 132% ROI and $7.74M in total benefits over three years, with a rapid nine-month payback period.
We were also honored with the 2025 ACM SIGMOD Systems Award for "reimagining relational data management to enable serializability with external consistency at global scale."

Looking ahead

We are proud of what we have delivered for customers in 2025, and are excited to see the innovative solutions you are building on Spanner. Needless to say, we are just getting started and we have a lot more exciting capabilities lined up for 2026.

Want to learn more about what makes Spanner unique and how it’s being used today?

Try it yourself for free for 90-days or for as little as $65 USD/month for a production-ready instance that grows with your business without downtime or disruptive re-architecture.

Introducing managed connection pooling in AlloyDB — scale further, connect faster

Thu, 22 Jan 2026 17:00:00 +0000

AlloyDB for PostgreSQL is a fully managed database service engineered for demanding enterprise workloads, blending the familiarity and robustness of PostgreSQL with Google Cloud's advanced technology for exceptional performance, scalability, and high availability.

However, as applications grow and user loads intensify, another critical factor comes into play: efficiently managing database connections. Inefficient connection handling can become a bottleneck, hindering the very performance and scalability AlloyDB is designed to provide. Recognizing this, we are introducing a new capability designed to tackle this challenge head-on: managed connection pooling.

The hidden cost of database connections

In many application architectures, particularly those involving frequent, short-lived interactions like web applications or serverless functions, a common pattern is to open a new database connection for each request and close it afterward. While seemingly straightforward, this approach carries significant hidden costs, especially when running at scale.

Frequently establishing new database connections (common in web apps or serverless functions) is resource-intensive. Each new connection involves network handshakes, potential Transport Layer Security (TLS) negotiation, authentication, session initialization, and resource allocation, adding latency and consuming server CPU and memory. When multiplied across hundreds or thousands of concurrent requests, the cumulative impact of this connection overhead can be substantial:

Performance degradation: The time spent setting up and tearing down connections adds directly to application response times. Users experience slower interactions as the application waits for new connections before executing queries.
Resource exhaustion and scalability bottlenecks: Databases dedicate resources for each client connection. Even idle connections consume memory and CPU. This isn't just about the number of connections, but also the inefficiency caused by the constant churn of creation and destruction, consuming valuable resources, and capping how much a database can scale.
Reliability concerns: Traffic spikes causing connection surges can overwhelm the server, leading to degraded performance, connection timeouts, or even outages.

While client-side connection pooling libraries exist within application frameworks, managing these effectively across distributed systems or microservices architectures can introduce significant complexities. Ensuring consistent configuration, behavior, and efficient resource utilization across numerous independent client pools is a non-trivial challenge. A centralized, server-managed approach offers a more robust and simpler solution in such environments.

Introducing AlloyDB managed connection pooling

To address these challenges directly within our managed environment, managed connection pooling for AlloyDB for PostgreSQL provides an integrated, optimized solution for managing database connections, enhancing the performance, scalability, and reliability of your applications. Managed connection pooling for AlloyDB for PostgreSQL is generally available.

How connection pooling works

Instead of creating a new connection for every request, a pooler maintains a cache of active, ready-to-use database connections. When an application requests a connection (via the pooler's dedicated port 6432), the pooler assigns an available connection from its pool, bypassing the costly setup process. When the application finishes, the connection is returned to the pool, ready for reuse, rather than being closed.

The "managed" advantage

Crucially, this is not just any connection pooling solution; it's managed by AlloyDB. This means you get:

Tight integration: The pooling mechanism is built directly into the AlloyDB service, running efficiently alongside your database instance.
Simplified operations: AlloyDB handles the setup, configuration, patching, and maintenance of the connection pooler. You get the benefits without the operational burden of deploying, managing, and scaling a separate pooling infrastructure (which would be required with external tools like PgBouncer). This aligns perfectly with our core philosophy of automating AlloyDB administrative tasks and simplifying database management.
Optimized performance and security: Because the pooler is integrated within the AlloyDB environment and Google Cloud's network, communication between the pooler and the backend database processes is highly optimized, minimizing latency. Connections benefit from the robust security posture of our Cloud's infrastructure.
Enhanced reliability: The managed pooler inherently benefits from the underlying reliability features of the AlloyDB instance it runs on, including High Availability (HA) configurations.

In other words, by integrating connection pooling as a managed feature of AlloyDB, we’re directly addressing a fundamental scaling challenge of the traditional PostgreSQL connection model, making it easier than ever to build highly scalable and resilient applications.

Unlock more scale, reliability, and performance

Enabling managed connection pooling in AlloyDB also translates into tangible benefits for your applications:

Increased scale and performance: Efficient connection reuse unlocks more of the instance’s power. With the new Managed Connection Pooling feature, AlloyDB handles over 3x more clients and drives up to 5x higher transactional throughput compared to standard connections.
Improved reliability during connection surges: The pool acts as a shock absorber, rapidly serving requests with existing connections and preventing backend overload during traffic spikes, thus maintaining stability and preventing connection errors during peak loads. If the pool is temporarily exhausted, the pooler can queue incoming requests gracefully, improving the application's resilience.
Decreased latency for transient connections: Eliminates connection setup overhead for frequent, short-lived connections (common in web, microservices, serverless), resulting in faster query execution and significantly improved end-user response times.

To cater to different application needs and behaviors, AlloyDB managed connection pooling offers flexibility through configurable pooling modes :

Transaction mode (Default): Assigns connections per transaction, maximizing reuse and scalability. Ideal for high volumes of short transactions. Incompatible with session-specific features like non-transaction-scoped SET, session advisory locks, LISTEN, WITH HOLD cursors, or protocol-level prepared statements (use named prepared statements via max_prepared_statements).
Session mode: Assigns a connection for the client's entire session, ensuring full compatibility with all PostgreSQL features. Suitable for long-lived sessions or applications needing session state persistence, but offers less aggressive connection multiplexing.

The choice between modes represents a trade-off: transaction mode prioritizes maximum scalability and resource efficiency, while session mode prioritizes full compatibility with all session features. AlloyDB makes it simple to select the mode that best fits your application's requirements during configuration.

The following table summarizes the key improvements offered by enabling managed connection pooling:

Metric	Without Managed Pooling	With Managed Pooling (Typical)	Benefit
Transactions Per Minute	Baseline (1x)	Up to 5x	Higher throughput on the same instance
Max Concurrent Connections	Baseline (1x)	> 3x	Supports more simultaneous client connections
Connection Latency	High (Setup Overhead)	Low (Connection Reuse)	Faster responses for transient connections
Reliability (Load Spikes)	Vulnerable to overload	More resilient, absorbs spikes	Improved stability under heavy load

Customer spotlight: UKG

UKG, a leading provider of HR, payroll, and workforce management solutions, is an early adopter of AlloyDB managed connection pooling. To support their mission-critical People Fabric application used by millions of people every day, UKG needs a database that can handle immense scale, high transaction volumes, and fluctuating demand.

“We chose AlloyDB for its performance, reliability and managed simplicity. AlloyDB’s unique architecture allows us to pack significantly more databases per cluster than with any other Postgres managed service. This larger capacity translates to more database connections from users and applications, and so we had concerns with Postgres’ normal connection limits. We were thrilled to work with Google on the early adoption of managed connection pooling. This essential capability has helped us ensure top performance and low latency for our global customer base, giving us the freedom to grow on the same servers without worrying about connection constraints, even during peak usage.” - Jeff Bogenschneider, Sr. Principal Architect, People Fabric Chief Architect, UKG

UKG's experience highlights the critical role efficient connection management plays in supporting cutting-edge, demanding workloads. By leveraging managed connection pooling, UKG helps ensure their AlloyDB infrastructure remains robust and responsive, even under dynamic and unpredictable load patterns. This validation from a key provider in the HR technology space highlights AlloyDB's suitability for powering the next generation of intelligent, large-scale applications.

Getting started with managed connection pooling

One of the best aspects of managed connection pooling is its simplicity. Enabling it is straightforward:

Activate managed connection pooling in the Google Cloud console. Look for a checkbox when creating a new AlloyDB read pool instance or when editing an existing primary or read pool instance. You can also enable it using gcloud command-line tool flags or the AlloyDB API.
Connect your applications using standard PostgreSQL drivers and database credentials. Simply target your application to the connection pooler's dedicated port, 6432, instead of the default PostgreSQL port 5432. If you’re using AlloyDB Auth Proxy or language connectors, you don’t need to make any changes.
Finally, easily configure options like the desired pooling mode (Transaction or Session) and pool size limits during instance creation, and modify them via the Google Cloud console, gcloud, or API.

For detailed instructions, advanced configuration parameters, monitoring guidance, and best practices, please refer to the official documentation.

AlloyDB just got better

AlloyDB managed connection pooling is more than just a new feature; it's a fundamental capability that makes AlloyDB more accessible and effective for a wider range of applications. By intelligently managing database connections, it directly addresses common performance and scalability bottlenecks, allowing applications to fully leverage AlloyDB's performance and robust architecture.

Ready to experience the benefits? Enable managed connection pooling for your AlloyDB instances today.

Learn more: https://cloud.google.com/alloydb/docs/configure-managed-connection-pooling
New to AlloyDB? Try it at no cost

How Fastweb + Vodafone reimagined data workflows with Spanner & BigQuery

Thu, 22 Jan 2026 17:00:00 +0000

Editor’s note: Fastweb + Vodafone, a leading telecommunications provider in Italy, created its Customer 360 platform to support faster and more personalized customer experiences across channels. By rebuilding serving layers and governance with Google Cloud services like Spanner, BigQuery, and Gemini, the company simplified its architecture and introduced AI-assisted engineering workflows. Fastweb + Vodafone now delivers real-time insights across the organization and is preparing for expanded AI agent use cases in the future.

Following the acquisition of Vodafone Italy by Swisscom in 2025, and looking toward our official merger in January 2026, we saw an opportunity to rethink how we serve our customers.

As a leading telecommunications provider in Italy, we aim to deliver timely, personalized experiences across mobile, broadband, and digital channels. Our team’s job is to give everyone at our business access to the customer insights they need, when they need them. Those insights rely on a robust Customer 360 platform where data from thousands of sources is unified and made available in real-time.

Both companies had already begun modernizing these customer data workflows on Google Cloud, especially with BigQuery. However, combining ecosystems exposed the limits of our existing setup. The architecture required more upkeep than we wanted and didn’t offer the flexibility our unified organization needed. It was time for us to rethink how we served and governed customer data.

Choosing a connected platform, not a single tool

When we stepped back and looked at what Fastweb + Vodafone needed, it was clear we weren’t searching for a single tool. We wanted a connected suite of products that could support real-time serving, stronger governance, and new AI-assisted workflows without adding operational weight.

Figure 1: Architecture diagram for the Customer 360 Serving Layer

We were covered on the warehouse side: BigQuery was already in place and handling core analytical workloads. What we lacked was a serving layer that could match BigQuery’s speed and flexibility while simplifying our architecture. We also wanted tighter integration across the stack so we could more easily surface insights and begin incorporating AI.

Google Cloud brought all these capabilities together in a unified way. With native integrations between products, it was the right choice. We could spend less time connecting systems and more time building the features our business actually needs.

Spanner accelerates serving without the overhead

Giving every channel real-time access to accurate customer data meant finding a serving layer that kept pace with telecom traffic. Spanner was the answer. Spanner delivers low-latency reads, horizontal scalability, high availability, and a fully managed environment with zero ops overhead.

Spanner’s native integration with BigQuery was the real game-changer. Before Spanner, we relied on several custom layers built solely to move warehouse data into downstream systems. But the direct interoperability between Spanner and BigQuery has made most of that complexity disappear. With Spanner as the front-end serving layer, we were able to migrate ten applications in two weeks.

Spanner also transformed how we monitor and maintain our workflows. Four separate monitoring processes collapsed into a single view, making troubleshooting and optimization far faster. And with Apigee exposing Spanner data to the call center, digital channels, and partner systems, the improvements were felt across the entire organization — not just within engineering.

Making sense of thousands of data flows

With Spanner in place as our serving layer, the next challenge was making sense of the thousands of batch and real-time ingestion flows that power Fastweb + Vodafone Data platform. Understanding how data moves across these pipelines is essential for quality, compliance, and day-to-day engineering. We needed something faster and far more intuitive than our previous solution.

Spanner’s multi model capabilities gave us that foundation.

Spanner Graph allowed us to map lineage in a way that reflects how our platform actually works: which tables drive specific jobs, how transformations cascade, and where dependencies sit. From there, vector search and full-text search added a richer discovery layer. This made it easier to surface results quickly, even in a large and complex ecosystem.

Together, these features gave us the governance experience we wanted — not only more accurate, but much easier for engineers and analysts to work with.

Figure 2: Spanner’s Graph model allowed us to rapidly build a scalable, easy-to-navigate visualization of complex data lineage for improved Data Governance

Effortless documentation

We also wanted to make development smoother across our organization’s large and varied codebase. Many services had limited documentation, especially older systems that had evolved over time. Gemini helped us close those gaps.

With Gemini, our teams can generate clear documentation directly from the code, which saves hours of manual work. We store this output in Spanner as vector embeddings, which creates a searchable knowledge base that grows alongside our platform.

To make that knowledge even easier to use, we built a chat interface powered by Gemini. Developers can ask natural-language questions — say, about a function or how a change might ripple through the system — and get a context-aware answer in seconds. It’s a far more intuitive way to explore the codebase and reduces the time spent deciphering legacy logic or chasing down subject-matter experts.

Figure 3: Code Documentation augmentation and search with Gemini and Spanner

This AI-assisted workflow is now a regular part of how we build. It speeds up onboarding and gives us a scalable way to improve productivity even as our systems evolve.

Engineering at the speed of business

Rebuilding our Customer 360 platform with Google Cloud services has already changed how Fastweb + Vodafone works.

Workflow monitoring is simpler, pipelines are leaner, and real-time serving is now the norm.

The gains from this work are also visible across the business: Call centers now see more complete, up-to-date customer information, digital channels can rely on consistent data without custom integrations, and partners can access what they need with low latency through Apigee. Together, it all creates a smoother, more personalized customer experience — exactly what we imagined at the start of this process.

And we’re just getting started. We are now exploring Spanner Graph capabilities to better understand customer relationships through householding and social indexing. We also see more potential for AI agents to help teams improve analysis and decision-making.

Google Cloud didn't just simplify our engineering – it changed how our entire organization operates.

Learn more:

Explore Spanner, a fully managed relational database for global-scale workloads, and the power of Spanner Graph!
Learn how BigQuery simplifies analytics with built-in performance and scalability.
Bring AI assistance into engineering workflows with Gemini for Google Cloud.

Elevate your applications with Firestore’s new advanced query engine

Tue, 20 Jan 2026 17:00:00 +0000

A hallmark of a valuable database is how easy it is to query the data inside, so that developers can build tailored and complex user experiences in an application. Last week marked a significant evolution for Firestore, Google Cloud’s enterprise-grade, scalable document database, with the debut of an advanced query engine designed to help you build more sophisticated applications.

Available as part of Firestore in Native mode, this powerful engine introduces over a hundred new query capabilities, called pipeline operations, available in preview, which streamline complex queries directly within the database. Alongside this, we're launching precise indexing controls and refreshed observability tools like query explain and query insights, giving you granular control over performance. All these robust capabilities are now available in the Firestore Enterprise edition, which also offers a more transparent pricing model for potential cost savings. This is all in the service of building highly expressive, performant applications that can query, transform and filter data across many dimensions, with less operational overhead. At the same time, you’re benefiting from Firestore’s unique serverless foundation, multi-region replication, and virtually unlimited scalability, freeing you from database management complexities, so you can truly focus on innovation.

Used by a vibrant community of over 600,000 developers, Firestore has long been appreciated for its simplicity. In 2019, Firestore Standard edition in Native mode streamlined the development of collaborative applications with a straightforward query interface that guaranteed high performance through the use of automatically generated indexes. However, this simplified query engine has a strong dependence on indexing for query execution, often demanding upfront planning throughout the application lifecycle. Now, with the introduction of the advanced query engine in Enterprise edition, developers can construct highly expressive applications, regardless of the explicit presence of indexes — particularly for demanding solutions like e-commerce, interactive gaming, content management, and sophisticated user personalization. The refined query engine makes it easier to create pipeline operations, complete with sophisticated new stages and expressions, including support for complex aggregations, querying directly over arrays, advanced string matching capabilities, and granular filtering options.

A new query engine and pipeline operations experience

To enable this, we’ve updated Firestore’s existing SDKs with expanded support for pipeline operations. Now, you can elegantly chain together numerous stages for essential tasks such as aggregations, grouping, and filtering. Queries now run without mandatory indexes, giving you complete autonomy over when you want to create indexes to optimize performance. Let’s take a look at an illustration of pipeline operations.

Note: This example assumes you're familiar with Firestore's data model and existing query methods.

Suppose you want to identify the top trending hashtags on an existing food recipe application that allows users to add hashtags to recipes. For essential data (like the recipe text itself), you might represent a recipe as a document with some fields. Since a hashtag can be represented with just a string, you could add hashtags directly to the recipe document as an array of strings:

code_block: <ListValue: [StructValue([('code', '{\r\n title: "My recipe",\r\n instructions: "Cook the ingredients",\r\n authorId: "SomeAuthorID",\r\n hashtags: ["easy", "high protein", "low carb"],\r\n ...\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f67a0c44160>)])]>

Firestore users can query for specific hashtags within recipes using existing core operations. However, prior to pipeline operations, there was no direct way to extract and aggregate array data from within a document during a query.

With pipeline operations, you can “unnest” arrays directly. This makes it simple to identify and suggest trending hashtags to your users. Below is an example of how to implement this using Javascript:

code_block: <ListValue: [StructValue([('code', '// Fetch 10 hashtags sorted by most popular.\r\nconst snapshot = await db.pipeline()\r\n\r\n // Starting with the collection of recipe documents:\r\n .collection("recipes")\r\n\r\n // Limit the document to just the `hashtags` field.\r\n .select("hashtags")\r\n\r\n // Unnest each tag within the `hashtags` array to its own document.\r\n .unnest(field("hashtags").as("tagName"))\r\n\r\n // Count the number of instances of each tag across recipes and\r\n // consolidate documents sharing a tagName into a single document\r\n // per tagName.\r\n .aggregate({\r\n accumulators: [countAll().as("tagCount")],\r\n groups: ["tagName"]\r\n })\r\n\r\n // Sort the resulting hashtags by their count.\r\n .sort(field("tagCount").descending())\r\n\r\n // Limit query results to just the top ten hashtags.\r\n .limit(10)\r\n\r\n .execute()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f67a0c44af0>)])]>

In addition, Firestore Enterprise edition supports a broader array of index types (including single field, composite, sparse, non-sparse, and unique indexes) that lets you maximize query performance even more. Furthermore, you can control when indexes are created, consequently improving overall write performance and storage utilization when compared to Standard edition’s automatic single-field indexes. This helps to mitigate index fanout during write operations.

Since indexing is fully customizable, Enterprise edition also provides advanced observability tools — query explain and query insights — specifically built to help developers identify and optimize queries by identifying missing indexes. Through query explain, developers can profile queries to gain a comprehensive understanding of query planner details and view execution statistics. This includes essential data such as billing information, and deep, system-level visibility into the query's execution path.

Determine if a query is using an index and analyze its total execution metrics by profiling it with query explain.

Complementing this, query insights enables ongoing monitoring of high-latency and frequently executed queries that may require tuning. By utilizing the query insights dashboard, you can identify queries that can benefit from deploying indexes to boost performance.

Leverage query insights to identify the highest latency and most frequently executed queries on your database, evaluating whether they require indexing based on the quantity of index entries scanned.

Migration for current Firestore customers

If you’re new to Firestore, getting started is easy — simply create a Firestore Enterprise edition database. For existing Firestore developers, transitioning to Firestore pipeline operations is also simple: just use the integrated import and export service to migrate data from a Firestore Standard edition database to a freshly provisioned Enterprise edition database. Crucially, Enterprise edition maintains backwards compatibility, so you can retain your existing application code for Firestore core operations. When the time is right to harness the advanced capabilities, here’s how to convert code from core operations into pipeline operations:

code_block: <ListValue: [StructValue([('code', 'const query = db.collection("recipes").where("authorId", "==", user.id);\r\n\r\n// Convert the query into a pipeline\r\nconst pipeline = db.pipeline.createFrom(query);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f67a0c442b0>)])]>

And then you can immediately begin working with the new pipeline capabilities.

code_block: <ListValue: [StructValue([('code', '// From the last snippet\r\nconst pipeline = db.pipeline.createFrom(query);\r\n\r\nconst snapshot = pipeline\r\n .where(field("rating").greaterThan(4))\r\n .execute();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f67a0c44940>)])]>

Predictable pricing and optimized costs

Firestore Enterprise edition utilizes an improved, transparent pricing model for managing costs. For all read and write operations performed against the database, you are now billed based on the size of the documents and associated index entries involved. This new approach brings potential savings of up to 86% when executing read operations on documents under 4 kibibytes.

Real-time listen query updates are separately metered and billed as they are incurred. Furthermore, there are no upfront fees or latent costs resulting from incorrect database cluster capacity planning or inefficient database sharding. Storage consumption is billed solely for the actual capacity you use, inclusive of replicated copies for high availability. And if you’re new to Firestore and want to try it out, Enterprise edition includes access to a generous free-tier to make it easy to get started.

Get started with Firestore pipeline operations

Enterprise edition offers an advanced query engine to power flexible developer experiences, accessible both through Firestore in Native mode, and Firestore with MongoDB compatibility mode. This allows developers to maximize existing libraries and tools from either the Firestore and MongoDB developer communities. You can get started with Firestore pipeline operations in preview today, by creating a new Firestore Enterprise edition database in Native mode. To delve into how to get started with pipeline operations, refer to the documentation.

Embark on your journey with the Enterprise edition today — benefit from zero upfront fees and immediate access to a generous free-tier: https://cloud.google.com/products/firestore.

Supercharge your Cloud SQL for MySQL write performance with new optimized writes

Mon, 05 Jan 2026 18:00:00 +0000

Tuning MySQL instances for write-intensive workloads is a persistent engineering challenge. Cloud SQL for MySQL Enterprise Plus edition now includes optimized writes, a set of automated features that adjust MySQL configurations based on real-time workload and infrastructure metrics. This reduces write latency and increases throughput without manual intervention.

All Enterprise Plus edition instances have this feature enabled by default. This post details the underlying optimizations and provides a reproducible benchmark to measure the performance improvements.

Inside Cloud SQL for MySQL optimized writes

The optimized writes feature includes five different optimizations that all automatically tune MySQL parameters, flags, and data handling, in order to optimize write performance based on instance and workload needs. Here’s a little more about how each component of optimized writes works:

Feature	What it does
Adaptive purge	Cloud SQL dynamically adjusts innodb_purge_threads to prioritize user workloads over routine database maintenance operations.
Adaptive I/O limits	Cloud SQL dynamically adjusts I/O parameters, specifically innodb_io_capacity and innodb_io_capacity_max. This adjustment occurs in direct response to fluctuations in workload demands and prevents I/O bottlenecks during traffic spikes.
Scalable sharded I/O	Cloud SQL implements I/O sharding by distributing load across multiple mutexes to enhance I/O throughput and accommodate demanding workloads.
Faster REDO recovery	Cloud SQL optimizes the handling of temporary data and the expedited flushing of dirty pages, consequently reducing recovery times and enabling the utilization of larger redo logs.
Adaptive buffer pool warmup	Cloud SQL dynamically uses available disk I/O capacity to accelerate data cache warmup by scheduling page reads, resulting in faster data cache warmup post instance restart and a reduction in performance variance.

We've observed that with optimized writes, Cloud SQL for MySQL Enterprise Plus now delivers up to 3x better write throughput when compared to its Enterprise edition counterpart, while reducing latency significantly. These optimizations are most effective for write-intensive OLTP workloads and results can vary based on machine configurations. For workloads that are primarily read, Cloud SQL Enterprise Plus edition also provides an integrated SSD-backed data cache option, enabling up to 3x higher read throughput, as detailed in our initial launch blog.

Testing the optimized write performance improvement

Now that you're aware of the exceptional write performance offered by Cloud SQL for MySQL Enterprise Plus edition, you might be curious about its potential impact within your own environment. Measuring this performance enhancement can be done with the sysbench benchmarking tool. You can follow the steps below and adjust specific machine configuration parameters to conduct testing tailored to your typical workloads.

Step 1: Create database instances
To help study the performance improvement, first create three different class of machines:

Enterprise edition (ee)
Enterprise Plus edition (ee+) without optimized writes
Enterprise Plus edition (ee+) with optimized writes

code_block: <ListValue: [StructValue([('code', '# will set some basic configuration variables to help us run things with higher scalability.\r\n\r\n#------------------------------------------------------\r\n# ee\r\ngcloud sql instances create ee --database-version="MYSQL_8_0_37" --availability-type=zonal --edition=ENTERPRISE --cpu=64 --memory=416GB --storage-size=3000 --storage-type=SSD --zone="us-central1-c" --network=projects/${PROJECT}/global/networks/default --no-assign-ip --enable-google-private-path --no-enable-bin-log --database-flags="max_prepared_stmt_count=1000000,innodb_adaptive_hash_index=off,innodb_flush_neighbors=0,table_open_cache=200000"\r\n\r\n#------------------------------------------------------\r\n# ee+ without optimized writes\r\n# Note: this configuration is not recommended and being shown only for comparison\r\n# without optimized write larger redo log size will cause longer recovery time so switch back the redo log size to what it was originally (before optimized write was introduced).\r\ngcloud sql instances create eeplusow0 --database-version="MYSQL_8_0_37" --availability-type=zonal --edition=ENTERPRISE_PLUS --tier=db-perf-optimized-N-64 --storage-size=3000 --storage-type=SSD --zone="us-central1-c" --network=projects/${PROJECT}/global/networks/default --no-assign-ip --enable-google-private-path --no-enable-bin-log --database-flags="max_prepared_stmt_count=1000000,innodb_adaptive_hash_index=off,innodb_flush_neighbors=0,table_open_cache=200000,innodb_cloudsql_optimized_write=off,innodb_log_file_size=1073741824"\r\n\r\n#------------------------------------------------------\r\n# ee+ with optimized writes\r\ngcloud sql instances create eeplusow1 --database-version="MYSQL_8_0_37" --availability-type=zonal --edition=ENTERPRISE_PLUS --tier=db-perf-optimized-N-64 --storage-size=3000 --storage-type=SSD --zone="us-central1-c" --network=projects/${PROJECT}/global/networks/default --no-assign-ip --enable-google-private-path --no-enable-bin-log --database-flags="max_prepared_stmt_count=1000000,innodb_adaptive_hash_index=off,innodb_flush_neighbors=0,table_open_cache=200000"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679ec61b80>)])]>

Step 2: Create client
Next, create a VM for the client instance. Client instances are placed in the same region but different zone.

code_block: <ListValue: [StructValue([('code', 'gcloud compute instances create c1 --zone="us-central1-a" --boot-disk-size=10GB --create-disk=name=c1disk,size=100GB --machine-type=n2-custom-32-65536 --network=projects/${PROJECT}/global/networks/default\r\n\r\ngcloud compute instances create c2 --zone="us-central1-a" --boot-disk-size=10GB --create-disk=name=c2disk,size=100GB --machine-type=n2-custom-32-65536 --network=projects/${PROJECT}/global/networks/default\r\n\r\ngcloud compute instances create c3 --zone="us-central1-a" --boot-disk-size=10GB --create-disk=name=c3disk,size=100GB --machine-type=n2-custom-32-65536 --network=projects/${PROJECT}/global/networks/default'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679ec61250>)])]>

Then, log in to the client instances and execute following commands to install sysbench and mysqladmin:

code_block: <ListValue: [StructValue([('code', 'gcloud compute ssh <CLIENT_INSTANCE> --zone us-central1-a'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679ec61ee0>)])]>

code_block: <ListValue: [StructValue([('code', 'sudo apt-get --purge remove sysbench\r\n\r\n# check for latest repo here https://dev.mysql.com/downloads/repo/apt/\r\nwget https://repo.mysql.com//mysql-apt-config_0.8.36-1_all.deb\r\n\r\n# command will prompt for selecting the mysql version. Feel free to select any version (8.4 default or change it to 8.0)\r\nsudo apt install ./mysql-apt-config_0.8.36-1_all.deb\r\nsudo apt update\r\nsudo apt -y install make automake libtool pkg-config libaio-dev\r\nsudo apt -y install libssl-dev zlib1g-dev\r\nsudo apt -y install libmysqlclient-dev\r\nsudo apt -y install mysql-community-client-core\r\n\r\nsudo apt -y install git\r\nmkdir ~/sysbench\r\ngit clone https://github.com/akopytov/sysbench\r\ncd sysbench\r\n./autogen.sh\r\n./configure --prefix=$HOME/sysbench/installed\r\nmake -j 16\r\nmake install\r\ncd ~/\r\nrm mysql-apt-config_0.8.36-1_all.deb'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679ec61c40>)])]>

Step 3: Run the benchmarking workload
Finally, you can run the sysbench write benchmark using the following script:

code_block: <ListValue: [StructValue([('code', 'mkdir opt-write\r\ncd opt-write\r\n\r\n# TODO: EDIT THE USER/HOST/PASSWORD\r\n\r\n#copy the script and replace the HOST IP address with the database instance ip.\r\nnohup ./write-workload.sh'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f679ec61fa0>)])]>

code_block: <ListValue: [StructValue([('code', '#!/bin/bash\r\n\r\n# write-workload.sh\r\n\r\nHOST=HOST_IP_ADDRESS\r\nsysbenchdir="$HOME/sysbench/installed/"\r\nmysqlclidir="/usr/bin"\r\nmysqluser="root"\r\nmysqlpasswd="pas$w0rd"\r\n\r\nrows=("12000000")\r\n\r\nfor (( k=1; k<=4; k+=1 ))\r\ndo\r\n for row in ${rows[@]};\r\n do\r\n #------------\r\n # step-1: load data\r\n $mysqlclidir/mysql -u $mysqluser -h $HOST -e "drop database if exists x86; create database if not exists x86;"\r\n $sysbenchdir/bin/sysbench --threads=100 --mysql-host=$HOST --mysql-port=3306 --mysql-db=x86 --mysql-user=$mysqluser --mysql-password=$mysqlpasswd $sysbenchdir/share/sysbench/oltp_insert.lua --tables=100 --table-size=$row prepare\r\n $sysbenchdir/bin/sysbench --threads=128 --events=10000000 --time=0 --report-interval=10 --mysql-host=$HOST --mysql-port=3306 --mysql-db=x86 --mysql-user=$mysqluser --mysql-password=$mysqlpasswd $sysbenchdir/share/sysbench/oltp_update_index.lua --tables=100 --table-size=$row run\r\n sleep 300\r\n\r\n #------------\r\n # step-2: start write benchmarking workload\r\n for (( i=128; i<=512; i*=2 ))\r\n do\r\n $sysbenchdir/bin/sysbench --threads=$i --time=3600 --report-interval=10 --mysql-host=$HOST --mysql-port=3306 --mysql-db=x86 --mysql-user=$mysqluser --mysql-password=$mysqlpasswd $sysbenchdir/share/sysbench/oltp_write_only.lua --tables=100 --table-size=$row run\r\n sleep 120\r\n done\r\n $mysqlclidir/mysql -u root -h $HOST -e "drop database if exists x86;"\r\n done\r\ndone'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f67a0dfd880>)])]>

Upon completion, you will observe the throughput and latency results from the three Cloud SQL instances created in Step 1. These results should demonstrate the performance advantages of the Enterprise Plus edition and further improvements brought by optimized writes. Please note that performance outcomes can fluctuate and may vary based on specific machine configurations.

Ready to enable optimized writes?

All existing and newly created instances have optimized writes enabled by default, so upgrade your Cloud SQL instances to Enterprise Plus edition today to experience the performance improvement!

Achieve near-100% accurate text-to-SQL for your agentic apps

Thu, 18 Dec 2025 18:00:00 +0000

Today’s AI capabilities provide a great opportunity to enable natural language (NL) interactions with your enterprise data through applications using text and voice. In fact, in the world of agentic applications, natural language is rapidly becoming the interaction standard. That means agents need to be able to issue natural language questions to a database and receive accurate answers in return. At Google Cloud, this drove us to build Natural-Language-to-SQL (NL2SQL) technology in the AlloyDB database that can receive a question as input and return a NL result, or the SQL query that will help you retrieve it.

Currently in preview, the AlloyDB AI natural language API enables developers to build an agentic application that answers natural language questions on their database data by agents or end users in a secure, business-relevant, explainable manner, with accuracy approaching 100% — and we’re focused on bringing this capability to a broader set of Google Cloud databases.

When we first released the API in 2024, it already provided leading NL2SQL accuracy, albeit not close to 100%. But leading accuracy isn’t enough. In many industries, it’s not sufficient to translate text into SQL with accuracy of 80% or even 90%. Low-quality answers carry a real cost, often measurable in monetary terms: disappointed customers or poor business decisions. A real estate search application that fails to understand what the end user is asking for (their “intent”) risks becoming irrelevant. In retail product search, less relevant answers lead to lower conversions into sales. In other words, the accuracy of the text-to-SQL translation must almost always be extremely high.

In this blog we help you understand the value of the AlloyDB AI natural language API and techniques for maximizing the accuracy of its answers.

Getting to ~100% accurate and relevant results

Achieving highly accurate text-to-SQL takes more than just prompting Gemini with a question. Rather, when developing your app, you need to provide AlloyDB AI with descriptive context, including descriptions of the database tables and columns; this context can be autogenerated. Then, when the AlloyDB AI natural language API receives a question, it can intelligently retrieve the relevant pieces of descriptive context, enabling Gemini to see how the question relates to the database data.

Still, many of our customers asked us for explainable, certifiable and business-relevant answers that would enable them to reach even higher accuracy, approaching 100% (such as >95% or even higher than 99%), for their use cases.

The latest preview release of the AlloyDB AI natural language API provides capabilities for improving your answers in several ways:

Business relevance: Answers should contain and properly rank information in order to improve business metrics, such as conversions or end-user engagement.
Explainability: Results should include an explanation of intent that clarifies — in language that end users can understand — what the NL API understood the question to be. For example, when a real estate app interprets the question “Can you show me Del Mar homes for families?” as “Del Mar homes that are close to good schools”, it explains its interpretation to the end user.
Verified results: The result should always be consistent with the intent, as it was explained to the user or agent.
Accuracy: The result should correctly capture the intent of the question.

With this, the AlloyDB AI natural language API enables you to progressively improve accuracy for your use case, what’s sometimes referred to as “hill-climbing”. As you work your way towards 100% accuracy, AlloyDB AI’s intent explanations mitigate the effect of the occasional remaining inaccuracies, allowing the end user or agent to understand that the API answered a slightly different question than the one they intended to ask.

aside_block: <ListValue: [StructValue([('title', 'Get started with a 30-day AlloyDB free trial instance'), ('body', <wagtail.rich_text.RichText object at 0x7f679f8de490>), ('btn_text', ''), ('href', ''), ('image', None)])]>

Hill-climbing to approximate 100% accuracy

Iteratively improving the accuracy of AlloyDB AI happens via a simple workflow.

First, you start with the NL2SQL API that AlloyDB AI provides out of the box. It’s highly (although not perfectly) accurate thanks to its built-in agent that translates natural language questions into SQL queries, as well as automatically generated descriptive context that is used by the included agent.

Next, you can quickly iterate to hill-climb to approximately 100% accuracy and business relevance by improving context. Crucially, in the AlloyDB AI natural language API, context comes in two forms:

Descriptive context, which includes table and column descriptions, and
Prescriptive context, which includes SQL templates and (condition) facets, allowing you to control how the NL request is translated to SQL.

Finally, a “value index” disambiguates terms (such as SKUs and employee names) that are private to your database, and thus that are not immediately clear to foundation models.

The ability to hill-climb to approximate 100% accuracy flexibly and securely relies on two types of context and the value index in AlloyDB.

Let’s take a deeper look at context and the value index.

1. Descriptive and prescriptive context

As mentioned above, the AlloyDB AI natural language API relies on descriptive and prescriptive context to improve the accuracy of the SQL code it generates.

By improving descriptive context, mostly table and column descriptions, you increase the chances that the SQL queries employ the right tables and columns in the right roles. However, prescriptive context resolves a harder problem: accurately interpreting difficult questions that matter for a given use case. For example, an agentic real-estate application may need to answer a question such as “Can you show me homes near good schools in <provided city>?” Notice the challenges:

What exactly is “near”?
How do you define a “good” school?
Assuming the database provides ratings, what is the cutoff for a good school rating?
What is the optimal tradeoff (for ranking purposes and thus for business relevance of the top results) between distance from the school and ranking of the school when the solutions are presented as a list?

To help, the AlloyDB natural language API lets you supply templates, which allow you to associate a type of question with a parameterized SQL query and a parameterized explanation. This enables the AlloyDB NL API to accurately interpret natural language questions that may be very nuanced; this makes templates a good option for frequently asked, nuanced questions.

A second type of prescriptive context, facets, allows you to provide individual SQL conditions along with their natural language counterparts. Facets enable you to combine the accuracy of templates with the flexibility of searching over a gigantic number of conditions. For example, “near good schools” is just one of many conditions. Others may be price, “good for a young family”, “ocean view” or others. Some are combinations of these conditions, such as “homes near good schools with ocean views”. But you can’t have a template for each combination of conditions. In the past, to accommodate all these conditions, you could have tried to create a dashboard with a search field for every conceivable condition, but it would have become very unwieldy, very fast. Instead, when you use a natural language interface, you can use facets to cover any number of conditions, even in a single search field. This is where the strength of a natural language interface really shines!

The AlloyDB AI natural language API facilitates the creation of descriptive and prescriptive context. For example, rather than providing parameterized questions, parameterized intent explanations, and parameterized SQL, just add a template via the add_template API, in which you provide an example question (“Del Mar homes close to good schools”) and the correct corresponding SQL. AlloyDB AI automatically generalizes this question to handle any city and automatically prepares an intent explanation.

2. The value index

The second key enabler of approximate 100% accuracy is the AlloyDB AI value index, which disambiguates terms that are private to your database and, thus, not known to the underlying foundation model. Private terms in natural language questions pose many problems. For starters, users misspell words, and, indeed, misspellings increase with a voice interface. Second, natural language questions don’t always spell out a private term’s entity type. For instance, a university administrator may ask “How did John Smith perform in 2025?” without specifying whether John Smith is faculty or a student; each case requires a different SQL query to answer the question. The value index clarifies what kind of entity “John Smith” is, and can be automatically created by AlloyDB AI for your application.

Natural language search over structured, unstructured and multimodal data

When it comes to applications that provide search over structured data, the AlloyDB AI natural language API enables a clean and powerful search experience. Traditionally, applications present conditions as filters in the user interface that the end user can employ to narrow their search. In contrast, an NL-enabled application can provide a simple chat interface or even take voice commands that directly or indirectly pose any combination of search conditions, and still answer the question. Once search breaks free from the limitations of traditional apps, the possibilities for completely new user experiences really open up.

The combination of the NL2SQL technology with AI search features also makes it good for querying combinations of structured, unstructured and multimodal data.The AlloyDB AI natural language API can generate SQL queries that include vector search, text search and other AI search features such as the AI.IF condition, which enables checking semantic conditions on text and multimodal data. For example, our real estate app may be asked about “Del Mar move-in ready houses”. This would result in a SQL query with an AI.IF function that checks whether the text in the description column of the real_estate.properties table is similar to “move-in ready”.

Bringing the AlloyDB AI natural language API into your agentic application

Ready to integrate the AlloyDB AI natural language API into your agentic application? If you’re writing AI tools (functions) to retrieve data from AlloyDB, give MCP Toolbox for Databases a try. Or for no-code agentic programming, you can use Gemini Enterprise. For example, you can create a conversational agentic application that uses Gemini to answer questions from its knowledge of the web and the data it draws from your database — all without writing a single line of code! Either way, we look forward to seeing what you build.

Databases

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

Agentic Tools: A Path to Accuracy and Explainability

The Key Ingredient: Comprehensive Database Context

1. Schema Ontology

2. Query Blueprints

Accuracy As Foundation for Agentic Actions

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

The opportunity for agentic systems: from intent to action

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

Understanding the accuracy gap

How QueryData solves for near-100% accuracy

Deterministic security for your queries

Ease of use for quality hill-climbing and tool integration

What you can build with QueryData today

Next steps

What’s new with Google Data Cloud

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

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

The Power of interoperable multi-model databases

Spanner’s AI advantage

Companies making AI a globe-spanning success

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

1. Fraud detection

2. Recommendation engines

3. Hybrid search

4. Autonomous network operations

Looking Ahead

How ID.me Scaled to 160M Users While Reducing Operational Risk

But demand doesn’t wait

A new database for us and our 160 million closest friends

Training AI to fight . . . AI?

One login. Every system. Zero friction.

Learn more:

Manhattan Associates powers over a billion daily API calls with Google Cloud databases

From monolithic roots to cloud resilience

Building resilience and speed into every transaction

A modernized foundation: From database to intelligence

Unprecedented speed, scale, and operational efficiency in practice

Learn more

Streamline read scalability with Cloud SQL autoscaling read pools

Why read pools?

Easier scaling with read pool autoscaling

How Cloud SQL improves availability with read pools

Enabling and using read pools with autoscaling

Get started today

Next-gen caching with Memorystore for Valkey 9.0, now GA

Performance at scale: Speed without compromise

The mechanics of throughput: Pipelining

New capabilities for modern developers

Enterprise-ready features

Seamless upgrades

Looking ahead

Ready to build?

PayPal's historically large data migration is the foundation for its gen AI innovation

Untapped potential of data

Legacy systems, modern ambitions

The journey to unified data

Benefits from BigQuery and beyond

AI-powered innovation unleashed

Lessons for the AI era

Serving data from Iceberg lakehouses fast and fresh with Spanner columnar engine

Uniting OLTP and analytics: The Spanner columnar engine

New features

Why Iceberg data needs a fast, low-latency serving platform

Benchmarking Spanner columnar engine

Universal reverse ETL: Serving data from all lakehouses

Get started today

Decommission your legacy Apache Cassandra stack and build for the future with Spanner

Beyond NoSQL: Strategic solutions for Cassandra Users

Tweak Spanner for your specific workload

Deconstruct your Cassandra ecosystem