Databases

SOCRadar powers rapid threat detection with AlloyDB and Gemini Enterprise

Wed, 01 Jul 2026 19:00:00 +0000

Editor’s note: SOCRadar is a leading cybersecurity company that provides threat intelligence to businesses worldwide. As the volume of cyber threats continued to grow, SOCRadar needed to modernize its data infrastructure to deliver faster insights to its customers. By migrating from PostgreSQL to AlloyDB, SOCRadar achieved a 20x performance boost, reduced operational overhead, and is now better positioned to innovate and grow.

How SOCRadar supercharges rapid threat detection with AlloyDB

SOCRadar provides external threat intelligence to help organizations across 30+ countries defend against cyberattacks. On the front lines of cybersecurity, timely intelligence is everything and a delay of a few minutes can mean the difference between a blocked exploit and a full-scale breach.

As SOCRadar’s business scaled and cyber threat volumes exploded, their on-premises, self-managed PostgreSQL database hit a wall. The database simply couldn't keep pace with the simultaneous demands of high-velocity data ingestion and heavy, real-time analytical queries. This created a severe data bottleneck, slowing down the delivery of critical insights to customers and pulling engineers away from innovation to focus on constant manual database tuning.

Evaluating database alternatives: The hunt for scalability

The engineering team realized their traditional PostgreSQL environment had reached its absolute performance limits. To scale, SOCRadar needed a high-performance fully managed database that could dramatically slash operational overhead while elegantly handling a complex, hybrid workload.

They evaluated alternatives and selected Google Cloud's AlloyDB for PostgreSQL. Because AlloyDB is fully PostgreSQL-compatible, it offered a low-risk migration path while promising a specialized architecture built to handle both high-volume transactions and real-time analytics simultaneously. To accelerate the transition, SOCRadar partnered with NGC, a Premier Business Partner, who meticulously validated the architecture before executing a precision cutover with minimal downtime.

Taming a "triple-threat" workload

Migrating to AlloyDB transformed how SOCRadar processes massive, diverse cyber telemetry. Today, AlloyDB effortlessly manages what SOCRadar’s engineering team calls a "triple-threat" query environment, maintaining sub-second lookup latency even as processing volumes scale.

To understand the performance leaps, it helps to separate the system’s velocity (handling live data streams) from its depth (analyzing historical data):

High-Velocity Transactional Ingestion (OLTP): The platform constantly ingests real-time telemetry from thousands of disparate, fast-moving sources—including Dark Web forums, botnet logs, and social media feeds. AlloyDB handles these continuous INSERT and UPSERT operations with a 3.2x boost in live ingestion velocity, ensuring that the newest threat indicators are immediately recorded and available for detection.
Real-Time Operational Point-Reads: When a security analyst is actively investigating a live incident, speed is everything. Baseline performance testing under zero-load conditions for random ID lookups on indexed fields (e.g., querying a specific Indicator of Compromise by ID) showed that standard queries requiring 3 to 3.5 seconds were completed in just 1 second on AlloyDB.
Deep Analytical Aggregations (OLAP): When a client requests a complex sectoral report such as correlating the most prevalent attack vectors in the finance sector over an entire year, the database must execute deep scans across vast historical datasets. Leveraging AlloyDB’s built-in In-Memory Columnar Engine, these analytical queries run up to 20x faster than standard PostgreSQL.

More than just speed: Reclaiming 45 TB and 75% of DBA time

While the raw performance gains were massive, the operational and financial impact completely changed how SOCRadar's engineering team works day-to-day.

Thanks to AlloyDB's advanced automation, including intelligent memory management and write-ahead log (WAL) optimization, the need for constant, manual database tuning evaporated. The database administrator's (DBA) workload dropped significantly, requiring a system health check just “about once every two or three days." This freed up 75% of SOCRadar’s DBA resources, allowing them to pivot away from maintenance and focus entirely on core platform innovation.

Financially, AlloyDB’s dynamic storage management solved a massive cost efficiency issue. Unlike traditional database environments that lock you into paying for fixed, provisioned storage even after data is purged, AlloyDB automatically scales storage down to match actual data footprints. By clearing out legacy, unnecessary logs, SOCRadar was able to instantly reclaim over 45 TB of storage, achieving massive, automated cost optimization.

Fighting alert fatigue with integrated Gemini Enterprise Agent Platform

Beyond scaling infrastructure, AlloyDB has allowed SOCRadar to redefine the core architecture of their threat response using artificial intelligence.

Security operations centers (SOCs) globally are plagued by "alert fatigue"—the sheer volume of security alarms makes it easy to miss a critical attack. To solve this, SOCRadar integrated Gemini Enterprise Agent Platform as a core component of their solution architecture, linking it directly to their Alarm Management framework running on AlloyDB.

By running Gemini AI-native filtering directly on their active data workloads, SOCRadar can automatically distinguish between true positives and benign false alarms. The AI categorizes, filters, and routes alerts before they ever reach the end-user. This ensures security analysts are insulated from noise and receive only the most critical, validated, and actionable intelligence.

Expanding capabilities: The future of agentic threat hunting

With a high-performance foundation firmly established, SOCRadar’s dedicated AI team is transitioning from passive analytics to active automation. The company is currently testing Agentic AI workloads, with plans to roll them into production in subsequent phases.

By integrating Real-time Data Agents with Gemini Enterprise and AlloyDB, SOCRadar is transforming with autonomous agents that don't just store data, but actively hunt threats, reason over context, and take action. Their upcoming production roadmap includes:

Natural Language Querying (NLQ): Allowing analysts to conduct rapid threat hunting using conversational language, lowering the technical barrier to querying massive database sets.
Intelligent Semantic Similarity Search: Leveraging native vector embeddings and Gemini Enterprise to allow Data Agents to independently surface hidden patterns across historical logs that traditional keyword searches would miss.
Automated Incident Summarization: Instantly transforming hundreds of lines of complex, deeply technical logs into concise, plain-language executive summaries for security analysts during critical incidents.

By consolidating transactional velocity, historical depth, and built-in AI intelligence into a unified platform, SOCRadar has eliminated its data bottlenecks and built a highly automated, future-proof framework for global cybersecurity defense.

Ready to modernize your database infrastructure? AlloyDB provides a fully managed, PostgreSQL-compatible database with high performance for transactional, analytical, and AI workloads. Learn how you can reduce costs, eliminate management overhead, and build intelligent applications.

AlloyDB AI Functions - now with revolutionary performance boosts and cost savings

Wed, 01 Jul 2026 18:00:00 +0000

AlloyDB is an AI-native database—it isn’t just a passive data store, it intelligently understands and processes your data. With AlloyDB, you get industry-leading vector and hybrid search, near 100% accurate natural language-to-SQL capabilities to build conversational agents, tools to enable you to build with your agentic IDEs of choice, and the ability to bring the intelligence of foundation models like Gemini directly to your data through AI functions.

In this blog post, we discuss the massive breakthroughs in AI function processing alongside a suite of brand-new AI functions.

But first: what exactly are AI functions? They bring Gemini’s world knowledge to your AlloyDB data. Consider the challenge of managing raw user feedback: it’s unstructured, and difficult to parse through. Before this data can be leveraged for search, it may require pre-processing and entity extraction. Rather than maintaining complex custom pipelines for knowledge extraction, you can use Gemini’s generation capabilities directly within AlloyDB to transform raw text into structured, searchable insights. For example, here is how you can use ai.generate to instantly turn raw feedback into clean, structured JSON (see more examples here):

code_block: <ListValue: [StructValue([('code', "SELECT\r\n log_id,\r\n raw_content,\r\n -- Use Gemini 3.0 to reason through the raw user feedback and extract structure\r\n ai.generate(\r\n model_id => 'gemini-3.1-pro-preview',\r\n prompt =>\r\n 'Analyze this raw customer feedback entry. Extract the country, service name, and a 1-sentence summary of the feedback. Return as JSON.'\r\n || raw_content) AS structured_feedback\r\nFROM raw_feedback_logs\r\nWHERE user_type <> 'internal';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdc8440970>)])]>

Here is a sample result:

log_id	raw_content	structured_analysis
1001	2025-12-16 08:00:01 [ERROR] Service: OrderSvc \| DbConnectionTimeout: Failed to acquire connection from pool "primary-shard-04" after 5000ms.	{"errorCode": "DbConnectionTimeout", "serviceName": "OrderSvc", "rootCause": "The service failed to acquire a database connection from the primary shard pool within the 5000ms timeout limit."}
1002	2025-12-16 08:05:12 [WARN] Service: IdentityProvider \| 401 Unauthorized: Bearer token validation failed for user_id=9942. Signature mismatch.	{ "error_code": "401", "service_name": "IdentityProvider", "root_cause": "The bearer token validation failed due to a signature mismatch." }
1003	2025-12-16 08:12:45 [CRITICAL] Service: AnalyticsEngine \| OutOfMemoryError: Java heap space. Allocation of 1.2GB array failed. Heap usage 99%.	{ "error_code": "OutOfMemoryError", "service_name": "AnalyticsEngine", "root_cause": "The service exhausted available Java heap memory attempting to allocate a 1.2GB array." }
1004	2025-12-16 08:25:33 [ERROR] Service: WebFrontEnd \| 404 NotFound: Resource /api/v3/users/profile/settings not found. Upstream returned 404.	{ "error_code": "404", "service_name": "WebFrontEnd", "root_cause": "The requested API resource for user profile settings was not found by the upstream service." }
1005	2025-12-16 08:35:50 [WARN] Service: NotificationGateway \| GatewayTimeout: External provider "SendGrid" failed to respond within 30s. Retry scheduled.	{"error_code": "GatewayTimeout", "service_name": "NotificationGateway", "root_cause": "The external provider SendGrid failed to respond within the 30-second timeout limit."}

More functions to summarize and analyze sentiment

Our core AI functions —ai.generate, ai.rank, ai.if, and ai.forecast—are now Generally Available. To learn more about use cases for the first three, refer to this blog post. To explore the forecast function in action, check out this deep dive.

Building on this momentum, we have introduced three brand new functions: ai.summarize, ai.agg_summarize, and ai.analyze_sentiment.

ai.analyze_sentiment: Automatically classifies the emotional tone of text as positive, negative, or neutral.
ai.summarize: Condenses lengthy text into its most essential information while preserving the original tone and nuance.
ai.agg_summarize: An aggregate tool that processes multiple rows within a column to generate a single, unified summary for an entire group (e.g., via a GROUP BY clause).

Here’s an example of how to use ai.agg_summarize to consolidate a product reviews for products on a retail website:

code_block: <ListValue: [StructValue([('code', 'SELECT productname, ai.agg_summarize(review) as reviews_summary\r\nGROUP BY productname;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdc8440880>)])]>

Here is a sample result of summarized reviews for two gaming console products:

productname

reviews_summary

AlphaCore Console

Users praise the stunning 4K graphics, smooth 120Hz frame rates, and the highly ergonomic controller design.

However, several reviews express frustration over the loud cooling fan noise during extended gaming sessions.

Overall, it is considered a top-tier console despite minor thermal and noise complaints.

NeoCore Console

Customers love the exceptional battery life and vibrant OLED display for handheld gaming on the go.

A significant number of users noted that the UI can feel sluggish and the game library is currently limited.

It represents great value for casual gamers but power users may find the performance lacking.

The power of LLMs on your data: now significantly faster and cheaper

We now have achieved unprecedented performance and cost breakthroughs in AI function processing. Previously, running a foundation model call for every single row in a massive database introduced cost and latency constraints. We have shattered these barriers by introducing two breakthrough capabilities:

Smart Batching for AI Functions: This AI Function Acceleration capability provides intelligent batching of AI function calls for optimal performance and quality. This efficiency is achieved by deduplicating prompt overhead; the LLM's boilerplate instructions are transmitted once per batch rather than repeated across every individual row. A question you may have is - “Why not do this in my own application layer?”. That’s because, AlloyDB intelligently determines the right batch size for optimal results - if you underestimate the batch size, you won’t reap gains for cost and latency, and if you overestimate the batch size, the prompt to the LLM could get bloated and lead to hallucinations, or you could exceed the model's token limits. In addition to calculating the perfect batch size for every request, AlloyDB also handles retries automatically out of the box, ensuring your pipeline stays resilient. We did some testing internally and saw massive gains; for example, an up to 2,400x performance boost (processing 10,000 rows/sec) over traditional row-at-a-time LLM calls. This is currently available for the ai.if and ai.rank functions, with support for additional functions coming in the future.

Let’s look at an example of using Smart Batching / Acceleration with ai.if to solve this use case: Imagine a customer on a gadget retail site searching for a camera that can handle an underwater depth of '60 meters or deeper.' Traditional hybrid search will pull the closest semantic and full-text matches, but it misses the hard constraints of numerical data—meaning it might serve up a camera that works only at 20 meters depth. By using AlloyDB’s ai.if-based intelligent filtering, the database actually understands the nuance of depth and makes the query return products that meet or exceed that 60-meter depth criteria. Notice how, in the example below, you don’t need to specify the batch size - AlloyDB handles all the optimizations under the hood when using ai.if.

code_block: <ListValue: [StructValue([('code', "-- Smart Batching / AI Function Acceleration \r\nSET google_ml_integration.enable_ai_function_acceleration = on;\r\nSELECT productid, productname, category,description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdc8440cd0>)])]>

Here is a sample result on a hypothetical gadgets site. Notice how the expanded descriptions of products really match the criteria of working at a depth of 60 meters:

Optimized AI Functions: For even greater efficiency, we’ve introduced an optimized mode, starting with ai.if. By deploying a small, proxy model that utilizes your embeddings and is trained on your specific LLM outputs, we can process decisions natively within the database. This drastically reduces the need to call the external LLM - and based on some of our internal tests, we saw staggering gains; for example, up to 100,000 rows processed per second (a 23,000x improvement) and costs slashed by 6,000x (down to 1/10th of a cent). For technical insights on this technique, including when it works best and when not, refer to this blog post. AlloyDB does the following when using optimized ai.if:

Trains a proxy model: AlloyDB trains a lightweight proxy model on a sample of your data. This happens in the background when you use the PREPARE statement with ai.if function to train the model for optimized queries.
Executes the query: When you use the EXECUTE statement, AlloyDB uses the trained proxy model to process the query locally.
Falls back to the LLM: If the accuracy of the model is low, or if AlloyDB can't find a model, AlloyDB automatically falls back to using the LLM.

Let’s look at the same example of searching for a camera that can handle an underwater depth of 60 meters or deeper using optimized ai.if. Here we train a proxy model using the PREPARE statement and then EXECUTE the statement thereafter.

code_block: <ListValue: [StructValue([('code', "-- Prepare the Optimized Function / Proxy Model\r\nPREPARE waterproof_camera_60m AS\r\nSELECT productid, productname, category, description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description,\r\n description_embedding);\r\n\r\n-- Run the Proxy Model\r\nEXECUTE waterproof_camera_60m;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdc8440910>)])]>

You see the same products that truly match the criteria of working at a depth of 60 meters - as shown in the screenshot above. Here’s a tabulated version for the first three products, so you can look at the descriptions more closely:

productname	description
Pulsetron Action Camera MZ314	Conquer your next adventure with this camera. Don't let the elements hold you back; dive up to 60 meters deep or withstand rugged trails with its shock-resistant, adventure-ready chassis. Every jump, every turn, every splash is rendered flawlessly smooth with advanced Horizon Lock stabilization, ensuring your footage tells the story with unparalleled fluidity.
Hyperbyte Action Camera LG688	Capture the world in breathtaking detail, even when the action is at its most intense. This camera packs a formidable 1-inch sensor into a remarkably tough, pocket-sized frame. Shoot stunning 5K video and crystal-clear 20MP stills that rival professional equipment. Dive deeper than ever before with robust waterproofing at 60 meters.
Alphasync Action Camera WW897	This formidable, compact camera shrugs off the elements, while the massive 1-inch sensor translates every breathtaking moment into stunning 5K video and crystal-clear 20MP stills. Conquer any environment – from the deepest dive to the highest peak – thanks to its 60 meter waterproofing and revolutionary Horizon Lock, ensuring your footage remains impossibly steady.

See it in action!

Watch how this all comes together in this demo video.

Getting started is easy

Ready to bring unprecedented speed and cost-efficiency to your AI workloads?

New to AlloyDB? Discover AlloyDB with a 30-day free trial.
AI functions quickstart: Enable a few quick prerequisites and start calling functions like ai.if, ai.generate, or ai.analyze_sentiment directly within your SQL queries. Check out these practical examples to begin.
Boost performance and optimize costs: To unlock the biggest performance and cost gains, follow our guide on optimized functions. This is available in preview for ai.if, and will be expanding to more functions soon. For technical insights on this technique, including when it works best and when not, refer to this blog post.
Scale your throughput: Use smart batching to accelerate AI functions (available in preview for ai.if and ai.rank) or array-based functions (generally available for all LLM-based AI functions) to handle bulk prompting smoothly.

Modernizing financial services with deployment freedom and transformational AI with AlloyDB Omni

Tue, 30 Jun 2026 16:00:00 +0000

The financial services industry (FSI) operates under a unique set of non-negotiable requirements: the need for strict regulatory compliance, sub-millisecond transactional speeds, and security that verges on impenetrable. Historically, organizations have met these standards by relying on brittle, proprietary database systems, leaving them with massive technical debt, operational overhead, and vendor lock-in.

At the same time, financial services companies are facing a series of daunting challenges:

The licensing trap and technical debt: Decades of reliance on legacy commercial databases have left institutions with skyrocketing maintenance costs and restrictive licenses that refuse to scale. In fact, a global investment bank might find that over 70% of its IT budget is swallowed up by decades-old COBOL core banking systems and siloed ledger databases—leaving virtually no capital to develop the real-time, AI-driven fraud detection tools their clients are actively demanding.
The tug of war between sovereignty and innovation: Emerging regulations like EMEA’s Digital Operational Resilience Act (DORA) and strict national data residency laws require institutions to maintain ironclad control over where their data lives. This often creates a massive barrier to public cloud adoption for sensitive workloads, effectively siloing a regional payment processor from modern AI tools simply because they cannot legally move transaction data to a public cloud for processing.
The "insights gap" in real-time operations: While agile fintech upstarts launch with flexible, cloud-native architectures, traditional firms struggle to turn vast data reserves into actionable intelligence. Their data is trapped in legacy environments that hit a performance ceiling during peak market volatility, leaving an investment firm struggling to scale its high-frequency trading ledgers when standard PostgreSQL or legacy systems max out.

As the industry enters the era of Agentic AI — where autonomous AI agents handle complex workflows like real-time risk assessment and automated trading — financial services firms must adopt a fundamentally new database strategy.

To overcome these entrenched challenges, they need to shift their strategy, moving away from proprietary databases that lock them in toward a hybrid, open-standards-based paradigm. This allows them to embrace the best of cloud-native innovation , like empowering real-time agentic AI workloads and edge computing , while maintaining control and residency of their own data on-premises.

At Google Cloud, we designed AlloyDB for PostgreSQL to unify operational data, real-time analytics, and generative AI into a single platform, and you can run it anywhere. Further, it specifically addresses the above mentioned FSI challenges directly through three guiding principles:

The licensing trap -> open standards: AlloyDB is 100% PostgreSQL-compatible, allowing institutions to modernize from expensive, legacy proprietary databases to an open platform that minimizes licensing headaches and vendor lock-in.
Sovereignty -> heterogeneous support: With AlloyDB Omni’s flexible deployment model, organizations can keep up with the complex topologies that characterize global banks, allowing mission-critical applications to run in a hybrid cloud, at the edge, or on-prem in air-gapped environments.
The insights gap -> battle-tested scale: By incorporating architectural lessons from Google's billion-user applications, the cloud-managed AlloyDB service delivers superior performance, running over 4x faster for transactional workloads than standard PostgreSQL. Crucially, the downloadable AlloyDB Omni engine brings this exact same high-concurrency scaling power straight to your local hardware—outperforming standard PostgreSQL by over 2x for transactions—while both deployment models accelerate real-time analytical queries by up to 100x.

Institutions are already realizing the benefits of this new approach:

Cynergy Bank: By migrating from on-prem SQL databases to AlloyDB, the bank successfully modernized a key element of its infrastructure. This critical initiative reduced app account loading times to under three seconds and enabled the integration of data and AI, providing a more personal "human touch" to digital banking and financial services.
Apex Fintech: The company leveraged AlloyDB to speed up margin calculations by 50%, enabling them to calculate risk for 100,000 accounts in just one minute while eliminating the need for a separate analytical system.

To ensure financial institutions can leverage these exact same breakthrough database innovations anywhere—without being forced into a public cloud migration—we built AlloyDB Omni to extend our signature kernel performance directly to your owned infrastructure.

AlloyDB Omni: Strong performance and deployment freedom

Whether running mission-critical applications on-premises, at the edge, or across hybrid clouds, financial institutions shouldn't have to choose between deployment flexibility and database performance. AlloyDB Omni bridges this gap by bringing Google’s breakthrough kernel innovations directly to your infrastructure. By design, it delivers enterprise-grade capabilities across three core dimensions:

True portability and modernization in place: Take absolute control over your data residency. Deploy AlloyDB Omni on-premises or at the edge to help comply with strict data sovereignty laws and regulations. This allows you to upgrade your legacy estates right where they live, avoiding the immense operational risk, latency, and vendor concentration risks of a forced public cloud migration.
Operational simplicity on your terms: Manage your databases like any other modern application. AlloyDB Omni is deployable across containerized environments, bare metal, or VMs. By leveraging tools like our Kubernetes Operator to automate routine provisioning, backups, and failovers, your platform teams gain integrated, API-driven control that elevates the database into a first-class citizen of your infrastructure alongside compute and storage. For non-containerized setups, Omni can be downloaded as a standalone RPM and managed with CLI or Ansible automation, and it is fully validated to run on Google Distributed Cloud (GDC) for the most restrictive air-gapped workloads.
Shattering the PostgreSQL performance ceiling: While standard PostgreSQL is highly trusted, high-concurrency financial workloads often hit a scaling wall. AlloyDB Omni breaks through these limits directly on your local hardware:

Superior transactional scalability: Delivers up to 2x faster transaction processing than standard PostgreSQL, ensuring payment processing and high-frequency trading ledgers maintain ultra-low latency even during volatile operational spikes.
Real-time analytics (HTAP): An intelligent, built-in columnar engine accelerates analytical queries by up to 100x. This enables instant, local business intelligence and reporting directly on live transactional data without the latency of moving it to a warehouse.
Secure, local AI transformation: Build fraud detection, risk modeling, or semantic search applications locally. AlloyDB Omni includes integrated AlloyDB AI vector capabilities—featuring a ScaNN index that is up to 10x faster and 4x more memory efficient than standard PostgreSQL's HNSW index. This allows you to scale generative AI apps while keeping sensitive financial data and foundation models strictly within your secured infrastructure boundaries.

Enterprise-grade security and compliance

Security cannot be an afterthought. We built AlloyDB Omni to exceed the rigorous standards of the finance industry, offering a hardened posture out of the box. AlloyDB includes:

Granular access and auditing: AlloyDB Omni integrates with Active Directory for unified identity management and provides detailed audit logging to track every access event — essential for regulatory audits.
Compliance-ready infrastructure: By utilizing features like Transparent Data Encryption (TDE) at rest, AlloyDB Omni is specifically engineered to help you meet your regulatory compliance obligations.

By providing a platform that is secure by design and that can be flexibly deployed in a variety of configurations, AlloyDB Omni enables financial institutions to stop choosing between stability and innovation and start delivering both.

Next steps

To learn more and get started, please visit https://cloud.google.com/alloydb/omni. You can learn more from the AlloyDB Omni documentation.

AlloyDB Omni is covered by the Google Cloud support plan the customer has chosen for their Google Cloud account; more information on support can be found at https://cloud.google.com/support.

Technology partners, system integrators and ISVs play an important role in helping customers modernize and build differentiated applications., We are extending the AlloyDB Cloud Ready program to now include AlloyDB Omni and enable our partner ecosystem to bring the best of what AlloyDB Omni has to offer to their customers. Customers can trust these validated partner products to work well with AlloyDB Omni, and can focus their time on modernizing database workloads and applications that will drive value for their business.

Get started with AlloyDB Omni by downloading and deploying in your preferred location, including on your laptop!

Supercharging the agentic era with Spanner’s multi-model architecture

Mon, 29 Jun 2026 23:00:00 +0000

In the agentic era, the role of the database has fundamentally changed. It is no longer a passive repository; it’s a critical context engine designed to ground generative AI apps, models and power autonomous workflows. To do this effectively, databases must move beyond fragmented architectures and embrace a unified, multi-model foundation, facilitating deep reasoning and transforming static data into a system of action.

Spanner is leading this charge, and as a foundational pillar of Google’s Agentic Data Cloud, the industry is taking notice. In the 2025 Gartner® Critical Capabilities for Operational Cloud Database Management Systems report, Google (Spanner) ranked #1 in the Lightweight Transactions Use Case for the second consecutive year — in our opinion proving it is the most efficient engine for modern microservices and event-driven architectures.

Gartner® Operational Cloud DBMS use cases:

#1 in Lightweight Transactions
4.9 / 5.0 for Transactional Consistency
4.6 / 5.0 for AI/Machine Learning and GenAI

This technical momentum, which also recently earned Spanner the prestigious SIGMOD Systems Award, is matched by undeniable economic value. A recent Forrester Consulting Total Economic Impact™ (TEI) study commissioned by Google Cloud found that an organization (based on composite customer profile from Forrester’s survey) realized a 132% ROI with a fast 9-month payback period, yielding $7.74M in total benefits over three years having deployed Spanner.

The multi-model advantage for the agentic era

True AI autonomy requires deep context. To reason effectively, an AI agent cannot look at data through a single lens; it must simultaneously understand structured history (relational), semantic meaning (vectors), real-world connections (graphs), and textual details (full-text search).

Spanner natively breaks down these multi-model barriers. Instead of forcing you to stitch together disparate engines, Spanner unifies relational, vector, graph, key-value, and full-text search data directly within a single, highly performant database architecture. This architectural integration allows AI models to leverage situational, semantic, and relationship context instantly and concurrently.

Spanner’s fully interoperable multi-model capabilities allow organizations to build intelligent applications without compromise:

Spanner Graph: A unified graph and relational experience built on the ISO-standard GQL. You can model data natively as a graph or as an overlay on top of relational data, which is critical for building knowledge graphs that ground AI agents in real-world facts. Customers like Palo Alto Networks leverage Spanner Graph to power crucial access-control use cases at planet-scale, securing their AI infrastructure without needing a specialized, siloed graph database.
Integrated vector search: A fully integrated semantic search solution offering both K-Nearest Neighbors (KNN) and Approximate Nearest Neighbor (ANN) search, capable of supporting indexes with over 10 billion vectors for fast, low-latency retrieval-augmented generation (RAG).
Relational and key-value: Spanner pioneered the relational scale-out database (Google SQL and PostgreSQL). We've also introduced high-performance key-value capabilities via a Cassandra-native endpoint, allowing for easy lift-and-shift of Cassandra workloads.
Full-text search: Building on Google's decades of search expertise, Spanner provides advanced information retrieval across structured and unstructured data, including an enhance_query option for automatic synonym matching and spell correction. Streaming legal intelligence platform Inspira simplified a 4.5 TB data pipeline into a unified, high-performance single-source of truth. Leveraging Spanner’s native support for FTS and vector search capabilities Inspira achieved high-precision snippets for LLM-based legal analysis with RAG workflow.
Spanner columnar engine: This architectural breakthrough enables analytical queries to run up to 200× faster on live operational data, bridging the gap between OLTP and analytics to provide agents with real-time context without the "ETL tax." AI-powered fraud prevention platform Verisoul uses the columnar engine to run rich analytics on high-velocity transactional writes in one place, eliminating data copies and replication lag to get near-instant answers.

True interoperability means these aren't just isolated features , they are tightly integrated. Instead of writing complex application logic and brittle ETL pipelines to stitch together a graph database, a vector database, and a search engine, developers can query relationships, semantic meaning, and keywords in a single, ACID-compliant SQL statement.

Here’s an example of how a developer can combine relational, graph traversal, full-text search, and vector similarity search in one cohesive query to power an intelligent product recommendation agent:

Spanner Omni: Multi-model capabilities, everywhere

To truly be the unified data foundation for the Agentic Data Cloud, a database cannot be confined by infrastructure borders. That’s why we expanded our vision with Spanner Omni, bringing these multi-model capabilities to any environment without hardware restrictions, just as we did with AlloyDB Omni.

Spanner Omni is a downloadable version of Spanner in a fully containerized deployment model that requires absolutely zero dedicated hardware. It is designed with maximum flexibility in mind, running natively on Kubernetes using the infrastructure you already own. Whether your workloads are running on-prem, at the edge, or across other major public clouds like AWS and Azure, Spanner Omni gives you control and helps ensure you have a consistent, globally distributed data foundation.

This means organizations can leverage Spanner Graph, vector search, full text search, and our columnar engine anywhere, effectively breaking down cloud silos and making these cutting-edge capabilities available without vendor lock-in.

Industry-defining capabilities for core databases

In the 2025 Gartner® Critical Capabilities for Cloud Database Management Systems for Operational Use Cases, for the second consecutive year, Gartner ranked Google (Spanner) #1 in the Lightweight Transactions Use Case. We believe this a testament to its efficiency and low latency for modern, event-driven microservices.

In our opinion, this industry recognition goes far beyond simple market presence, it is validated by deep foundational technical breakthroughs that separate Spanner from legacy architectures. Unlike platforms that bolt disparate, siloed database engines together and label it as "multi-model," or require users to select the modality at the time of database creation with no interoperability between modalities, Spanner’s capabilities are built on a bedrock of Google’s most advanced computer science:

TrueTime and Paxos for global consistency: Spanner’s distributed transactions are governed by TrueTime — a highly available, globally synchronized clock system utilizing GPS and atomic clocks. This enables lock-free distributed reads and strict external consistency globally. Combined with highly optimized Paxos consensus, Spanner delivers synchronous replication with zero data loss (Recovery Point Objective, i.e. RPO=0) and rapid recovery timelines (Recovery Time Objective, i.e. RTO=0) even during total regional failures.
Integrated columnar engine: To eliminate the ETL tax and bridge the gap between OLTP and OLAP, we integrated a breakthrough columnar engine directly into Spanner's distributed storage layer (Colossus). This allows developers to run complex analytical queries to run up to 200x faster directly on live, operational data without impacting transactional performance. And with full separation of storage and compute, users are able to run large analytical queries without impacting the operational workload using Spanner DataBoost, a serverless technology that directly accesses the database storage.
ScaNN-powered vector search: Our native vector search isn't a bolted-on afterthought. It’s powered by Scalable Nearest Neighbors (ScaNN) — the exact same state-of-the-art indexing algorithm that powers Google Search and YouTube. This allows Spanner to execute sub-millisecond similarity searches across 10-billion-plus vector indexes natively alongside relational and graph data.
Dynamic resharding: Under the hood, Spanner's architecture automatically reshards data based on size and load. This transparent load balancing eliminates the dreaded "hotspotting" that plagues legacy NoSQL and distributed SQL systems.

While some industry evaluations often measure the market through a fragmented lens of disconnected database engines, we believe true innovation requires engineering for this level of deep, architectural integrations. For the agentic era, anything other than a natively unified foundation is simply a bottleneck.

A unified vision for the agentic era

We believe that the future of data is unified, open, and inseparable from AI. Spanner’s momentum reflects a market rapidly shifting away from a patchwork of isolated databases towards a singular, intelligent context hub.

To meet this future head-on, we are relentlessly expanding what is possible with a single unified database. This includes breakthrough innovations like our integrated columnar engine for real-time analytics, native vector search powered by Google's world-class ScaNN technology, and built-in AI functions that bring model inference directly to your data. Furthermore, by integrating Spanner Graph integrated with Graph Neural Networks (GNNs) for deep predictive reasoning, and Spanner Omni to extend this unified architecture across hybrid and multi-cloud environments, we are delivering a platform designed for what comes next.

Crucially, Spanner does not exist in isolation; it is a foundational pillar of Google’s broader Agentic Data Cloud. Through seamless, zero-ETL integrations across our Data Cloud Including BigQuery for enterprise-wide analytics and Gemini Enterprise Agent Platform for advanced model orchestration, Spanner breaks down the barriers between operational data and enterprise intelligence.

In the agentic era, AI models require more than just isolated data points; they need a cohesive ecosystem. By natively federating real-time operational context from Spanner with petabyte-scale historical insights from BigQuery, we empower agents to act autonomously, reason deeply, and drive unprecedented business value.

By providing a real-time, trustworthy, and multi-faceted view of data, regardless of where it lives, Spanner empowers organizations to build the next wave of transformative, intelligent applications.

We are incredibly excited about the journey ahead and will continue to pioneer the frontiers of what a true multi-model database can achieve.

Try Spanner 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.

^{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.}

How Atlas scales hundreds of merchant databases with Cloud SQL Enterprise Plus edition

Tue, 16 Jun 2026 16:00:00 +0000

Atlas is building the operating system for restaurants. Online storefronts, point of sale, third-party logistics, food platform integrations, customer loyalty, and AI tools represent everything a restaurant needs to start, run, and grow. We work with brands like SaladStop, Killiney, Haidilao, Raffles Hotel, Lo and Behold Group and the Les Amis Group in Singapore, helping merchants increase basket sizes, grow sales, and reduce operational costs.

Every merchant on Atlas gets their own dedicated Cloud SQL for PostgreSQL database. Restaurants are very different from each other. A single-outlet cafe and a multi-outlet chain should not look the same underneath. Isolated databases give us full data separation, predictable performance even during peak lunch and dinner rushes, and the flexibility to scale, tune, or migrate each merchant independently. As Atlas grows, the number of databases grows with us.

The challenge: Scaling beyond standard

We started on the standard Cloud SQL Enterprise edition. It was a solid foundation, but as we onboarded more merchants and shipped more features, the operational layer required to manage our databases became a bottleneck.

We were managing connection pooling as a separate layer, which meant more services to run, secure, and monitor. When a query caused a CPU spike, we needed to know exactly what happened and which merchant triggered it, but we were spending too much time reconstructing problems from limited signals. With a lean team and no dedicated database engineers, every extra component multiplied the maintenance load.

The shift to Enterprise Plus edition

When we needed to provision new database instances, the Google Cloud team introduced us to Cloud SQL Enterprise Plus edition. We were already asking ourselves how much more operational overhead this was going to add, and what stood out was that Enterprise Plus edition removed whole categories of work we would otherwise have to own.

Managed connection pooling: Now built directly into Cloud SQL, we no longer run pooling as a separate layer. This means fewer moving parts, less to maintain, and a smaller security surface area.
Query insights: This was the most impactful feature for our needs. We can now see exactly which queries are expensive and which merchant is triggering them. It turns performance tuning from guesswork into something concrete and actionable. For a platform running hundreds of databases, this visibility is a "superpower."
Data cache: This keeps read performance consistent even as merchant datasets grow. Since restaurants generate more data every day, the data layer needs to stay fast as that complexity compounds.
Near-zero downtime scaling: We can now scale instances as merchants grow without disrupting service during off-peak hours.

After seeing the results on the new instance, we migrated all our existing databases to Enterprise Plus edition as well.

The impact: Focus on innovation, not plumbing

Atlas today powers thousands of restaurant outlets, processes tens of thousands orders daily using hundreds of managed databases. The biggest change is where engineering time goes. We spend 30% less time on database operations and more time building products. Merchant onboarding got simpler because a new merchant is provisioned in seconds with a ready-to-use managed database. We are much more proactive on performance now, catching and fixing issues before they reach merchants. Day to day, we are not thinking about database plumbing. We are thinking about how to serve merchants better and that has allowed Atlas to grow 200% to 300% year over year.

Looking ahead: An AI-first future

We are investing deeply in AI, both internally and externally. Internally, we have gone all in on agentic engineering through AI-assisted development workflows that let a lean team build, review, and ship code significantly faster. Externally, we are building AI-powered tools that help restaurant operators make better decisions and act on them. We have a lot of experimental ideas on the roadmap, including new product surfaces and new ways to help restaurants grow. The thing that gives us confidence to move fast on all of this is that the foundational layer, Cloud SQL and Google Kubernetes Engine (GKE), is battle-tested and does not get in the way.

Google Cloud handles the infrastructure complexity. Atlas stays focused on building the best tools for restaurants.

Cloud SQL Enterprise Plus gave us a database architecture that is flexible, observable, and easy to scale. We are not thinking about infrastructure anymore, we are thinking about our merchants. As we go deeper on AI and continue growing the platform, Google Cloud gives us the confidence to move fast without worrying about what is underneath.

Ready to scale your database architecture?

Don't let infrastructure bottlenecks slow down your innovation. Whether you are managing tens or hundreds of databases, see how Google Cloud SQL can streamline your operations, enhance observability, and give your engineering team the freedom to focus on what matters most.

Explore Cloud SQL Enterprise Plus edition today
Sign up to try Cloud SQL for free.

What’s new in data agents: Supercharging your AI workflows

Mon, 15 Jun 2026 17:00:00 +0000

The rise of AI agents is fundamentally disrupting applications and analytical systems. Generic AI platforms don't usually have access to the context stored within enterprise databases. This is because traditional data architectures often lack context for agents across the data estate, which can lead to agents being inaccurate. They’re also prone to security gaps due to a lack of granular access controls.

Google’s Agentic Data Cloud is an AI-native system of action that includes both operational and analytical systems. By infusing AI across the entire stack — from custom silicon to frontier Gemini models — we provide a deterministic, template-driven developer framework that allows agents to ground their reasoning in real-time enterprise data with near-100% accuracy, as well as unified governance.

Today, we’re making it easier to develop agents, with a whole host of new data agents and tools: for business analysts within Conversational Analytics; for data scientists, engineers, and database admins with a series of Google-built Data Agents that provide greater automation and intelligence; and finally, for developers, with Data Agent tools that help you better integrate with today’s open agentic ecosystem.

1. Conversational Analytics

To support developers building agents using natural language, we’re announcing expanded support for Conversational Analytics across Data Cloud.

Conversational Analytics in BigQuery integrates a sophisticated AI reasoning engine directly into BigQuery Studio, helping data and business teams go beyond writing manual SQL, leveraging business context to ground answers using multimodal synthesis and deep-dive research. Agentic workflows, in preview for select customers, automate root-cause analysis, and schedule actions — turning enterprise data into proactive, actionable intelligence.

Create agents for faster data insights with Conversational Analytics in BigQuery

Conversational Analytics in Lakehouse, now in preview, extends the Lakehouse unified infrastructure, so users can query distributed data lakes across AWS, Azure, and Google Cloud using natural language. This makes it possible to combine insights across cloud platforms without moving a single byte of data.

Conversational Analytics in AlloyDB, Spanner, and Cloud SQL, now in preview, supports out-of-the-box conversational AI, making data accessible for everyone. AlloyDB, Spanner, and Cloud SQL users can start natural-language conversations with their databases to gain visibility into their real-time operational data and capture analytical insights.

Use Conversational Analytics to get answers from your operational data

Looker Embedded Conversational Analytics, now generally available, allows you to embed agents directly into your custom applications and internal workflows via a low-code iframe implementation, making it easier to ship production-ready, conversational AI within any application. Additionally, with the Conversational Analytics API in Looker, you can create multi-turn conversational workflows that offer AI-powered recommendations, while also verifying and explaining the underlying SQL query. We are also significantly upgrading Looker’s core Conversational Analytics agent, which is already GA, with superior reasoning and semantic grounding, helping to eliminate ambiguity.

Embed agents directly into your applications for conversational AI

2. New data agents

To help data professionals move from reactive data management to proactive intelligence, and business analysts better interact with their dashboards, we’re announcing a new set of data agents that bring automation, intelligence, and natural language capabilities into their daily workflows.

Data Engineering Agent, now generally available, automates the heavy lifting of building and maintaining data pipelines. It transforms natural language requirements into optimized SQL or Python code for BigQuery and Dataflow, while proactively identifying and fixing pipeline breaks. By suggesting schema improvements and partitioning strategies, it ensures your data foundation is scalable, reliable, and performance-tuned without manual trial and error.

Data Science Agent accelerates the path from raw data to production-ready models. It assists data scientists by suggesting relevant features, generating boilerplate notebook code, and automating the technical documentation process.

Database Observability Agent, in preview with select Cloud SQL, AlloyDB, Spanner, and Bigtable customers, proactively monitors database performance and continuously identifies potential issues before they escalate. It then delivers intelligent recommendations and multi-turn remediation workflows for fast, comprehensive troubleshooting and optimization. It provides performance analytics for the entire database fleet, helping you quickly identify performance optimization opportunities across databases.
Database Onboarding Agent, in preview with select customers, takes the guesswork out of database selection and deployment. By evaluating your stated requirements — from simple use case descriptions, to complex enterprise needs — it recommends the best Google Cloud database and guides you through provisioning.
Looker Dashboard Agent, now in preview, enables conversational interaction with data within dashboards. Users can ask natural language questions and receive context-aware answers within the dashboard. This feature also provides AI-generated summaries that highlight key takeaways and insights from the dashboard.
Conversational Analytics in Gemini Enterprise, now in preview for Looker, BigQuery, and Lakehouse, brings governed intelligence built by data practitioners directly to business leaders. It serves as a "front door" to the Google Data Cloud, allowing business users to consume agents built in BigQuery, Looker, or Lakehouse without needing to access technical consoles. By publishing these agents from Google Data to Gemini Enterprise, organizations provide a single, grounded interface for precision data exploration and immediate answers to the business users.

Deep Research Agent, now in preview, uses the Knowledge Catalog to solve high-stakes, multi-layered business problems. It moves beyond simple search to build comprehensive research plans that synthesize intelligence from internal documents, BigQuery tables, and the public web. The result is a detailed report with dynamic visualizations and verifiable citations, that respect enterprise privacy and user permissions all the while.

3. Tools for data agents

Open-source standards for agentic development provide developers building AI applications and custom agents with a unified framework to access data and tools consistently and securely. Today, we are announcing the following tools to help ground your agentic development initiatives:

Data Agent Kit: now in preview, provides a standardized suite of skills and tools directly within preferred developer environments (IDE/CLI), empowering data practitioners to discover, transform, and action data at scale using the prescriptive guidance from the Agentic Data Cloud capabilities.
Managed MCP Servers for Databases, now generally available for AlloyDB, Spanner, Cloud SQL, Bigtable, and Firestore, fully manages the infrastructure required to connect AI models securely to your data, so you don’t have to host, secure, or scale MCP servers yourself. Now, developers can provide their agents with up-to-date context from across our database portfolio, so that your AI models can reason and act upon your most up-to-date enterprise data.
Managed MCP Server for Looker, now in preview, allows any MCP client or agent platform to query Looker's semantic models, extending governed BI insights across third-party applications.

Access Looker semantic models through Managed MCP Server

MCP Toolbox for Databases 1.0, now generally available, has achieved a major stability milestone, giving you the confidence to build production applications. We also overhauled the documentation, making the platform significantly more approachable for both human developers and autonomous agents.
QueryData for Cloud SQL, AlloyDB, and Spanner, now in preview, turns natural language questions into database queries. It’s built natively into these databases, and provides near-100% accuracy for natural language to SQL conversions through metadata, query examples, and evals.
Universal Commerce Protocol (UCP) Analytics powered by BigQuery, now in preview, enables merchants and developers to stream real-time events from UCP directly into BigQuery (see sample). This integration provides out-of-the-box observability for agentic commerce, allowing teams to monitor conversion funnels, track automated checkout performance, and identify system errors. By standardizing these metrics within BigQuery, businesses can bridge the gap between AI-driven transactions and existing business intelligence workflows.

Details on how to access the new agents and tools can be found from each of the documentation links on this page. Data agents are also available through Gemini Enterprise and the Google Cloud console.

Architecting a trusted agentic platform with graph technologies: A Yahoo case study

Mon, 15 Jun 2026 16:00:00 +0000

As enterprises adopt agentic AI, they need to shift from reactive systems of intelligence to proactive systems of action to equip the agents they’re building with the context and performance they need, plus regulator-grade accountability, where every decision is explainable and auditable.

At Google Cloud Next ‘26, we discuss how our Agentic Data Cloud enables a system of action, and Yahoo’s digital media buying platform is a compelling example of this vision. Yahoo partnered with Google Cloud to build its Seller Agent digital media buying platform using Google Data Cloud graph technologies. Seller Agent condenses multi-week manual processes into fully governed, live campaigns that can be executed in just seconds. Ultimately, this agentic platform serves as a powerful blueprint for multiple industries, demonstrating that autonomous systems can operate at remarkable speed while remaining strictly accountable.

"Yahoo's mission is to be a trusted guide through the digital world. In partnership with Google Cloud, we're extending that promise to advertisers: agentic media buying that's fast, transparent, effective, and built to be trusted." - Gabriel DeWitt, Head of Monetization, Yahoo

In this blog, we explore the shift toward agentic AI, examine how Yahoo’s Seller Agent architecture solves for speed and trust in media buying, and show you how to apply this graph-based pattern to build trusted systems of action in your own organization.

Case study: agentic media buying

For years, complex, high-value workflows—like premium digital advertising campaigns—have required weeks of human handoffs, fragmented spreadsheets, and manual analysis. Yahoo recognized that agentic AI could collapse this timeline, allowing agents to plan and execute campaigns in mere seconds. This leap from manual to autonomous execution represents a massive opportunity to reclaim operational efficiency and ensure more of every dollar reaches measurable outcomes.

But simply dropping LLMs into a high-stakes workflow does not solve the problem; an agent attempting to negotiate contracts or ad placements without a deterministic understanding of real-time inventory, pricing rules, and business constraints is prone to hallucinate — potentially resulting in disastrous deals. A trusted agentic platform requires a definitive, real-time source of truth, ensuring it acts on hard facts rather than statistical guesses.

Furthermore, speed and factual grounding are only half the equation. The moment an AI agent starts moving real budgets, it faces scrutiny from regulators who demand instant answers to why specific decisions were made or which policies were applied. Digging through raw system logs after the fact is the wrong control surface for autonomous execution. Real-world systems of action require regulator-grade governance and auditability built directly into the workflow, not bolted on as an afterthought.

The architecture of a trusted system of action

Yahoo's mission has always been to be a trusted guide through the digital world. Agentic media buying extends that promise to advertisers, agencies, publishers, and regulators who entrust Yahoo with their budgets — and expect real accountability. The issue was automating campaign execution in a way that was explainable, governable, and auditable.

To meet this challenge, Yahoo built its Seller Agent as a multi-agent system running on Google Cloud. Buyer requests enter through a planning supervisor agent running on Google Kubernetes Engine (GKE) and orchestrated with Google's Agent Development Kit (ADK). The supervisor decomposes each request into specialized tasks including inventory discovery, audience matching, forecasting, pricing analysis, package recommendation, governance review, and execution. Agents coordinate through the open Agent2Agent (A2A) protocol, while Gemini Enterprise Agent Platform hosts models for embeddings, forecasting, and graph learnings.

But the true breakthrough — what makes autonomous execution both fast and fully transparent — is the platform’s dual-graph foundation. The platform is anchored by two specialized graph systems with an intentional separation of duties: a knowledge graph that’s optimized for acting, and a second context graph for remembering and learning.

"As the industry moves from systems of intelligence to systems of action, the constraint on autonomous AI shifts from model capability to whether a business can trust what an agent does unsupervised. Autonomous systems must record why decisions were made and learn from outcomes. That trust is earned through robust data infrastructure. We built that foundation with Google Data Cloud: a knowledge graph for operational truth in Spanner Graph, a context graph for decision lineage in BigQuery Graph — the blueprint for enterprise-scale agentic platforms." - Swapnil Patel, Senior Director and Head of Monetization Engineering, Yahoo

The knowledge graph: Grounding agents in business reality

Powered by Spanner Graph, Yahoo’s knowledge graph represents its monetization business as a connected operational model, grounding every agent decision in business reality. It models advertising products, placements, audience segments, inventory, contracts, and governance controls as first-class entities and relationships. Crucially, policies live directly within the graph as versioned relationships rather than being buried in application logic. This design allows the system to evaluate products, contractual obligations, consent requirements, and regulatory constraints together in a single, unified graph traversal.

The graph acts as a semantic contract across the agentic platform. During campaign evaluation, an agent can navigate from initial buyer requirements to eligible audiences and governing policies within a single query plan. Gemini Enterprise Agent Platform embeddings enrich these entities with semantic similarity, while graph neural networks contribute inferred relationships. Ultimately, this allows agents to do more than just retrieve available inventory — they understand exactly why it is relevant and help ensure it satisfies all governing constraints.

Yahoo’s knowledge graph ontology, aligned with industry standards like IAB AdCOM

The context graph: creating an auditable memory

Execution at agent-scale is only safe if it is entirely transparent — which is the core function of the context graph. Every time the Seller Agent takes an action, that exact operational span is captured by the BigQuery Agent Analytics plugin. In addition to logging the raw events, the system shapes this evidence into a typed, queryable context graph using BigQuery Agent Analytics SDK utilizing Yahoo's decision-trace ontology, stored in BigQuery Graph.

Consequently, every decision point, candidate package, policy evaluation, specialist-agent delegation, and execution outcome becomes a connected graph of evidence. Because this trace is structured as a typed graph, explaining the agent’s decision making process becomes a simple query. An auditor can instantly trace a decision from the originating campaign brief through every score that’s assigned and policy that’s applied. This transforms autonomous behavior from an opaque process into a fully transparent and continuously improving record of decision-making, helping to ensure absolute accountability.

Yahoo’s context graph ontology

From human to agent scale

For a concrete example of the architecture in action, consider an ad campaign run. What traditionally required weeks of coordination across planning, sales, operations, and compliance can now be completed in seconds through two simultaneous processes.

Acting via the knowledge graph. This pipeline moves the budget, navigating linearly from the buyer's request to a live campaign ground on the knowledge graph. This proceeds in four steps:

Submitting the brief: A buyer agent submits a campaign brief over Ad Context Protocol (AdCP) that describes the desired audience, budget, geography, and business objective.
Knowledge retrieval: The Seller Agent queries the knowledge graph to identify relevant inventory, audiences, contractual availability, historical performance, and governing policies.
Evaluation and scoring: The agent evaluates these factors together to assemble a package of media buying candidates. Forecasting models score the opportunities, while a governance agent independently reviews consent, brand safety, and regulatory constraints.
Approval and execution: The package is either approved automatically under policy thresholds or escalated for human review. Once approved, the media buy is executed and activated.

Auditing and learning via the context graph. While the execution pipeline moves forward, this parallel loop continuously captures the system's reasoning in the context graph, helping to ensure transparency and improve future cycles. This offers the following capabilities:

Continuous capture: Every candidate considered, score assigned, policy applied, and governance decision becomes a connected record in the context graph, linked to the originating campaign session.
Closed-loop learning: As delivery, attribution, and outcome signals arrive, they are joined back to the decisions that produced them, creating the training data that improves future recommendations.
Instant explainability: If an advertiser asks why a particular package was selected or which policies influenced the outcome, the answer is preserved in the context graph and reachable through a single query.

The result is a platform where knowledge, decision-making, governance, measurement, and learning operate together — allowing autonomous media buying to remain explainable, auditable, and continuously improving.

A blueprint for many industries

The era of AI as a mere advisor is ending. Enterprises are demanding systems of action — autonomous agents capable of executing complex, multi-step workflows. But in regulated sectors, the speed that AI brings to the table turns into a liability if you cannot prove how a decision was made. The primary barrier to autonomous execution is no longer intelligence; it is trust.

The architecture that Yahoo and Google Cloud built provides a broadly applicable blueprint with which to solve this. While designed to fix the bottlenecks of digital media buying, the underlying pattern applies to any industry managing high-stakes decisions — from financial trading to supply chain logistics. To operate at agent speed but still maintain human oversight, enterprises must adopt a new architectural baseline that:

Grounds decisions in business reality: Agents cannot rely on probabilistic models alone. They must be grounded by a knowledge graph that deterministically maps your business logic, active contracts, and compliance rules.
Builds an auditable memory: You cannot govern what you cannot trace. Every agentic action must be captured in a context graph, creating an immutable, queryable record of exactly why a decision was made and which alternatives were rejected.
Embraces open interoperability: Trust requires transparency. By building on open protocols and provenance standards, industries can establish a common, auditable language for agentic behavior.

As foundational models become commoditized, enterprises’ competitive advantages are shifting. Long term, your moat will not be the language model you deploy, but the proprietary graph of your business operations and governed history. Likewise, the future of enterprise AI isn’t simply systems that can act, but systems that can explain, govern, and take accountability for those actions.

Get started today

Ready to build your own trusted system of action? Start by exploring Spanner Graph to ground your agentic workflows in business reality. Next, use BigQuery Graph to build an auditable memory that powers closed-loop learning and regulator-grade explainability. You can begin capturing and analyzing these operational traces today using the BigQuery Agent Analytics Plugin and SDK. Finally, review the Ad Context Protocol to understand the open communication standards underpinning Yahoo’s agentic platform.

Modernizing Healthcare: How Alcidion achieved greater stability and performance with AlloyDB

Mon, 08 Jun 2026 16:00:00 +0000

In clinical informatics, every second counts. For Alcidion, a global leader in smart health solutions, the mission is simple but critical: use technology to reduce cognitive load for clinicians and present the right information at the right time to save lives.

Whether it’s managing patient flow in an emergency department or ensuring a patient is in the correct ward to avoid adverse outcomes, Alcidion’s flagship platform, Miya Precision, serves as a dynamic intelligent care platform for modern hospitals. To power this mission, the platform recently underwent a major architectural transformation, migrating from a legacy Microsoft SQL Server environment to Google Cloud’s AlloyDB for PostgreSQL.

The challenge: overcoming performance bottlenecks

Operating in an industry where data integrity and uptime are non-negotiable, Alcidion faced several technical and operational hurdles with its previous setup:

Operational overhead: Managing persistent backends for SQL Server required significant manual effort. The team had to manually balance database loads between elastic pools to maintain performance while trying to optimize costs. They also had to constantly manage the gap between allocated and used space to prevent shared pools from being consumed by excessive slack space.
Performance latency: Complex JSON data processing, critical for modern health informatics, was taking up to 30 minutes for certain jobs.
Stability concerns: The team sought a more stable Kubernetes environment and a persistent backend that could scale without constant administrative intervention.

The solution: a smooth migration to AlloyDB

Alcidion used the Database Migration Service (DMS) to move from SQL Server to AlloyDB, achieving a remarkably efficient cutover. The total learning and migration process took under one month, with the core database move completed in only one and a half weeks.

By creating custom synchronization tools and using Google Cloud’s managed services, the team reduced the final transition window to just 15 minutes. Alcidion achieved this by spinning up a new Google Cloud instance synchronized to the active one, with both accessible via unique fully qualified domain names. The new environment remained in read-only mode for customer validation.

During the final cutover, the old instance was set to read-only, synchronization was halted, and external integration links were toggled to the new environment. This streamlined process allowed users to log into the new instance and resume work within minutes, with the primary delay being DNS record updates.

Alcidion chose a fully managed AlloyDB service to eliminate control plane tasks and administrative overhead. This shift allows their engineering team to focus on clinical innovation and product development rather than "managing the container" or the underlying database infrastructure.

Being able to cut over to AlloyDB in about 15 minutes had our users back to work almost immediately. For a system clinicians rely on around the clock, that kind of smooth transition gave Alcidion real confidence.

The results: impact by the numbers

The shift to AlloyDB and Google’s Agentic Data Cloud has delivered immediate, quantifiable improvements for Alcidion and its healthcare customers:

Faster data processing: Data processing that previously relied on SQL Server stored procedures — a process that became increasingly time-consuming as data volumes grew — has been transformed. By migrating to AlloyDB and using BigQuery and Dataflow for processing, Alcidion has seen jobs that once took 30 minutes now complete in just 5 to 60 seconds.
Enhanced stability: The migration has delivered a step-change in reliability. In the previous environment, the team faced monthly disruptions, ranging from failed scheduled maintenance to connectivity issues that required manual intervention. In contrast, AlloyDB and Google Cloud’s compute services have proven exceptionally stable, allowing the team to move away from the "firefighting" mode associated with frequent infrastructure crashes.
Reduced cognitive load: By simplifying their backend and clinical dashboards, Alcidion’s SREs have significantly reduced their administrative burden. This shift has freed the team to focus on high-value innovation, such as refining predictive analytics and generative AI that empower clinicians to make informed clinical decisions faster.

Future vision: AI and beyond

Alcidion isn't stopping at database modernization. The move to AlloyDB is a foundational step for their next phase of growth:

AlloyDB columnar engine: The team is exploring the columnar engine for a second round of query optimization and real-time analytics.
Generative AI apps: Alcidion is actively working with Google to use AlloyDB’s Gemini Enterprise Agent Platform integration to perform concept analysis and pick out critical clinical insights from vast datasets.

By moving to AlloyDB, Alcidion has improved its stability and performance and built a strong foundation to keep delivering smarter, safer care to hospitals worldwide.

Ready to modernize your database? Learn more about how AlloyDB can transform your operational workloads.

What’s new with Google Data Cloud

Thu, 04 Jun 2026 16:00:00 +0000

June 1 - June 5

Beyond the Query: Powering AI Agents with Bigtable, Firestore & Memorystore
Discover the latest advancements in Google Cloud's NoSQL Database portfolio, including Bigtable, Firestore, and Memorystore. This series is designed for a broad audience: whether you are exploring these databases for the first time or are an existing user looking to leverage the new capabilities announced at Next '26.

Register here to secure your spot!

Cloud Engineer's AI Toolkit Workshops: Solve data-driven challenges with BigQuery, AlloyDB, Gemini and more. Hosted by Google Cloud Labs, this highly technical event is built specifically for Platform Engineers, SREs, and cloud infrastructure teams ready to bridge the gap between AI prototypes and production-grade deployments. Look out for more locations coming soon

Toronto - June 25 (Data Cloud) | RSVP Here
Chicago - June 30 (Data Cloud) | RSVP Here
Start a 10-day Bigtable free trial with a 1 node SSD cluster and up to 500GB of storage capacity. With no credit card required to start, you can easily ingest workloads and manage workloads that require low-latency, high-throughput, and predictable access. Plus, new Google Cloud customers get $300 in free credits on signup.

May 11 - May 15

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

April 20 - April 24

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

April 13 - April 17

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

April 6 - April 10

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

March 23 - March 27

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

March 16 - March 20

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

February 23 - February 27

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

February 16 - February 20

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

February 2 - February 6

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

January 26 - January 30

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

January 19 - January 23

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

January 12 - January 16

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

Announcing Spanner Graph algorithms: Google-grade intelligence for connected data

Tue, 02 Jun 2026 16:00:00 +0000

At Google Cloud Next, we announced the preview of graph algorithms with Spanner Graph, bringing Google Research’s state-of-the-art graph mining capabilities natively to your database. These graph intelligence capabilities can help you derive valuable insights from graph data faster, cheaper, and at scale.

Enterprises are increasingly leveraging graph technologies to uncover complex relationships in data for use cases such as fraud detection, social network analysis, entity resolution, and healthcare research. Graph algorithms, such as node centrality and community detection, are the computational methods used to analyze these structures, and work by quantifying the patterns and strength of connections between entities. However, running graph algorithms at scale has historically been challenging and resource-intensive, often requiring complex ETL pipelines to dedicated analytic solutions or risking the transactional performance of the graph database.

We designed Spanner Graph algorithms to tackle demanding enterprise workloads without compromising on the performance of your operational database. This architecture provides several distinct advantages:

Tight integration with GQL: Directly invoke algorithms using ISO Graph Query Language (GQL) to run structural analytics across your data. By sequentially weaving algorithms and standard queries together, Spanner Graph minimizes complex data movement to external engines, simplifying your architecture and accelerating time-to-insight.
Near-zero transactional impact and lower TCO: Algorithm execution happens on dedicated compute resources, so as not to impact live production traffic. Spanner automatically provisions resources and securely routes data via Data Boost without having to create a custom ETL pipeline. Pay only for what you use, avoiding expensive licensing and operational overhead of legacy solutions.
Global insights on billion-edge graphs in minutes: Built for scale and speed, our engine can run algorithms on graphs with tens of billions of edges within minutes. Encoding topologies in a dense format that’s optimized for random access enables high-performance structural analytics on massive datasets.

While Google Research has published several research papers, held workshops, and released open-source projects based on its graph mining tools (e.g., for multi-core clustering), this is the first time that they are widely available to Google Cloud customers. Let’s take a deeper look at graph algorithms, and how you can use them with Spanner Graph.

Algorithms: Deeper insights for connected data

When we first launched Spanner Graph, our goal was to reimagine graph data management with a native graph database experience within Spanner, Google’s highly scalable, distributed database. Spanner Graph unifies relational and graph models, allowing developers to query connected data using the ISO GQL, while also interoperating with Spanner's existing tabular, search, and vector capabilities. This allows you to build intelligent applications without creating complex data pipelines, duplicating data, or increasing security and governance risk.

Building on this foundation, Spanner Graph algorithms help you to extract even deeper insights from your connected data. Graph algorithms analyze the relationships and connections within data, revealing hidden patterns and insights that might be missed with traditional analytical methods. With this launch, you can analyze connectedness to, for example, detect fraud rings, conduct clustering for entity resolution, identify points of failure in complex networks, or recommend products based on the preferences of connected users.

We use graphs extensively at Google. In fact, many popular algorithms like PageRank, the foundational technology that powers Google Search, were invented here. With native algorithm support in Spanner Graph, we are bringing some of Google’s leading graph intelligence capabilities directly to Google Cloud customers, with a set of essential graph algorithms that help you easily uncover the hidden structures within your data:

Centrality: Pinpoint the most influential and central nodes within your network using betweenness centrality, closeness centrality, and PageRank.
Community detection: Automatically group highly connected entities to uncover hidden segments with label propagation, correlation clustering, modularity clustering, weakly connected components, and clique aggregator.
Similarity and path finding: Find optimal routes using set-to-set shortest paths, or measure node similarities using Jaccard, cosine, common neighbors, and total neighbors.

An integrated developer experience

You can invoke graph algorithms directly using GQL on the entire graph, subgraphs, or a select set of nodes and edges. Spanner offers an integrated workflow: results from graph algorithm runs can be written directly back to Spanner Graph. This lets you invoke algorithms and standard queries sequentially, using the output of one operation as input to the next. Additionally, you can also store results in Cloud Storage buckets.

Example: Uncovering the ringleader of a fraudulent network

Consider a scenario where you are analyzing financial transactions to combat money laundering. Fraudsters usually manipulate a set of “mule” accounts (intermediary accounts for money laundering) that interact with one another to collectively commit fraud. To capture the teamwork between detected and hidden mule accounts, anti-fraud experts usually resort to link analysis and community detection graph algorithms. Here’s how you can use algorithms and queries together in Spanner Graph to catch them.

Step 1: Identify communities of accounts (algorithm)
First, we apply a modularity clustering algorithm to cluster accounts into communities. We then write the resulting community_id directly back to the Account in Spanner Graph.

code_block: <ListValue: [StructValue([('code', "-- Runs community detection and update results to the graph\r\nEXPORT DATA OPTIONS(\r\n format ='CLOUD_SPANNER',\r\n table = 'Account',\r\n write_mode = 'update_ignore_all'\r\n) AS\r\nGRAPH FinGraph\r\nCALL ModularityClustering(\r\n node_labels => ['Account'],\r\n edge_labels => ['Transfer']\r\n)\r\nYIELD node, cluster\r\nRETURN node.id, cluster AS community_id;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdba80cb80>)])]>

Step 2: Pinpoint the suspicious community (query)
Now that every account belongs to a community, we can use a GQL query to perform analytical queries on each community to uncover anomalous behaviors. For example, we can check the total number of known fraud accounts within each community.

code_block: <ListValue: [StructValue([('code', '-- Finds the community with the highest concentration of flagged fraud\r\nGRAPH FinGraph\r\nMATCH (a:Account)\r\nWHERE a.community_id IS NOT NULL\r\n AND a.fraud_flag = TRUE\r\nRETURN a.community_id AS community_id, COUNT(*) AS fraud_count\r\nORDER BY fraud_count DESC;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdba80c070>)])]>

Step 3: Calculate influence to find the "ringleader" (algorithm on a subgraph)
Let's assume the query above reveals that Community 2 has seen a massive spike in fraudulent activity. In this step, we filter the graph to isolate only the accounts in that specific community and run the PageRank algorithm to find the central ringleader within that exact group.

code_block: <ListValue: [StructValue([('code', "EXPORT DATA OPTIONS(\r\n format = 'CLOUD_SPANNER',\r\n table = 'Account',\r\n write_mode = 'update_ignore_all' \r\n) AS\r\n-- Specifies a suspicious subgraph\r\nGRAPH FinGraph\r\nMATCH (n:Account {community_id: 2})\r\nRETURN n\r\nFULL UNION ALL\r\nMATCH -[e:Transfer]->\r\nRETURN e\r\nNEXT\r\n-- Runs PageRank \r\nCALL PER() PageRank(max_iterations => 20) \r\nYIELD node, score\r\nRETURN node.id, score AS pagerank_score;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdba80ce20>)])]>

Step 4: Investigate the target (query)
Now that the accounts in Community 2 have a pagerank_score, we can write a query that isolates the most central account and that immediately traces where that specific ringleader moved their funds recently.

code_block: <ListValue: [StructValue([('code', "-- Finds the top scorer (ringleader) and trace their money\r\nGRAPH FinGraph\r\nMATCH (ringleader:Account {community_id: 2})\r\nORDER BY ringleader.pagerank_score DESC\r\nLIMIT 1\r\nWITH ringleader\r\nMATCH (ringleader)-[e:Transfer]->{1, 5}(receiver:Account)\r\nWHERE e.ts > '2025-12-01'\r\nRETURN ringleader.id AS ringleader_id, receiver.id AS receiver_id, e.amount, e.ts;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdba80cd00>)])]>

By allowing you to weave high-performance algorithms with standard GQL queries, Spanner Graph eliminates the need to move data back and forth between operational databases and external analytics engines. This unified approach dramatically simplifies your data architecture and accelerates your time to insight.

Trusted by industry leaders

Customers like DaVita, Yahoo!, SoundCloud, and WPP are already leveraging Spanner Graph algorithms to solve some of their most complex data challenges.

"Leveraging Spanner Graph for our Patient 360 initiative has allowed us to consolidate complex healthcare data into a single, unified view. The addition of native graph algorithms like community detection and centrality is a major step forward, enabling us to uncover deep insights within our patient networks faster and at scale. These fully managed capabilities allow our team to focus on driving innovation in patient care without the operational burden of managing complex data pipelines." - Sam Ghosh, Chief Enterprise Architect at DaVita Kidney Care

"Operating at global scale across Yahoo’s iconic consumer properties requires us to unify billions of user profiles into a single, real-time view. With Spanner Graph, we’ve modeled our Unified User Profile (UUP) as a graph, bringing together previously distributed systems into a centralized source of truth. The addition of fully managed graph algorithms on Spanner further accelerates our ability to deliver personalization at scale. By leveraging algorithms such as community detection and PageRank, we can drive deeper audience segmentation and power more relevant, engaging user experiences across our platform." - Chris James, Director of Engineering, Yahoo

"With 500+ million tracks from 40+ million artists across 190+ countries, SoundCloud is where emerging artists find their sound, hidden gems are discovered, and music culture is shaped in real time. We have been running graph algorithms in batch mode for years, with processes often taking multiple hours on custom clusters to analyze our massive, multi-billion-edge music graph. The launch of Spanner Graph algorithms is a true game-changer: It not only provides the massive scalability we need, but also allows us to move away from complex custom Python workflows to a fully managed service. Most importantly, it unlocks the ability to run graph algorithms on our most up-to-date data for use cases like identifying creator hubs and improving recommendations, without requiring complex ETL pipelines or impacting the low-latency transactional workloads running on Spanner today." - Sergey Chekanskiy, VP of Engineering - Data Foundation, SoundCloud

“We've been eager to leverage advanced graph algorithms for Open Intelligence, our foundational intelligence layer that securely connects trillions of live data points from clients, partners and WPP in a privacy-first way and that is now integrated and powers WPP’s agentic marketing platform, WPP Open. In order to have instant, exploratory access to complex relationships across billions of entities – driving planning, modelling, and experimentation — we need native support for deep graph traversal, structural pattern recognition, and advanced algorithms. Algorithm support on Spanner Graph provides the performance and scalability to tackle our most challenging graph analytics problems without operational overhead or expensive licensing." - Rob Marshall, Head of Strategy, Data & Intelligence, WPP

Build more intelligent applications

Now with native support for algorithms in Spanner Graph you can move beyond basic relationship traversals and run deep structural analytics directly on your freshest transaction data. By applying these classic graph algorithms at scale, you can unlock new capabilities for your enterprise applications:

Proactive fraud detection and anti-money laundering: Expose coordinated fraud rings by automatically grouping connected mule accounts with Community Detection (like modularity clustering), then apply centrality (like PageRank) to pinpoint the ringleader who controls the illegal fund flow.
Customer 360 and entity resolution: Unify fragmented, cross-channel data into a single canonical profile using similarity functions like Jaccard and community detection like label propagation. These profiles can be further enriched for downstream ML training by generating topological features, such as PageRank, for each node.
Autonomous network operations and digital twins: Model your IT or telecom infrastructure as a digital twin, using similarity and path finding (like set-to-set shortest path) to proactively identify critical vulnerabilities and predict cascading failures.
Hyper-personalized product recommendations: Move beyond basic purchase histories by analyzing broader user behaviors. Use similarity algorithms (like common neighbors) to find overlapping preferences between entities, and centrality (like personalized PageRank) to surface the most relevant recommendations for those peer groups.
Resilient supply chain and logistics: Protect your supply chain from hidden bottlenecks using centrality (like betweenness centrality) to pinpoint over-relied-upon distribution hubs, and path finding to instantly calculate efficient alternative routes during disruptions.
Cybersecurity threat hunting and blast-radius analysis: Accelerate threat hunting by applying community detection (like correlation clustering) to isolate anomalous machine communications, and path finding to trace the attacker's exact lateral movement and blast radius.
Predictive customer churn analysis: Stop contagious customer churn by mapping out tight-knit subscriber groups with community detection, then apply centrality to identify and target core influencers with retention promotions before the churn spreads.

Get started today

Spanner Graph algorithms are supported with the Enterprise and Enterprise+ editions of Spanner. To learn more, view the documentation or try out this codelab. You can also watch this video for a summary of graph algorithm support with Spanner Graph.

Modeling a digital twin of a food supply chain using BigQuery Graph

Mon, 01 Jun 2026 16:00:00 +0000

The example of a growing restaurant

Imagine you are running a restaurant chain. You just can't physically feel and touch things to know how your business operates. You need tools and a digital replica of your business to sense the health of the business for you.

The friction of growth

Growth creates a unique kind of friction that spreadsheets simply weren't built to solve:

The bullwhip effect: Small downstream demand shifts swell into upstream inventory tidal waves.
SOP drift: Tiny departures from standard prep work eventually erode the entire brand vibe.
The food safety blast radius: One contaminated ingredient creates a messy, complex map of risk across the network.
Maverick spend: The "million-dollar leak" caused by local managers purchasing ingredients off-contract.

The digital twin

Digital models empower us to ask more insightful questions about the world, but they also force a critical choice in how we structure data. While traditional relational tables have been the standard, we must ask: are they still the right tool for everything? Given that our world is inherently interconnected, perhaps shifting to graph-based models is the natural evolution for capturing reality.

When managing thousands of assets, complex supply chains, or global logistics networks, traditional relational databases require massive, resource-intensive SQL joins to trace dependencies. This architecture creates a latency gap between physical events and operational awareness.

Modeling with BigQuery Graph

BigQuery Graph allows you to build a digital twin of your entire supply chain within your existing data platform. By turning your physical world—items, recipes, and locations—into a searchable map of nodes and edges, you gain a new level of clarity.

1. Defining the Semantic Layer

Instead of moving data to a new database, you create a Graph View over your existing tables. This tells BigQuery exactly how your tables relate to one another.

Query Language:

code_block: <ListValue: [StructValue([('code', '# Build the Graph Nodes & Edges\r\nCREATE or REPLACE PROPERTY GRAPH `restaurant.bombod`\r\nNODE TABLES (\r\n `restaurant.item` label item properties all columns,\r\n `restaurant.location` label location properties all columns,\r\n `restaurant.itemlocation` label itemlocation properties all columns\r\n)\r\nEDGE TABLES (\r\n `restaurant.bom`\r\n KEY(bomKey)\r\n SOURCE KEY (childItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n DESTINATION KEY (parentItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n LABEL consists_of properties all columns\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdba5df970>)])]>

Image of a fictitious restaurant supply chain modeled using BigQuery Graph

Precision in practice

How does this change daily operations? It moves the business from panic to precision.

Surgical recalls: If a supplier reports a Listeria breakout, you walk the graph forward to find exactly which menu items in which specific restaurants are affected.
Weather risk analysis: When a hurricane threatens a distribution center, you don't see a list of stores; you see the blast radius. You identify the locations critically dependent on that hub and reroute supplies.

2. Executing the search

Graph Queries are a new tool for modelers and data scientists to query their data - it simplifies complex multi-domain data concepts and simplifies querying and makes data analysis a simpler more natural representation of problem articulation. For example: If I want to know which all locations handle chicken I could run a graph query as shown below:

To investigate a specific complaint or risk, you run a search on the model using graph query language.

Graph Query Language

code_block: <ListValue: [StructValue([('code', "# Navigate to the source of a specific ingredient issue\r\nGraph restaurant.bombod\r\nMATCH (a:itemlocation)-[c:consists_of]->(b:itemlocation) \r\nWHERE b.itemKey LIKE '%Chicken%'\r\nRETURN to_json([to_json(a),to_json(c),to_json(b)]) as result"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fbdba5dfc70>)])]>

Source of a foul odor - modeled as a graph

Building for the future

To get the most out of your digital twin, follow these guiding principles:

Focus on structure: Use graphs for relationships and dependencies; keep daily sales totals in relational tables.
Clean your keys: Spend time on data engineering; a graph is only as strong as its connections.
Capture edge properties: Store metadata like lead times or shipping costs directly on the edges to increase the model's utility.

Conclusion

The restaurant industry has outgrown the relational way of treating business data only as a list. By building inter-domain relationships as a digital twin with BigQuery Graph, you move from reactive problem solving to proactive modeling. It’s time to stop managing your network with a list and start seeing the connections in seconds.

Get started today

Check out the tutorial here
Visit the BigQuery documentation: find overview and quickstart guide.
Share your feedback: join our community, and get your questions answered via bq-graph-preview-support@google.com.
Related blog: Introducing BigQuery Graph

AlloyDB Hot Standby: Faster failovers, consistent performance

Fri, 29 May 2026 16:00:00 +0000

AlloyDB for PostgreSQL is a fully managed, PostgreSQL-compatible database service designed for the most demanding enterprise workloads. It combines the best of PostgreSQL with the power of Google, delivering exceptional performance, scalability, and availability. We are continuously innovating to make AlloyDB even more resilient, and today, we're excited to announce a significant upgrade to our High Availability (HA) architecture: Hot Standby.

Understanding AlloyDB HA Architecture

An AlloyDB primary instance configured for high availability consists of an active node and a standby node, located in different zones within a region for resilience. AlloyDB's cloud-native architecture separates compute and storage to allow for individual scaling of each resource. Database write-ahead logs (WAL) are synchronously written to a regional log persistor, ensuring durability, while data blocks reside in AlloyDB's regional storage service. A load balancer directs traffic to the current active node using a stable IP address.

In the traditional HA model, if the active node became unavailable, AlloyDB would automatically initiate a failover. The standby node, previously idle from a PostgreSQL perspective, would start the database, process any remaining logs, and then take over. While this ensures high availability, the database startup time and the subsequent cache warming period could impact application recovery time and performance.

Introducing AlloyDB Hot Standby: The New Architecture

With the new Hot Standby capability, we've transformed the role of the standby node. Instead of being a passive node, the standby node now continuously applies WAL records streamed from the primary. This architectural shift brings two massive advantages:

Dramatically Reduced Failover Times: Because PostgreSQL is already running, initialized, and actively replicating on the standby, the time required to promote it to primary in the event of a failure is significantly shorter. The system detects the failure (typically within 30 seconds), promotes the standby, and redirects connections. The database startup phase on the standby is eliminated, reducing overall downtime and improving your Recovery Time Objective (RTO).
Consistent Performance After Failover: Since the Hot Standby node is actively replaying logs, its memory caches (like the PostgreSQL buffer cache) are kept "warm." They contain much of the same frequently accessed data as the primary node's caches. When a failover occurs, the new primary can serve requests at optimal speed almost immediately. This avoids the performance "brownout" typically seen while caches warm up from disk, ensuring application performance remains stable.

And the best part? This substantial enhancement to availability and resilience comes at no additional cost to you.

See Hot Standby in Action

We've prepared a short demonstration to illustrate the difference between the new Hot Standby HA and the legacy HA setup. In the video, we run a benchmark load on two AlloyDB instances and trigger a failover on both simultaneously.

As you can see in the demo:

The instance with Hot Standby completes the failover in approximately 15 seconds. Crucially, its transaction per second (TPS) rate returns to the pre-failover levels almost immediately.
The instance with Legacy HA takes noticeably longer to complete the failover. Even when it comes back online, the TPS is significantly lower and takes several minutes to ramp back up to the original performance levels as its caches warm up.

This side-by-side comparison clearly shows the benefits of Hot Standby in minimizing downtime and eliminating the post-failover performance impact.

Get Started with Enhanced HA

Hot Standby is being rolled out to newly created AlloyDB instances in PostgreSQL 18, providing an upgraded HA experience automatically, and will be rolling out to the earlier major versions in the coming months. You can continue to rely on AlloyDB's 99.99% SLA, now backed by even faster failovers and more predictable post-failover performance.

This enhancement underscores our commitment to providing a best-in-class, enterprise-grade managed PostgreSQL experience.

To learn more about AlloyDB's High Availability features, please refer to the official documentation. New to AlloyDB? Try it out today!

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

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

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

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

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

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

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

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

An easy on-ramp: The Google Cloud Starter Tier

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

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

Powering full-stack vibe coding with Cloud SQL

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

AI Studio integration with Cloud SQL includes:

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

Creating an app powered by Cloud SQL for PostgreSQL developer edition

Full-stack vibe coding with Firestore and Firebase Auth

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

Enable Firebase for your application when prompted by the agent

By clicking “Enable Firebase,” the agent automatically:

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

With Firebase Auth, you can:

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

Connect your app to Google Sheets, powered by Firebase Authentication

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

Getting started in AI Studio

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

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

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

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

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

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

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

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

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

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

The solution: AlloyDB for PostgreSQL

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

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

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

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

A transformative shift

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

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

A blueprint for success: Planning and testing

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

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

Learn more:

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

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

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

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

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

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

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

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

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

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

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

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

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

How Proxy Models Work?

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

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

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

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

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

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

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

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

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

Revisiting when Proxy Models Work

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

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

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

Why isn’t Vector Search Enough?

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

Experimental Results

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

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

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

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

Conclusion

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

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

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

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

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

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

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

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

Gemini-powered enhancements

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

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

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

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

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

Other platform enhancements

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

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

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

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

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

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

What are Database Center customers saying

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

Get started with Database Center

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

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

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

Get started with Database Center today:

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

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

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

Maintain stability with Extended Support

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

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

Key timelines

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

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

What’s included

During the Extended Support period, Google Cloud provides:

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

Managing your transition

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

Speed up development with PostgreSQL 18 on AlloyDB

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

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

Proven reliability: UKG modernizes the data foundation

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

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

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

Maximize performance with database-aware storage

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

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

Get started

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

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

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

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

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

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

The cache-miss nightmare: A familiar story

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

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

Enter Bigtable’s in-memory tier

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

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

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

A peek behind the curtain

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

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

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

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

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

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

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

The cache-miss nightmare, revisited

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

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

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

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

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

Get started with Bigtable Enterprise Plus

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

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

Learn more

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

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

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

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

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

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

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

The case for Firestore

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

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

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

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

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

Companies like FlutterFlow are already reaping the benefits.

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

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

1. Accelerating application development through agentic AI integrations

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

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

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

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

Write queries in natural language using Gemini Code Assist.

2. Differentiated search and queries

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

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

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

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

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

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

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

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

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

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

3. Enhanced MongoDB compatibility and scalability

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

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

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

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

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

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

Get started on Firestore

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

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

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

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

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

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

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

Unifying the systems behind the suite

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

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

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

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

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

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

Bringing people intelligence to intelligent people

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

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

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

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

Driving impact across every layer

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

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

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

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

Learn more

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

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

Databases

SOCRadar powers rapid threat detection with AlloyDB and Gemini Enterprise

How SOCRadar supercharges rapid threat detection with AlloyDB

Evaluating database alternatives: The hunt for scalability

Taming a "triple-threat" workload

More than just speed: Reclaiming 45 TB and 75% of DBA time

Fighting alert fatigue with integrated Gemini Enterprise Agent Platform

Expanding capabilities: The future of agentic threat hunting

AlloyDB AI Functions - now with revolutionary performance boosts and cost savings

More functions to summarize and analyze sentiment

The power of LLMs on your data: now significantly faster and cheaper

See it in action!

Getting started is easy

Modernizing financial services with deployment freedom and transformational AI with AlloyDB Omni

AlloyDB Omni: Strong performance and deployment freedom

Enterprise-grade security and compliance

Next steps

Supercharging the agentic era with Spanner’s multi-model architecture

The multi-model advantage for the agentic era

Spanner Omni: Multi-model capabilities, everywhere

Industry-defining capabilities for core databases

A unified vision for the agentic era

How Atlas scales hundreds of merchant databases with Cloud SQL Enterprise Plus edition

The challenge: Scaling beyond standard

The shift to Enterprise Plus edition

The impact: Focus on innovation, not plumbing

Looking ahead: An AI-first future

Ready to scale your database architecture?

What’s new in data agents: Supercharging your AI workflows

1. Conversational Analytics

2. New data agents

3. Tools for data agents

Architecting a trusted agentic platform with graph technologies: A Yahoo case study

Case study: agentic media buying

The architecture of a trusted system of action

The knowledge graph: Grounding agents in business reality

The context graph: creating an auditable memory

From human to agent scale

A blueprint for many industries

Get started today

Modernizing Healthcare: How Alcidion achieved greater stability and performance with AlloyDB

The challenge: overcoming performance bottlenecks

The solution: a smooth migration to AlloyDB

The results: impact by the numbers

Future vision: AI and beyond

What’s new with Google Data Cloud

June 1 - June 5

May 11 - May 15

April 20 - April 24

April 13 - April 17

April 6 - April 10

March 23 - March 27

March 16 - March 20

February 23 - February 27

February 16 - February 20

February 2 - February 6

January 26 - January 30

January 19 - January 23

January 12 - January 16

What’s new with Google Data Cloud - 2025

Announcing Spanner Graph algorithms: Google-grade intelligence for connected data

Algorithms: Deeper insights for connected data

An integrated developer experience

Example: Uncovering the ringleader of a fraudulent network

Trusted by industry leaders

Build more intelligent applications

Get started today

Modeling a digital twin of a food supply chain using BigQuery Graph

The example of a growing restaurant

The friction of growth

The digital twin

Modeling with BigQuery Graph

1. Defining the Semantic Layer

Precision in practice

2. Executing the search

Building for the future

Conclusion

Get started today

AlloyDB Hot Standby: Faster failovers, consistent performance

Understanding AlloyDB HA Architecture