Cloud Blog

Introducing Google Cloud’s U4 compute: Enabling ultra-low latency trading

Wed, 07 Oct 2026 16:00:00 +0000

In capital markets, operational success is built on predictable performance and low latency, where even tiny variations in packet timing alter queue priority and trade execution. At the same time, both exchange venues and their participants face mounting constraints in traditional on-premises data centers — from power and physical rack space limits to lengthy hardware procurement cycles. Increasingly, global capital markets seek the speed and determinism of physical co-location combined with the dynamic scalability and automation of the cloud.

At Google Cloud Next ‘26, we announced the Ultra Low Latency (ULL) Solution, now generally available, providing high-frequency trading workflows that run in the cloud with an ultra-low latency network and agility. The ULL Solution includes the new U4 machine family, also generally available today.

The ULL Solution is based on three infrastructure pillars:

Hardware-level networking: Scaleable, hardware-based multicast data distribution for reliable market-data feeds
Advanced networking observability: Dynamic network traffic capture with hardware-level timing accuracy, facilitating consistent auditing, market replays, and absolute trade validation without impacting primary traffic performance
Deterministic high-performance compute: Processing of latency-critical execution tiers in a highly predictable, consistent amount of time, every single time

Taken together, the ULL Solution’s compute, storage, networking, and observability provide financial exchanges and market participants with a number of technical capabilities:

Bare metal performance: Dedicated bare metal compute provides direct access to physical host resources, minimizing jitter and delivering predictable, low-latency execution for market-data feeds and order routing.
High-performance storage options: Local Titanium SSDs handle real-time transaction and tick logging on the host, complemented by scalable Google Cloud Hyperdisk for persistent market data archives and analytics.
Physical traffic isolation: The ULL trading fabric’s redundant A/B multicast market feeds are accessed through two independent and dedicated Titanium adapters, while an independent third Titanium adapter offloads telemetry, management, and provides access to Google Cloud services.
Hardware-accelerated multicast distribution: The ULL network architecture supports hardware-level multicast feed ingestion. This allows participants to stream high-throughput market data directly to low-latency trading applications, bypassing traditional hypervisor-level virtual switches.
Accelerated packet processing: Support for OpenOnload and DPDK enables Linux user-space networking to deliver predictable unicast and multicast packet handling while minimizing application code changes.
Precision timing and UTC synchronization: Integration with Google Cloud’s Firefly clock synchronization system allows the solution to consistently achieve sub-10 nanosecond network-level timestamping and better synchronization to UTC than the sub-100 microsecond regulatory requirement for financial exchanges.
Built-in telemetry: 24/7 low-latency packet capture and seamless out-of-band packet brokering for regulatory compliance and real-time analytics helps ensure deep visibility without impacting primary traffic performance.
24-7 market ready: The solution is designed for continuous, round-the-clock trading readiness by isolating production workloads in a dedicated primary zone for live trading, while routine cloud maintenance and qualification testing occur in a secondary zone for updates and testing.

Compute in the ULL Solution is delivered by the new U4 machine family, which brings predictable performance and ultra-low latency compute in three specialized machine series: dual-socket bare metal instances with three physical NICs — U4P for exchange operators and U4C for market participants — alongside U4S high-performance VMs for operators, participants, and service providers.

Machine Series	CPU Platform	CPU Cores	Memory	NICs	Storage Options
U4P (Bare Metal)	Intel 5th Gen Xeon (Emerald Rapids)	120 Physical Cores	512 GB or 768 GB	3 Physical (1 Standard + 2 ULL)	Local Titanium SSD (12 TiB), Hyperdisk
U4C (Bare Metal)	Intel 5th Gen Xeon (Emerald Rapids)	120 Physical Cores	512 GB or 768 GB	3 Physical (1 Standard + 2 ULL)	Local Titanium SSD (12 TiB), Hyperdisk
U4S (VM)	Intel 6th Gen Xeon (Granite Rapids)	2 to 288 vCPUs	Up to 2,232 GB	Multi-vNIC (Up to 200 Gbps)	Local Titanium SSD (18 TiB), Hyperdisk

Machine Series

CPU Platform

CPU Cores

Memory

NICs

Storage Options

U4P

(Bare Metal)

Intel 5th Gen Xeon (Emerald Rapids)

120 Physical Cores

512 GB or 768 GB

3 Physical (1 Standard + 2 ULL)

Local Titanium SSD (12 TiB), Hyperdisk

U4C

(Bare Metal)

Intel 5th Gen Xeon (Emerald Rapids)

120 Physical Cores

512 GB or

768 GB

3 Physical (1 Standard + 2 ULL)

Local Titanium SSD (12 TiB), Hyperdisk

U4S

(VM)

Intel 6th Gen Xeon (Granite Rapids)

2 to 288 vCPUs

Up to 2,232 GB

Multi-vNIC (Up to 200 Gbps)

Local Titanium SSD (18 TiB), Hyperdisk

We developed the U4 machine family to enable the world’s most technically demanding markets to run within Google Cloud and benefit from cloud services and scale. An example of this is our ongoing collaboration with CME Group, through which we are migrating listed derivatives markets to Google Cloud. Here, the U4C and U4P bare metal instances deliver direct physical co-location latency parity, providing predictable low-latency clock precision, and native hardware-multicast feed ingestion. This architecture demonstrates that core exchange systems and trading strategies can run in the cloud with the speed, consistency, and control that financial markets require.

"Migrating the world’s leading derivatives marketplace to the cloud requires uncompromising performance, latency, and reliability. Google Cloud’s Ultra Low Latency Solution and the U4 instance families represent a breakthrough for financial market infrastructure. By combining deterministic, ultra-low latency networking and dedicated bare metal compute with the benefits of the cloud, market participants can execute and ingest market data and execute with the speed of traditional co-location and the agility of the cloud." - Pearce Peck-Walden, Managing Director Markets Engineering, CME Group

Powered by Google Cloud-native infrastructure

The ULL Solution is available in select private Google Cloud regions, where trading teams can leverage core cloud infrastructure benefits such as rapid automated resource provisioning, on-demand capacity scaling, and dynamic fleet management. Trading teams can execute ultra-low latency trades on a dedicated, isolated ULL network, and offload data streams over an independent network interface to Google Cloud services such as BigQuery and Gemini Enterprise.

For exchange participants managing tick-to-trade workflows or processing real-time market data, microsecond variations are critical. As bare metal instances, U4P and U4C machine series don’t add any virtualization overhead for latency-sensitive execution tiers. Leveraging Google Cloud's Titanium offload system architecture, these bare metal instances provide direct access to the host resources. Compute Engine instances enable users to provision dedicated hardware through standard Google Cloud APIs, orchestrate deployments with infrastructure as code, apply Cloud Next Generation Firewall (NGFW) policies, and collect rich telemetry.

The U4S VM series complements these bare metal offerings for applications such as pre-trade risk validation and real-time analytics. Deployed alongside U4P and U4C instances, these VMs shorten transit hops across the trading architecture while offering elastic scaling from 2 to 288 vCPUs and networking up to 100 Gbps.

“Our testing of the U4 instances validated that Google Cloud delivers the low latency and determinism required for our demanding exchange trading workloads. Having both bare metal and VM options allows us to evaluate the value of that performance relative to its cost, helping us align the right infrastructure to each of our trading strategies.” - Corbin Kidd, EVP/CTO, Prime Trading

"In our tick-to-trade performance testing, the U4C bare metal instance demonstrated exceptional speed, showing that cloud compute and ultra-low latency networking can comfortably satisfy microsecond trading demands. But, what sets the U4 series apart isn't just raw processing speed, it’s structural determinism. When we stress-tested Google Cloud's U4 bare metal family, the performance curve remained virtually flat, which confirms that these cloud compute layouts can now offer the strict determinism institutional market participants require." - Christopher Wilson, Global Head of Experience Modernization, 28Stone

Looking to the future, this low-latency architecture serves as the foundation for algorithmic trading, allowing firms to feed real-time markets directly into AI-driven trading models.

Storage and placement for trading workloads

The U4 family supports Google Cloud storage options and placement policies, helping trading teams record trades at speed and minimize network latency between machines:

Local Titanium SSD for fast logging: For real-time trade logging and data caching without slowing down execution, U4P and U4C provide up to 12 TiB of direct-attached NVMe SSDs, and U4S VMs scale up to 18 TiB.
Hyperdisk for data archives: For historical market data, backtesting models, and regulatory archives, you can attach Hyperdisk Balanced and Hyperdisk Extreme volumes across all U4 series, scaling up to 32 volumes and 512 TiB per instance.
Placement policies: To reduce physical network hops, compact placement policies keep related machines close together in the data center. Alternatively, spread placement policies place machines on separate racks to improve resiliency.

Getting started with the ULL Solution

With the ULL Solution, financial exchange operators, exchange participants, and trading service providers can execute trades with the speed and reliability they need today while positioning their businesses to leverage continuously evolving AI and infrastructure capabilities for the trading of tomorrow. The ULL Solution is available in select Google Cloud regions. To learn more, check out the public documentation, and reach out to our team to request access.

Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise

Tue, 06 Oct 2026 19:00:00 +0000

Co-authors:
Stenal Jolly, Strategic Cloud Engineer, Google
Anubhav Dhawan, Software Engineer, Google

Following the landmark announcement of MCP Toolbox v1.0, we're thrilled to announce that the MCP Toolbox Java SDK has officially reached version 1.0.

This release brings first-class, type-safe agent orchestration to one of the world's most widely adopted enterprise ecosystems. Java's mature architecture is purpose-built for rigorous demands, providing the high concurrency, strict transactional integrity, and robust state management required to safely scale mission-critical AI agents in production.

In this post, we'll tell you about what's new in Java SDK v1.0, show you a real-world example, and help you get started with your own implementation.

MCP: The universal interface

Today, developers face a compounding integration bottleneck: if you have N different AI models and M enterprise data sources, you must build, secure, and maintain N × M bespoke, custom connections. This lack of a unified integration layer forces engineering teams to rely on a fragmented web of ad-hoc pipelines. As a result, scaling an agentic architecture quickly becomes unsustainable, exposing sensitive enterprise databases to severe security vulnerabilities, fragmented access controls, and massive maintenance overhead.

Eliminating the fragmented web of custom integrations is the core problem solved by the Model Context Protocol (MCP). Acting as a universal interface—the "USB Type-C" for AI orchestration—MCP decouples models from data sources. Instead of writing custom or managed API integration code for every new model or database, developers write to a single, standardized protocol. This approach allows any MCP-compliant agent to securely and immediately interact with any MCP-enabled system. The MCP connection lets developers connect agents to real-world systems without building bespoke integrations for every new model.

What's new in Java SDK v1.0: Built for production workloads

When we announced the public Beta for the MCP Toolbox Java SDK, our goal was to bring first-class, type-safe agent orchestration to enterprise Java environments. Since then, we've collaborated with developers and open-source contributors to harden our APIs.

The v1.0 release marks a stable, backwards-compatible foundation suitable for enterprise workloads. Here's what's new and hardened since our v0.2 release:

Transport layer abstraction & HttpMcpTransport: We introduced a clean transport layer abstraction alongside HttpMcpTransport. This feature decouples the core protocol logic from underlying HTTP clients, making it easy to swap network implementations or customize connection pooling.
Decoupled client authentication: To simplify enterprise security compliance, client authentication is now decoupled using CredentialsProvider and AuthMethods classes. Credentials are resolved asynchronously on every request, so teams can refresh tokens dynamically or plug in their own token source (Google OIDC via ADC ships in the box, anything else is a one-method interface).
Default parameter support: Native support for default values in tool parameters, reducing prompt payload sizes and enhancing agent reliability.
Pruning bound parameters: Sensitive parameters that are bound server-side (like tenant_id) are now automatically stripped from exposed tool definitions so the LLM can't manipulate them.
Version selection & session tracking: Standardized MCP version selection and robust session tracking ensure consistent protocol negotiation and conversation-state lifecycles.
HTTP credential exposure warnings: Added built-in detection that warns you at runtime when credentials are about to travel over a plaintext HTTP connection.
Generic client headers map: Easily attach custom corporate proxy headers, transaction tracing IDs, or correlation metadata to all outgoing requests.

Get started with the Java SDK v1.0

We designed the MCP Toolbox Java SDK to be frictionless for enterprise teams. Just add the following dependency to your pom.xml:

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n</dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cbd40d0>)])]>

Real-world example: The autonomous transit concierge

To demonstrate the power of the Java SDK combined with AlloyDB, let's look at an enterprise use case.

Meet Cymbal Transit, a fictitious intercity bus network. Customers don't want to click through nested dropdown menus to plan a trip. They want to ask:

"I need to get from New York to Boston tomorrow morning. Can I bring my Golden Retriever? If so, book me the fastest trip."

To answer this question, an AI agent must cross-reference unstructured data (pet policies) with structured data (schedules and seat availability) and execute a transaction (booking)—all while maintaining the context of the conversation.

The foundation: AlloyDB schema with native embeddings

We used AlloyDB for this implementation because it handles relational data and high-dimensional vectors natively. Set up your database tables with these statements:

code_block: <ListValue: [StructValue([('code', "-- Enable necessary extensions for semantic search and embeddings\r\nCREATE EXTENSION IF NOT EXISTS vector;\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration;\r\n\r\n-- Table 1: Transit Policies (Unstructured Data for RAG)\r\nCREATE TABLE transit_policies (\r\n policy_id SERIAL PRIMARY KEY,\r\n category VARCHAR(50),\r\n policy_text TEXT,\r\n policy_embedding vector(768)\r\n);\r\n\r\n-- Table 2: Intercity Bus Schedules (Structured Data)\r\nCREATE TABLE bus_schedules (\r\n trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n origin_city VARCHAR(100),\r\n destination_city VARCHAR(100),\r\n departure_time TIMESTAMP,\r\n arrival_time TIMESTAMP,\r\n available_seats INT DEFAULT 50,\r\n ticket_price DECIMAL(6,2)\r\n);\r\n\r\n-- Table 3: Booking Ledger (Transactional Action Data)\r\nCREATE TABLE bookings (\r\n booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n trip_id UUID REFERENCES bus_schedules(trip_id),\r\n passenger_id VARCHAR(100),\r\n status VARCHAR(20) DEFAULT 'CONFIRMED',\r\n booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP\r\n);"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cbd73d0>)])]>

Mapping intents to SQL: The `tools.yaml`

The MCP Toolbox lets you define custom tools securely. Rather than granting the LLM direct database access, a tools.yaml configuration maps natural language intents directly to parameterized, safe queries:

code_block: <ListValue: [StructValue([('code', 'kind: source\r\nname: alloydb\r\ntype: alloydb-postgres\r\nproject: my-project\r\nregion: us-central1\r\ncluster: my-cluster\r\ninstance: my-instance\r\ndatabase: postgres\r\n---\r\nkind: tool\r\nname: query-schedules\r\ntype: postgres-sql\r\nsource: alloydb\r\ndescription: Find available bus schedules between cities.\r\nparameters:\r\n - name: origin\r\n type: string\r\n description: The departure city name.\r\n - name: destination\r\n type: string\r\n description: The arrival city name.\r\n - name: limit\r\n type: integer\r\n description: Maximum number of schedules to return.\r\n default: 5\r\nstatement: |\r\n SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price\r\n FROM bus_schedules\r\n WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)\r\n ORDER BY departure_time ASC\r\n LIMIT $3'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cbd77d0>)])]>

For the complete YAML file, see the tools.yaml file in the mcp-toolbox-sdk-java repository.

Stateful agent architecture in Spring Boot

The hardest part of building conversational AI in enterprise applications is managing state: when a user asks, "What times are available?" and follows up with, "Book the 8 AM one," the agent must remember prior context across turns.

Using the Java MCP Toolbox SDK with Spring Boot and LangChain4j, we can cleanly maintain conversational memory in the HTTP Session and we can cleanly separate the agent into two declarative components:

A declarative agent interface that manages the prompt, tools, and conversational memory via an HTTP session.
A tool execution service that routes agent requests directly to the MCP Toolbox server.

code_block: <ListValue: [StructValue([('code', 'interface TransitAgent {\r\n @SystemMessage({\r\n "You are the Cymbal Transit Concierge.",\r\n "Use the \'querySchedules\' tool for finding schedules.",\r\n "Use \'bookTicket\' to execute transactions.",\r\n "Use \'searchPolicies\' to look up luggage and pet rules."\r\n })\r\n String chat(@MemoryId String sessionId, @UserMessage String userMessage);\r\n}\r\n\r\n@Service\r\nclass TransitAgentTools {\r\n // These methods automatically invoke our MCP Toolbox server!\r\n @Tool("Query specific schedules between an origin and destination city.")\r\n public String querySchedules(String origin, String destination) { ... }\r\n\r\n @Tool("Book a ticket for a passenger.")\r\n public String bookTicket(String tripId, String passengerName) { ... }\r\n\r\n @Tool("Search transit policies for luggage and pet rules.")\r\n public String searchPolicies(String query) { ... }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cbd5d10>)])]>

Notice how the @MemoryId annotation abstracts session tracking: Spring Boot automatically correlates conversational context to the user's HTTP session. Meanwhile, LangChain4j and the MCP Toolbox handle schema translation and tool routing behind the scenes—no handwritten if/else intent parsing required.

By pairing the MCP Toolbox Java SDK with LangChain4j, we achieve clean separation of concerns and effortless state management:

Zero-boilerplate session management: The @MemoryId String sessionId parameter binds conversation history directly to the user's HTTP session.
Declarative agent contract: The TransitAgent interface defines the model's persona and system instructions without complex prompt templating.
Type-safe tool execution: The TransitAgentTools Spring service wraps remote MCP database tools as native Java methods.

This architecture ensures your agent remains modular: you can refine prompt guidance in the interface, manage user sessions automatically, and execute secure database queries through MCP Toolbox without tight coupling.

Connecting the dots: Listing, invoking, and executing tools in Java v1.0

Now let's look under the hood of the TransitAgentTools interface. Inside those LangChain4j @Tool methods on our Spring @Service, the MCP Toolbox Java SDK handles the heavy lifting—bridging your Java service methods to the MCP tools defined in the tools.yaml file. In just a few lines of type-safe code, we can initialize our client using the new v1.0 decoupled authentication and headers abstractions:

code_block: <ListValue: [StructValue([('code', '// 1. Initialize the Client with Decoupled Auth and Custom Headers (v1.0)\r\nString serviceUrl = "https://toolbox-my-project-uc.a.run.app/mcp";\r\nMcpToolboxClient mcpClient = McpToolboxClient.builder()\r\n .baseUrl(serviceUrl)\r\n .credentialsProvider(new GoogleCredentialsProvider(serviceUrl)) // Decoupled OIDC credentials\r\n .headers(Map.of( // Generic client headers\r\n "X-Correlation-ID", "enterprise-session-abc123",\r\n "X-Client-Platform", "Spring-Boot"\r\n ))\r\n .build();\r\n\r\n// 2. Listing Discoverable Tools\r\nmcpClient.listTools().thenAccept(tools -> {\r\n System.out.println("Successfully discovered " + tools.size() + " tools.");\r\n});\r\n\r\n// 3. Invoking a Tool (Read-Only Data with Default Parameter Support)\r\n// "limit" is omitted: the SDK fills it from the default in the tool definition\r\nString schedules = mcpClient.loadTool("query-schedules")\r\n .thenCompose(tool -> tool.execute(Map.of(\r\n "origin", "New York",\r\n "destination", "Boston")))\r\n .join().text();\r\n\r\n// 4. Executing a Transactional Tool (Using Bound Parameters)\r\nAuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);\r\n\r\nString bookingConfirmation = mcpClient.loadTool("book-ticket", Map.of("google_auth", toolAuthGetter))\r\n // Bind the authenticated user context securely. bindParam returns a new immutable\r\n // Tool, and the bound parameter is pruned from the definition exposed to the LLM!\r\n .thenCompose(tool -> tool.bindParam("passenger_name", "Jane Doe")\r\n // Execute the mutable transaction\r\n .execute(Map.of("trip_id", "123e4567-e89b-12d3-a456-426614174000")))\r\n .join().text();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cbd52d0>)])]>

Secure by default: authentication and deployment

Moving an AI agent to production requires rock-solid credential handling and an infrastructure that scales with demand. Let's look at how you can enforce credential safety across environments and deploy independently on Cloud Run.

Application Default Credentials (ADC) & safety

By using the GoogleCredentialsProvider service, your Java app inherits its secure identity from its execution environment (whether local or in Google Cloud) through Application Default Credentials (ADC)—no hard-coded keys, with OIDC tokens minted and cached per audience under the hood. Furthermore, v1.0 offers HTTP Credential Exposure Warnings that automatically detect when credentials are about to travel over a plaintext HTTP connection and emit a runtime warning telling you to switch to HTTPS.

Deploying the fleet to Cloud Run

Because MCP Toolbox and the Spring Boot Agent are fully decoupled, they scale independently on Google Cloud Run to meet high concurrency and stateful conversation requirements.

To set up and configure Toolbox on Cloud Run, download the open-source MCP Toolbox for Databases and then follow the deployment guide.

Get started today

With MCP Toolbox Java SDK v1.0, enterprise Java teams can wire Spring Boot and LangChain4j agents to the Toolbox server, and through it, to AlloyDB and every other supported data source. When you use the toolbox, arguments are validated against the tool definition before they leave the JVM, authentication is decoupled, and custom headers are attached to every outgoing request. The following implementation steps will help you get started.

Step 1: Add the Dependency

To start building with the SDK, add the following dependency to your Maven project's pom.xml file:

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n \r\n </dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cbd6c10>)])]>

Step 2: Explore Resources & Demos

GitHub Repository: Java SDK for interacting with the MCP Toolbox for Databases
Official Documentation: MCP Toolbox for Databases

Demo Application: To experience the Java SDK V1.0 for MCP Toolbox latest, try the sample application Cymbal transit project.

Gradle implementation

If your team uses Gradle instead of Maven, remember they will need to translate this dependency:

code_block: <ListValue: [StructValue([('code', "implementation 'com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cbd4050>)])]>

Automatic version tracking

If you copy this setup into automated internal repositories, keep the XML comment  intact. It's required by the release manager's deployment scripts to automatically bump versions.

Now that you can integrate your modern agentic tools and servers to your enterprise Java applications with a stale MCP Toolbox Java SDK, get started today!

Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog

Tue, 06 Oct 2026 16:00:00 +0000

As customers modernize to lakehouse architectures, they are standardizing on open formats such as Apache Iceberg to create a shared data estate across compatible engines. This enables you to build AI-native lakehouses that turn data to semantic knowledge, enable proactive action, and operate at an agentic scale.

One of the key components of a lakehouse is the catalog, and in the Apache Iceberg environment, that usually means the Iceberg REST Catalog. An Apache Iceberg catalog is responsible for maintaining table pointers, handling atomic commits, and serving as the single source of truth for table locations. But as large enterprise organizations modernize to lakehouses, they have begun to realize that they need a highly scalable and available managed catalog as a part of their lakehouse architecture. This becomes even more important as querying scales with agents. To support a large amount of repeated small queries from agents, you will need to build on top of a managed catalog that provides atomicity, consistency, availability and concurrency at massive scale.

In this blog, we explore the challenges a managed catalog faces in modern cloud environments at agent scale, and show you how Google Cloud’s serverless Lakehouse runtime catalog can help address them. Powered by Spanner, Google Cloud’s always-on database with virtually unlimited scale, and built to meet the open Apache Iceberg REST catalog specification, the Lakehouse runtime catalog is the highly scalable and available foundation you need for the agentic era.

Challenges a managed catalog needs to solve in the Lakehouse

When speaking with data engineers and infrastructure leads running production analytics at scale in a Lakehouse, the following core pain points consistently emerge and need to be solved by a managed catalog:

Atomic commits and concurrency control: Iceberg guarantees ACID transactions via optimistic concurrency control (OCC). A managed catalog must implement a bulletproof atomic compare-and-swap (CAS) operation to swap the current metadata pointer.

High availability and operational maintenance: Because queries fail immediately if the catalog is down, a managed catalog becomes a critical Tier-1 service.

Scaling the database backing the catalog: Catalog architects typically face a difficult trade-off when choosing a backing database for table metadata and state. Traditional scale-up relational databases provide SQL and ACID transactions, but hit vertical CPU, memory, storage and connection limits under heavy concurrent read/write loads unless manually sharded which incurs a huge operational overhead; while scale-out database systems are either eventually consistent, hard to manage, not enterprise-ready, or all of the above.

Table maintenance coordination: A catalog alone does not optimize data; you must build and operate ancillary pipelines for compaction, snapshot expiration, manifest rewriting, and orphan file cleanup.

Governance and security: A catalog acts as the security gatekeeper. The catalog must implement and maintain:

Authentication protocols (e.g., OAuth2 token exchange, IAM federation)
Access control down to namespace and table levels
Vended storage credentials (e.g., generating short-lived tokens so query engines don't need broad, direct storage credentials)

Lakehouse runtime catalog

To solve these challenges, we built the Lakehouse runtime catalog (GA) with support for Iceberg Rest Catalog. The Lakehouse runtime catalog is a fully serverless, highly available, and unified metadata registry designed from the ground up to support modern open table formats like Apache Iceberg. By natively implementing the Apache Iceberg REST Catalog specification, the Lakehouse runtime catalog decouples metadata discovery from compute engines, helping ensure multiple Iceberg-compatible engines can access a shared data estate and enabling you to take your workloads to production sooner. We’ve helped many customers streamline the migration of their managed catalogs. For example, Etsy migrated its catalog to Lakehouse runtime catalog, joining data in place to accelerate pipeline queries by 60%.

This approach offers a number of architectural benefits:

Open APIs: Support for Iceberg Rest Catalog enables different teams to use their preferred analytics tools on a single, unified dataset.
Multi-engine interoperability: Once registered, tables are immediately discoverable and queryable across Google Cloud Managed Service for Apache Spark, BigQuery, and open-source engines via standard REST interfaces.
Read/write interoperability for Iceberg tables: Leverage Iceberg-compatible engines such as BigQuery, Managed Spark to write to Iceberg tables registered in the Lakehouse runtime catalog. Customers can also use Managed Spark to write to Iceberg tables in external catalogs.
Fully managed Iceberg storage with enterprise-grade features: Use Google's differentiated infrastructure to run analytics with performance on Iceberg tables. This gives you the benefits of open-source flexibility plus performance, scale, governance, and multimodal processing.
Zero data copy: Table definitions point directly to your existing data in the underlying object store. You do not move, rewrite, or duplicate your underlying data.
Bi-directional catalog federation across clouds: Access data from Databricks Unity, Snowflake Horizon and AWS Glue with support for vended credentials and OIDC token exchange. This lets you bring Google AI directly to your AWS and Azure data.
Secure access using credential vending: The catalog supports multiple authorization mechanisms, letting you choose between credential vending and end-user credentials. This means that you can access tables with modern mechanisms such as credential vending without needing direct access to the files in the underlying object store (Cloud Storage, AWS S3, Azure Blob Storage).
AI-powered context and governance: The Lakehouse runtime catalog integrates directly with Knowledge Catalog and Cloud IAM, allowing you to define trusted context for your agents, and apply table-level security consistently across all compute engines. Get out-of-the-box search, lineage, and insights for Iceberg tables in the catalog.
Atomic commits and concurrency control, high availability and scalability: Backed by Google’s planet-scale infrastructure and Spanner, you get the high availability, concurrency and scale you need for your metadata to scale with your data. Support for Cloud Storage dual-region and multi-region buckets enables failover use cases. It also provides reduced TCO due to serverless and no-ops environments, and scalability for any workload size.

What powers the Lakehouse runtime catalog?

The Lakehouse runtime catalog is a highly available, concurrent and scalable catalog with strong consistency guarantees because it is built on top of Spanner. Unlike traditional scale-up relational databases that hit vertical single-node ceilings, Spanner combines full relational SQL semantics and multi-table ACID transactions with the horizontal scale-out elasticity for both reads and writes of a NoSQL system.

Spanner makes the Lakehouse runtime catalog highly available through Spanner’s regional configurations with up to 99.99% availability. Spanner also delivers out-of-the-box scalability for Lakehouse runtime catalog: As a horizontally scalable database, Spanner does not require manual sharding and scales compute and storage independently and transparently. Spanner dynamically monitors data volume and query load, splitting and redistributing data ranges across nodes. Compute nodes scale dynamically based on CPU utilization and storage thresholds. Spanner automatically detects split-level overload and moves heavy splits away from overloaded nodes. Spanner also lets Lakehouse runtime catalog users eliminate the traditional trade-offs between relational consistency and distributed scalability, delivering Lakehouse runtime catalog’s industry-leading consistency guarantees. Lakehouse transactions are serializable — the order of transactions within the database is the same as the order in which clients observe the transactions to have been committed. This foundation allows Lakehouse users to operate at agent-scale.

Then, to further power agentic use cases, the Lakehouse runtime catalog integrates directly with Knowledge Catalog to easily discover lakehouse Iceberg tables and provide trusted context to agents. Knowledge Catalog leverages an efficient combination of full-text search and native vector search provided by Spanner; this approach enables better recall for search retrieval, pairing lexical keyword searches with semantic embeddings in a single query. Because both index types are built on the identical base dataset, they update with strict, transactional ACID consistency alongside base table DML operations. This removes operational overhead such as managing sync pipelines, and external-vector and full-text search systems. In short, the Lakehouse runtime catalog provides faster time-to-market for your agentic use cases.

Combine analytical and operational workloads

With Google Cloud’s borderless Lakehouse based on Apache Iceberg, you can combine your analytical data with your operational workloads. Use cases span combining data assets from your Lakehouse with OLTP data (from Spanner) for analytics, to low-latency serving applications where your Lakehouse assets are accessible in an operational database such as Spanner, to conversational analytics in first-party and third-party agents.

Below, in an example, you can see the Lakehouse runtime catalog with Spanner in action. Here, we combine analytical data for taxi trips in Manhattan (backed by Apache Iceberg) with operational data for taxi zones in Spanner to find the most congested traffic routes. The example also shows that you can also use a Conversational Analytics Agent to access the same data and get second-order insights.

Find out most congested traffic routes in Manhattan

Modernize to the borderless Lakehouse

Modernizing to Google Cloud’s Lakehouse minimizes data silos across analytics engines and agents, unifies multi-engine governance, provides trusted context to your agents and slashes operational TCO. Leveraging the Spanner-based Lakehouse runtime catalog helps prepare your modern cloud environments to operate at agent-scale. To learn more and get started with a free trial, visit the

Lakehouse web page and learn more about Spanner here.

Networking for AI inference model serving - GKE only and for all other backends

Tue, 06 Oct 2026 12:00:00 +0000

Enterprises and individual developers frequently run multiple AI inference models. The right architecture can simplify how the models are called while also providing centralized governance. In this post, we'll look at two reference architectures focused on networking AI inference model serving: one for Google Kubernetes Engine (GKE) and one all other backend types. First, we'll explore the commonalities between the reference architectures that you'll see later. Then we'll explore unique components of the architecture for GKE backends and finally, we'll go over the elements of the architecture for all backend types.

The entry point

You can expose your model deployment behind a stable, secure, and reliable entry point that acts as the front end for inference calls. This entry point also acts as a control zone where policy, security, and logic can be enforced. Both the Cloud Load balancer and the Inference Gateway provide entry point capability. These types of endpoints can terminate secure connections with TLS, integrate with API management components, extend functionally with service extensions, and capitalize on capabilities of Model Armor for added security.

Common services in the designs

Both reference designs use these services:

Private Service Connect inference endpoint: Anchors the entry point inside your consumer Virtual Private Cloud (VPC) network. Traffic hits a private internal IP address, keeping inference calls in your private network.
Apigee API Management (Optional): Integrates via an Apigee Extension Processor callout to handle client identity verification, rate limits, and quota enforcement before requests ever reach compute resources.
Model Armor: Serves as an inline AI safety checkpoint, screening prompts and output completions against prompt injection and sensitive data leakage.

Design pattern serving on GKE only

This section focuses on a GKE-only backend design. To understand the full end-to-end concept, please read the entire architecture document Networking for AI inference model serving on GKE. The design pattern is based on this diagram:

In addition to the common services identified in the previous section, the design for GKE uses these components:

GKE Inference Gateway: Deployed as an internal Application Load Balancer (gke-l7-rilb). It acts as a specialized ingress engine that parses incoming request payloads, evaluates HTTPRoute rules, and steers queries to appropriate model-serving targets.
Inference pools: A logical group containing replicas of the same model. When the Gateway receives a prompt, it evaluates HTTPRoute rules to select the appropriate inference pool based on the model identifier. Pools have an initial size and can be configured to autoscale dynamically.
Model replica sets: Individual model replicas (inference server instances) deployed across single-node or multi-node GPU or TPU node pools. A replica set represents a uniform group of these model replicas.

The traffic flow GKE example

A client application that uses this GKE-based architecture to call a backend model would go through a flow like this:

Ingress: A client application in the consumer VPC issues an OpenAI-compatible API call to the local Private Service Connect endpoint, routing directly to the GKE Inference gateway using a regional internal Application Load Balancer.
Payload inspection: The Gateway reads the target model parameter specified in the request body and adds it to the HTTP headers.
Control plane validation: If Apigee is used, it checks client credentials and quotas. Model Armor screens the prompt for policy violations or data leakage.
Backend selection: The Gateway evaluates HTTPRoute mappings to identify the target pool, matches shared prefix cache context, and routes to the lowest-load GPU or TPU replica based on real-time Prometheus data.
Egress: The replica runs the inference workload. Output tokens pass through Model Armor for final response verification before streaming back over the private connection.

Design pattern serving on all backends

This section focuses on multiple backend types which can be used for inference, and it provides an overview of the architecture in the following diagram. To understand the full end-to-end concept, please read the entire architecture document Networking for AI inference model serving on all backends.

For architectures spanning mixed environments such as GKE, Cloud Run, Agent Platform, on-premises data centers, or external clouds, these additional components are used:

Regional internal Application Load Balancer: Serves as the central Layer 7 routing proxy that manages routing logic, SSL termination, and Service Extensions callouts.
Inference Payload Processor (Service Extensions): This is similar to body-based routing as used in the GKE Inference Gateway, but to enable the functionality on an Application Load Balancer a service extension is needed. A lightweight Cloud Run callout inspects the JSON body of incoming OpenAI API requests, extracts the target model identifier, and writes an X-Gateway-Model-Name header to drive URL map routing.
Network Endpoint Group (NEG): Delivers flexible routing to heterogeneous backends based on the injected model header.

All-backends traffic flow example

A client application that uses this architecture to call a backend model would go through a flow like this:

Private ingress: The client application targets the Private Service Connect endpoint over private IP address space. The regional internal Application Load Balancer receives the request.
Model name extraction: The load balancer sends the payload to the Cloud Run body-based router callout, which inspects the JSON payload and injects the X-Gateway-Model-Name header.
Policy and safety enforcement: The request passes to Apigee for identity and quota validation, then to Model Armor to scrub sensitive data and block malicious prompts.
NEG routing: The load balancer URL map inspects the model header and forwards the request to the matching backend NEG (Agent Platform, GKE, Cloud Run, Hybrid, or Internet).
Private delivery: The target backend executes the model prompt, Model Armor screens the completion, and the result returns privately along the ingress path.

What's next

Take a deeper dive into building AI workloads on Google Cloud:

Document set: Agentic AI architecture guides
Architecture Center: Multi-agent private networking patterns in Google Cloud
Document: Gemini Enterprise Agent Platform networking access overview

Want to ask a question, find out more, or share a thought? Please connect with me on Linkedin.

Where mission meets moonshot: Join us at the Google Public Sector Summit 2026

Tue, 06 Oct 2026 07:00:00 +0000

Across the public sector, the question has shifted from “what’s possible?” to “how can we drive mission impact?” We’ll be answering this question at the Google Public Sector Summit on October 20th at the Ronald Reagan Building in Washington, D.C.

This year’s summit brings together public sector leaders, creators, and builders to architect what’s next and bridge the gap between ambitious innovation and secure, scaled execution. Together, we’ll explore how public sector organizations are harnessing Google’s secure, integrated AI stack—encompassing everything from planet-scale infrastructure to leading models and agentic platforms—to turn ambitious moonshot aspirations into real-world outcomes that drive mission impact.

The Google Public Sector Summit is a celebration of what’s possible when human ambition and powerful technology come together in support of mission. Keep reading for a preview of the event, and how to make the most of your onsite experience.

Opening Keynote: Where Mission Meets Moonshot

Get inspired during our opening keynote which will feature Karen Dahut, CEO of Google Public Sector, Thomas Kurian, CEO of Google Cloud, and Chris Hein, Field CTO of Google Public Sector. They will share real-world customer examples and live product demonstrations that showcase Google’s technology in action across the public sector. Attendees will also get the opportunity to hear from public sector leaders who are collaborating with Google and applying technology to transform missions and power moonshots.

General Session: Cloud Talks

Join Elizabeth Moon, Managing Director of Customer Engineering for Google Public Sector, as she hosts a series of talks that dive deeper into the critical pillars of public sector transformation including infrastructure, AI, and security. Hear from Rich Sanzi, VP of Engineering for Google Cloud, Michael Gerstenhaber, VP of Product Management for Gemini, and Sandra Joyce, VP of Google Threat Intelligence, as they share strategies for establishing an infrastructure foundation for the agentic era, building safely with Google’s platforms, and implementing proactive defense at planet scale.

Breakouts: Panel Discussions and Birds of a Feather

Hear from Google Public Sector executives, industry partners, and leaders across defense, federal civilian, higher education, and state and local government through a series of panels and birds of a feather discussions.

From fragmented to fluid: Connecting data to build the agentic future. Moderated by Tony Orlando, Managing Director of Partner and Specialty Sales, this session will explore how agencies can break down legacy data silos and build a unified, AI-ready data foundation. Speakers include Andrew Mapes, CDAO Principal Deputy Chief Digital and AI Officer, Dr. Neil Jacobs, NOAA Administrator and Undersecretary of Commerce for Oceans and Atmosphere, and Scott Alfieri, Accenture Global Lead for the Google Business Group. An additional speaker, Adarryl Roberts, DLA CIO, has been invited.
Automating defense: Securing the agentic era against complex threats. Moderated by Ron Bushar, Managing Director and Chief Security Officer, panelists will discuss how they’re applying autonomous AI and threat intelligence to protect dynamic environments at machine speed. Speakers include Justin Fanelli, U.S. Navy CTO, Jamie Wolff, DOE-NNSA CIO, Vice Admiral (Ret.) TJ White, Texas Cyber Command Chief, and Thomas Browning, Rhombus Power Senior Vice President of Strategic Capabilities.
The agentic era: Advancing missions and transforming the way we work. Moderated by Elizabeth Moon, this session will highlight how secure, cost-efficient agentic capabilities can scale impact and advance missions. Featured speakers include Barry J. Schindler, USPTO Acting Commissioner for Patents, Miro Humer, Case Western Reserve University CIO, and Todd Johnston, Deloitte Managing Director, AI & Engineering and Defense, Security & Justice AI/Analytics Leader.
Interactive Birds of a Feather discussions. Connect directly with a small group of peers and Google experts to address critical mission blockers, share best practices, and accelerate your agency's journey beyond the pilot stage. Join discussions across a range of topics including tokenomics, migration, and compliance.

Demos, Lightning Talks and Labs

Experience Google’s innovations through hands-on labs, Lightning Talks, and demos taking place in the Mission Exchange on the showfloor. Topics will include agentic threat defense, multimodal AI citizen services, and legacy database modernization with AI.

Attendees can also join two expert-led labs:

Getting Started with Gemini: This introductory lab will guide participants through the fundamentals of Gemini and Gemini Notebook to summarize documents, search data and streamline daily tasks. No technical background required.
Build Gemini Agents: From Prompt to Prototype: This lab will help you bring your real-world agency use cases to life by building an AI agent with Gemini, with support from Google Cloud specialists.

Throughout the day, we will host Lightning Talks, which are dynamic 20-minute presentations featuring live demos and interactive Q&A that take place on the showfloor. These talks feature partner and customer speakers and showcase the "art of the practical" through live, real-world solutions.

Closing Session: What’s Your Moonshot?

Join us for an inspirational closing session that I’ll moderate with a special guest: NASA Administrator Jared Isaacman. Together, we’ll define what a moonshot means for the public sector in the agentic era and share strategies for fostering a culture of courageous problem-solving and applying technology to supercharge human ambition and ingenuity.

Register for the Google Public Sector Summit

Beyond the personalized programming and practical hands-on experiences, attendees will leave the event with a customized action plan for driving impact in their organization. Register today for the Google Public Sector Summit to gain the strategies, skills, and inspiration to turn your moonshot aspirations into a reality. Join us as we build what’s next for the public sector, together.

AlloyDB: A unified database engine for hybrid search

Tue, 06 Oct 2026 07:00:00 +0000

For modern AI and RAG applications, achieving high search relevance requires that you combine at least two techniques: vector search for semantic context, and full-text search (FTS) for keyword precision. While AlloyDB for PostgreSQL supports both of these capabilities, managing them has traditionally required a more hands-on operational approach to ensure peak performance.

The challenge is not executing the searches, but the subsequent fusion of result sets. Merging results from the vector query (distance scores) and the FTS query (relevance scores) requires complex SQL queries or custom code in the application layer. This often means maintaining a separate system for fusion, score normalization, and re-ranking.

This article details how AlloyDB AI's hybrid search eliminates this complexity. We will explore how recent updates allow you to:

Simplify hybrid search: Consolidate complex SQL queries, or multi-step application workflows into a single, high-performance SQL function powered by Reciprocal Rank Fusion (RRF).
Optimize FTS performance: Use the new RUM extension to achieve low-latency relevance ranking and efficient phrase matching by storing word positions directly in the index.
Leverage industry-standard ranking: Utilize the new natively supported BM25 index for superior keyword-based scoring directly out of the box.
Expand search versatility: Execute queries against specialized external clusters, including Elasticsearch, OpenSearch, and Solr, using the new external search Foreign Data Wrapper (FDW) without leaving the AlloyDB environment.

The problem of the multi-step workflow

Before AlloyDB AI's native solution, achieving robust hybrid search was very demanding, especially for developers trying to keep this logic within the database using standard SQL. This approach required multi-step orchestration that was not only difficult to manage and maintain for two sources, but became virtually impossible to scale as additional sources were added. These steps included:

Executing vector search: Run a query using a vector column or vector index (for AlloyDB this can be a ScaNN index) to find top k results, generating vector scores.
Executing the FTS query: Run FTS query e.g. by using a generalized inverted index, or GIN, to find top k results.
Normalizing scores (the brittle step): Write complex SQL logic or custom application code to map both result sets onto a common scale. This logic is prone to breaking when data distributions change.
Performing cross-service joins and re-rankings: Use application memory to perform a complex FULL OUTER JOIN on document IDs, apply a weighted summation of the normalized scores, and finally sort the combined results in cases where the FTS search was done in a separate system than the one used for vector search.

This decentralized approach led to fragile score logic, increased latency, high operational load, and a dependency on application expertise for maintaining search quality.

Simplifying hybrid search architectures with AlloyDB

The key to simplifying this is to adopt RRF, which, because it is inherently rank-based, cleverly bypasses the brittle step of score normalization entirely. RRF consists of two parts:

1. The single source of truth

Instead of a multi-step fetch and join process, you simply call one SQL function, providing your search components as a declarative JSON array:

SQL

code_block: <ListValue: [StructValue([('code', 'SELECT id, score \r\nFROM ai.hybrid_search(\r\n search_inputs => ARRAY[\r\n -- Vector Component (Semantic) with dynamic embedding generation from natural language\r\n $json${\r\n "data_type": "vector",\r\n "limit": 10,\r\n "table_name": "documents",\r\n "key_column": "doc_id",\r\n "vec_column": "embedding",\r\n "distance_operator": "<=>",\r\n "query_vector": "ai.embedding(\'text-embedding-005\', \'alloydb search\')::vector"\r\n }$json$::jsonb,\r\n \r\n -- Text Component (Keyword)\r\n $json${\r\n "data_type": "text",\r\n "limit": 10,\r\n "table_name": "documents",\r\n "key_column": "doc_id",\r\n "text_column": "content",\r\n "query_text_input": "alloydb search"\r\n }$json$::jsonb\r\n ]\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42fb92ad0>)])]>

(Note: The unified ai.hybrid_search API isn't limited to just two components. It also natively supports external search sources via the new FDW).

2. Database-native orchestration

The hybrid_search() function executes the entire workflow in a single query plan, minimizing overhead and helping ensure transaction consistency. It uses:

Dynamic CTE generation: The function constructs dynamic SQL, creating Common Table Expressions (CTEs) for each component. Each CTE is responsible for calculating the positional rank (ROW_NUMBER()) of its results.
Kernel-level fusion: All ranked component results are immediately combined using a FULL OUTER JOIN based on the document ID.
Final RRF score: The combined ranks are used to calculate the final, unified score using the RRF formula:

By taking this approach, brittle score calculations and application-side joins become unnecessary. While Reciprocal Rank Fusion (RRF) is our current ranking algorithm, we intend to introduce additional merging and ranking options down the road.

The result: Performance and operational simplicity

Moving from complex external workflows to native SQL functions provides immediate, measurable benefits:

Metric	Multi-step application workflow (simulated by manual SQL)	AlloyDB AI-native hybrid_search() UDF
Code complexity	Complex score normalization functions, service calls, and application joins.	Zero external logic; a single, declarative SQL call.
Maintenance	Constant tuning of normalization formulas.	No tuning required; RRF is rank-based and distribution-agnostic.

Enhancing FTS performance: The RUM extension

AlloyDB AI's hybrid_search() function is designed to deliver comprehensive search relevance by combining high-performance vector search with FTS. While AlloyDB's native FTS capabilities are powerful, reliance on the standard PostgreSQL GIN index for the text component can present a bottleneck for advanced operations.

The challenge with GIN indexes is that they do not store the positional information of words. This limitation forces costly table scans to re-analyze content for:

Relevance ranking: Calculating search result scores based on word proximity and frequency
Phrase searching: Finding exact word order, which requires positional information.

Introducing the RUM extension for low-latency FTS

The RUM extension is a powerful index access method based on GIN that directly resolves these performance issues.

RUM's core advantage: Unlike the GIN index (which maps word -> [docID]), the RUM index stores the positional information of each word directly within the index (e.g., word -> [(docID1, [pos])], ...).
Performance benefits: This allows RUM to perform complex operations like ranking and phrase matching predominantly within the index itself, avoiding expensive heap scans. RUM provides significantly faster relevance ranking and efficient phrase and proximity searches.
Great for hybrid search: RUM is a critical complement to vector search (like ScaNN) within a hybrid search framework, as GIN’s potential latency makes it less suitable for a real-time hybrid approach.

The RUM extension is an excellent choice for ranking-heavy or high-concurrency search applications. By storing word positions directly in the index, RUM cuts out the need to re-scan table pages during ranking, giving you fast and sorted results. However, it comes with some trade-offs: slower index builds and a larger disk footprint. If your workload prioritizes quick queries and precise ranking over write speeds and storage density, RUM is an investment that's well worth it.

Measurable gains and integration

Adopting RUM directly bolsters the performance of FTS in AlloyDB, showing considerable gains for raw FTS queries, as well as gains on hybrid search that includes FTS queries. Below are performance statistics showing the speedup between using RUM compared to GIN on various BEIR datasets.

(Performance based on tests using the BEIR Natural Questions benchmark.)

RUM integrates with the specialized <=> distance operator for search and ranking, which is supported for use in hybrid search SQL calls, delivering the best of both worlds. The following codelab shows how to configure and use the RUM index with the Hybrid Search UDF.

Introducing BM25 Index: The modern ranking standard

We recently introduced the BM25 index to CloudSQL and AlloyDB in preview, bringing the industry-standard relevance ranking via the pg_textsearch extension. BM25 uses TF-IDF, which accounts for term frequency saturation and document length normalization, delivering significantly higher precision and quality for keyword-based search queries. By leveraging native BM25 indexes within AlloyDB AI, you can achieve superior ranking accuracy out of the box, so that exact-term matches and critical keywords score well without having to implement external search engines or complex custom scoring logic.

code_block: <ListValue: [StructValue([('code', "-- Install pg_textsearch extension\r\nCREATE EXTENSION pg_textsearch;\r\n\r\n-- Create the native BM25 index on the content column\r\nCREATE INDEX idx_docs_bm25 \r\nON cymbal_products \r\nUSING bm25 (product_description) \r\nWITH (text_config='english');\r\n\r\n-- Full text search query\r\nSELECT product_name, product_description <@> 'cherry tree' AS bm25_score \r\nFROM cymbal_products\r\nORDER BY bm25_score \r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f9bba50>)])]>

External search: Extending versatility with foreign data wrappers

To further extend search capabilities, we also introduced the external search Foreign Data Wrapper (FDW) in AlloyDB AI. This lets you execute full-text searches against specialized external clusters, starting with Elasticsearch, OpenSearch, and Solr, and provides several key architectural advantages:

Optimized retrieval: Leverage ranking algorithms and a richer feature set from dedicated search backends without leaving the AlloyDB environment.
Unified SQL interface: Interact with external data, perform joins, and meld results using standard PostgreSQL SQL without losing the expressiveness of advanced FTS queries.
Strong portability: Maintain existing search infrastructure while benefiting from the simplified hybrid architecture offered by AlloyDB AI.

The following codelabs are end-to-end code guides walking through hybrid search with Elasticsearch and Solr integrations.

A unified architecture for AI-powered search

The true challenge of modern search is not technical in nature, but in achieving architectural simplicity and sustained operational stability. AlloyDB AI addresses this with a unified platform built on three core innovations:

Simplifying hybrid search: AlloyDB AI’s hybrid search function, powered by RRF, transforms a fragile, multi-step application workflow into a single, high-performance SQL call. This native implementation eliminates the need for complex score normalization and application-side joins, drastically lowering the operational and engineering cost while delivering consistently accurate and fast hybrid relevant results.
Optimizing FTS performance: To ensure the FTS component of Hybrid Search meets diverse application demands, AlloyDB AI offers distinct full-text search options. The RUM extension optimizes for low-latency performance by storing positional data directly in the index to enable faster relevance ranking and efficient phrase searches — important when you need fast query speeds. Alternatively, the BM25 index provides industry-standard relevance ranking, and is the preferred choice when prioritizing keyword scoring precision. You can select between these options depending on whether your focus is search latency or ranking precision.
Enhancing versatility through external search: The addition of the external search through FDW extends AlloyDB’s reach to specialized search backends like Elasticsearch. This lets you leverage the superior scale and advanced retrieval features of dedicated search clusters while maintaining a familiar PostgreSQL interface. By integrating these external results directly into the hybrid search framework, AlloyDB AI ensures that you can combine even the most massive text repositories with vector-based semantic insights.

By consolidating the complexity of scoring, joining, and re-ranking within the database kernel, and offering a dual-path approach to FTS — leveraging RUM for optimized, low-latency, internal FTS or external search for specialized, scalable backends — AlloyDB AI delivers a robust and self-contained search foundation. This coexistence is essential to the overall hybrid search story, providing the flexibility to choose the optimal path based on workload, data volume, and existing infrastructure. Now, you can focus on building intelligent application features, confident that your search architecture is both highly performant and easy to maintain.

Watch it in action

Watch how AlloyDB is the ultimate hybrid search engine.

Learn about BM25 support in AlloyDB.

Getting started

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

New to AlloyDB? Discover AlloyDB with a 30-day free trial.
Getting started with hybrid search: Set up a text-search index and select a vector search index. Once these are created, you can find some examples to perform various hybrid search queries.
External search: Create a foreign data wrapper and foreign table in AlloyDB to query external data from Elasticsearch, Solr, or OpenSearch.

Introducing Google Cloud Modernize, transforming for (and with) AI

Mon, 05 Oct 2026 16:00:00 +0000

Today, we’re announcing Google Cloud Modernize, an end-to-end transformation portfolio to help enterprises collapse multi-year roadmaps with the power of AI.

Google Cloud Modernize brings together Google Cloud’s proven migration and modernization tools, including Migration Center, Google Cloud VMware Engine, Google Cloud Mainframe Modernization and our new EKS-to-GKE Migration Agent, into a single portfolio. With it, enterprise teams now have purpose-built agentic capabilities across infrastructure assessment, platform modernization, and application modernization.

Central to this portfolio is Modernization Hub, a newly launched in-console experience where developers and architects can analyze source code, map dependencies, and accelerate modernization for Java, .NET, and mainframe applications.

Agentic infrastructure assessment

Every transformation begins with an accurate assessment. With new Gemini capabilities in Migration Center, the Agentic Quick Estimator (GA) converts VMware inventory exports (such as RVTools) and infrastructure inputs into total cost of ownership (TCO) projections for your Compute Engine environment.

Using an interactive chat interface, teams can test real-time modeling assumptions, such as evaluating multi-region footprints or comparing BYOL licensing against pay-as-you-go, to discover contextual cost optimizations. This condenses weeks of spreadsheet modeling into a defensible business case in minutes.

Migration Center’s Quick TCO Estimator and agentic chat interface

For specialized support, we also provide a comprehensive modernization assessment at no cost through our Rapid Migration & Modernization Program (RaMP).

Platform modernization

With the rise of real-time AI agents querying backend systems, workloads increasingly require high-throughput infrastructure that removes I/O bottlenecks. Once you’ve defined your target environment using our assessments, there are several new purpose-built compute options for mission-critical workloads:

SAP S/4HANA at scale (X5 Series, GA): Delivers single-node 43 TiB memory configurations that remove the previous 29 TiB ceiling, allowing enterprise ERP estates to run without distributed partitioning overhead.
Core-optimized database performance (M4N Series, GA): Delivers 26.57 GiB RAM per vCPU paired with Hyperdisk Extreme. This prevents organizations from overprovisioning compute cores to meet memory requirements, reducing software licensing costs by more than 20% for Oracle and other core-licensed databases.
Ultra-low latency data engines (Z4D, GA and Z4M, Preview): Deliver up to 84,000 GiB and 168,000 GiB of high-speed local NVMe SSD respectively, 400 Gbps networking for both Z4D and Z4M, and RDMA support for Z4M. This throughput reduces I/O wait times and prevents query timeouts when real-time AI agents query vector stores, operational databases, and large-scale data pipelines.

Cloud elasticity for VMware environments

For organizations operating VMware estates that need the elasticity of the cloud but aren’t ready to re-architect their environment, the Google Cloud self-managed VMware solution provides administrative control on Bare Metal Z3 shapes with VMware Cloud Foundation (VCF) 9.1. Native global VPC links connect VMware estates directly to Compute Engine, Google Kubernetes Engine (GKE), BigQuery, and Gemini Enterprise, allowing teams to ground autonomous agents in operational data without code changes.

Automated container transitions to GKE

The new EKS-to-GKE Agentic Migration (Public Preview) automates transitions from AWS Elastic Kubernetes Service to GKE thanks to:

An automated pipeline: Manages discovery, Kubernetes manifest translations, storage and network mappings across clouds.
Enterprise-grade security: Built-in Human-in-the-Loop (HITL) approval gates and in-memory credential security maintain strict GitOps compliance.
A fast-track to modern runtimes: Quickly moves workloads to GKE to take advantage of low-latency model serving, autoscaling, and multi-agent orchestration.

NetEase Games demonstrated the value of this platform approach by containerizing services on GKE, reducing infrastructure scaling times from hours to five minutes during peak launches while cutting server costs by 40%:

"By integrating diverse computing instances and powerful orchestration, we have transformed our infrastructure into a competitive advantage, ensuring NetEase remains a leader in the global gaming market." - Deng Ding, Director of Site Reliability Engineering, NetEase Games

Application modernization with Modernization Hub

Landing on modern infrastructure enables teams to unlock legacy business logic and modernize their core applications. Modernization Hub centralizes several modernization tools directly inside the Google Cloud console.

.NET and Java modernization

Modernization Hub integrates the Google Cloud App Modernization CLI (CodMod), which uses Gemini to analyze large source code repositories, understand legacy application architectures,maps hidden dependencies, identifies modernization challenges and generates modernization recommendations. This enables customers to migrate legacy .NET Framework applications to modern .NET Core running on Linux containers, reducing OS licensing overhead, while also making these applications and data accessible to modern AI agent workflows.

Modernization Hub’s in-console interface

Mainframe modernization

For customers running mainframes, we provide specialized solutions to help accelerate and de-risk end-to-end application transformation to Google Cloud:

Mainframe Assessment Tool: Parses legacy mainframe codebases, extracts business rules, maps application and data dependencies to generate cloud-ready target application specifications and power agentic modernization workflows.
Dual Run: Substantially reduces cutover risk by replaying live production transaction streams simultaneously across the mainframe and the new cloud applications, verifying functional equivalence before going live.
Mainframe Connector: Copies mainframe data directly into Google Cloud services (BigQuery, AlloyDB, GCS and others), , unlocking legacy data and supports hybrid architectures.

Intesa Sanpaolo used Google Cloud mainframe modernization solutions to accelerate their core banking transformation off the mainframe and onto Google Cloud:

“To confidently move forward with Mainframe Modernization, we will need to provide confidence and assure the bank's leadership and internal control units as well as get approval from the regulators. One of the enablers for this is Google Cloud Dual Run, which is gradually providing the evidences to build such confidence to all three groups.” - Claudio Balbo, Head of IT Architecture, Intesa Sanpaolo

A proven track record and partner ecosystem

Deutsche Börse Group transitioned its mission-critical SAP S/4HANA environment and DAX® index calculations to Google Cloud, cutting disaster recovery times from hours to minutes, reducing aggregation latency by over 50%, and shortening development cycles from months to days.

To deliver these capabilities at enterprise scale, we are also collaborating with our global partner ecosystem to integrate Google Cloud Modernize with enterprise delivery frameworks, including Cognizant:

“Google’s modernization offering heralds the next frontier of AI-native modernization — enabling enterprises to autonomously decode legacy complexity and accelerate into cloud-first, intelligent architectures. Coupled with Cognizant's AI-led, governed delivery engine, we amplify this shift through agentic business processing, unlocking faster, outcome-driven value at scale.” - Nishant Upadhyaya, Global Practice Head – Digital Engineering, Cognizant

Accelerate your transformation now

Modernizing your infrastructure and applications is the baseline requirement for enterprise AI agility. Google Cloud Modernize equips teams to navigate each phase safely and efficiently as they pursue AI readiness and adoption.

Get started:

Join the webinar: Register for our upcoming session on November 17 to see live demos of Modernization Hub and our agentic migration tools.
Explore the console: Log into the Google Cloud Modernize console to access Modernization Hub.
Start planning: Visit the Google Cloud Modernize webpage, or request a modernization assessment at no cost today.

AI21 achieves an 83% reduction in time-to-start for AI workloads with AI Hypercomputer

Fri, 02 Oct 2026 19:00:00 +0000

Editor’s note: AI21 Labs is a leading global AI lab with a long track record of building foundation models, most notably the Jamba family, and today focuses on specialized LLMs and agent optimization technology. By adopting Google Cloud AI Hypercomputer, AI21 cut high-priority job wait times from 72 hours to 12 and manual scheduling interventions from 20 per week to zero.

At AI21, we build foundation models and agent optimization products that help enterprises run agents at frontier quality, efficiently. Our language models, including the Jamba family, and our agent optimization product suite run demanding production workloads, including our own. We chose Google Cloud AI Hypercomputer to support them at scale.

To keep our model training runs highly utilized, we needed a performant, scalable environment codesigned across infrastructure, orchestration, and consumption models. Our model training runs on one of our shared Google Kubernetes Engine (GKE) clusters, pooling thousands of Google Cloud A3 (powered by NVIDIA H100 Tensor Core GPUs) and A3 Ultra (powered by NVIDIA H200 Tensor Core GPUs) instances, so any team can draw on the full capacity of the fleet rather than being boxed into its own slice. The cluster also trains models and agent-optimization workloads beyond the Jamba family. That approach keeps utilization high, and it makes scheduling hard.

The gridlock of high-utilization clusters

Prior to leveraging GKE for orchestration, we used to negotiate capacity by hand in Slack. If you needed capacity for a training run, you posted in #gpu-resources and hoped for the best.

That worked fine when the cluster had headroom. It stopped working once utilization pinned near 100%, which is where you want a reserved compute fleet to sit.

Over time, every request became a negotiation. Team leads spent their time refereeing compute disputes. Our high-priority jobs — the large, multi-node training runs that need half or more of the cluster at once and serve as the critical path for model projects — could sit blocked for up to 72 hours waiting for enough contiguous capacity to open up.

Figure 1: A typical day on #gpu-resources — manual requests, ad-hoc coordination, and researchers waiting on replies.

Scarcity created two distinct problems, and it took us a while to see them as separate. The first was contention: determining who gets compute access next, which we resolved through negotiation. The second was fragmentation: capacity that was technically free but scattered in pieces too small for a large job to use, a bin-packing problem no amount of negotiation could fix.

Figure 2: GPU fragmentation. 8 free GPUs scattered as 1+1+4+2 across four nodes can’t fit an 8-GPU workload.

Sometimes we had plenty of capacity free on paper, but it was scattered across different machines in chunks too small for a larger job to actually land. Without all-or-nothing admission, the cluster could reach a deadlock, with machines holding resources without doing useful work until someone stepped in manually.

It was clear the status quo wasn’t working and we needed something better.

Choosing the right scheduler

We looked at a few open-source batch schedulers, including Apache YuniKorn, Volcano, and Kueue. YuniKorn didn’t cover all our use cases. And while Volcano had more features, integrating it with our environment would have required replacing core Kubernetes scheduler components.

Kueue won on simplicity and integration. It worked with standard Kubernetes, didn’t require replacing core components, and didn’t force us to rewrite our job specs.

Pairing Kueue with AI Hypercomputer’s flexible, open operations through GKE also contributed to our success. We rely on GKE because it gives us the right level of control for compute-intensive AI work — close access to GPU hardware and drivers, without the overhead of managing raw instances ourselves. Kueue’s native integration with GKE, including with Google Cloud capacity types like Spot VMs and Dynamic Workload Scheduler, meant that once our reserved capacity filled up, the same scheduling logic could reach out to elastic capacity automatically instead of leaving jobs stuck.

Closing the loop with open source

Adopting Kueue turned into something bigger than a simple process change. Because we partner with Google Cloud, we have a direct line to a Technical Account Manager, who saw an opportunity to make AI21 a design partner for the Kueue team. This way, we wouldn’t just be a user, but a source of real production requirements that could help shape where the tool went next.

One of the first things to come out of that partnership was a requirements document we shared with the Kueue team, describing behavior we needed that didn’t exist yet: fair admission ordering across teams for multi-node jobs, without the preemption that usually comes bundled with fairness. The Kueue team built it. Admission Fair Sharing (AFS) reorders the admission queue to favor teams that have historically used less capacity without disrupting jobs already running. Around the same time, we also turned on Topology Aware Scheduling. This existing feature made Kueue aware of our physical cluster layout, so it can refuse to admit jobs that won’t fit on a single node rather than placing them with nowhere to run.

For us, that’s what the best-case open-source feedback loop looks like: Real requirements surfaced through production use, fed directly back into Kueue.

Same fleet, less friction

The Slack #gpu-resources channel is archived now. Every workload, whether a debug pod, a multi-node training run, or an inference deployment, gets queued, prioritized, and scheduled automatically. The results were immediate. Manual interventions dropped from about 20 a week to zero. High-priority jobs that used to wait up to 72 hours now wait 12. Fragmentation across the cluster fell from 15% to 8%, and the “zombie job” problem — workloads partially admitted with nowhere to run — is gone.

None of this changed our total cost. We run our reserved fleet at close to 100% utilization on purpose, so raw spend was never the variable we were optimizing. What changed is where our people’s time goes. Team leads aren’t refereeing compute disputes anymore, and researchers aren’t waiting on replies in Slack. That frees everyone to run more experiments and iterate faster.

Announcing Spanner queues: Transactional messaging for agentic workloads and beyond

Fri, 02 Oct 2026 16:00:00 +0000

AI agents don't just answer queries — they can autonomously issue refunds, manage inventory, execute multi-step handoffs, and orchestrate sub-agents, to name but a few complex agentic workflows. That frequently requires the agents to maintain internal state in an operational database while dispatching asynchronous actions through a separate messaging or event queue system. And unfortunately for the teams building these applications, managing two systems with disjointed commit points destroys transactional consistency in agentic systems.

Today, we are excited to announce the general availability of Spanner queues: native transactional messaging embedded directly within Spanner. Designed specifically for reliable agentic execution, with Spanner queues, creating a message is simply another write in your transaction. An agent's state change and intended downstream actions commit together atomically or fail completely.

Compare this to traditional approaches: When a database state update succeeds, but the action dispatch fails, your AI agent decides to act but doesn’t execute. If the message dispatch succeeds but the state transaction rolls back, your agent executes an action based on an invalid state. In asynchronous multi-agent coordination, retries, speculation, and race conditions amplify these failures, forcing developers to build complex outbox patterns, idempotency layers, and reconciliation workers — a heavy reliability tax on agentic architecture.

Key capabilities for agentic architectures

Spanner queues introduces several core capabilities to support these complex asynchronous workflows without introducing infrastructure overhead.

Atomic decide-and-act enqueue. Within a single Spanner read-write transaction, agents can update internal memory or state tables and enqueue tasks to peer agents simultaneously. Backed by Spanner's strict serializability and global external consistency, state changes and execution intent commit as a single atomic unit.

Scheduled execution and delays. Queue messages can be dispatched immediately upon commit or scheduled for future delivery. Agentic patterns such as delayed retries, scheduled agent check-ins, or SLA escalation timers can be enqueued transactionally alongside memory updates without requiring external cron schedulers or polling infrastructure.

Streaming SQL pull for agent workers. Autonomous agents consume tasks dynamically using streaming SQL reads. Agent runtimes stream incoming tasks, process them as capacity becomes available, and acknowledge task completion within a transaction to guarantee end-to-end task execution state reliability.

Episodic memory persistence and handoffs. Agent memory updates — including long-term episodic summaries, reflective state transitions, and context handoffs across sub-agents — can be persisted asynchronously and transactionally via queues. This guarantees that an agent's internal memory remains fully synchronized with its execution history without blocking real-time interactive turns.

Why Spanner queues are essential for autonomous agents

Transactional exactly-once agent execution: When an agent evaluates tool call results, state modification, reasoning persistence, and downstream tool invocation tasks are saved in one transaction. We guarantee at-least-once delivery and at-most-once ACK, enabling you to achieve exactly-once processing.

Robust multi-agent orchestration and handoffs: In multi-agent systems (A2A), handing off state from a primary agent to a specialist agent is represented as a durable, transactionally committed message. Specialist agent workers receive deliverable messages while maintaining a fully auditable lineage of agent interactions.

First-class timeouts and human-in-the-loop workflows: Agent workflows frequently require pausing for human approvals or scheduled follow-ups. Spanner queues handles timeout management natively: A single transaction records the pending approval state and schedules an automated escalation message, resolving whichever triggers first.

SQL-native observability for agent queues: Inspecting in-flight agent workloads, monitoring task backlogs, or auditing agent execution history can be accomplished with standard SQL queries over queue tables, avoiding opaque message-store black boxes.

Beyond agentic workflows

Beyond AI agents, Spanner queues serves as a flexible, multi-purpose messaging platform across a variety of traditional event-driven architectures. Whether powering real-time activity feeds in social applications, delivering live updates in news publishing, orchestrating order processing and inventory workflows in retail, or handling high-throughput asynchronous task processing and transaction notifications in financial services, Spanner queues provides a robust foundation for asynchronous message delivery and transactional event-driven workflows within your primary database.

Under the hood: Transactional mechanics of Spanner queues

Because Spanner queues are represented as first-class relational structures in Spanner, you define, inspect, and manage queues using familiar GoogleSQL.

1. Defining a queue and enqueuing atomically

When an agent decides to approve a customer refund, it updates the Orders table and dispatches an execution task to the OrderAgentTasks queue within a single ACID transaction:

code_block: <ListValue: [StructValue([('code', '-- Assume parent table:\r\n-- CREATE TABLE Orders (\r\n-- OrderId STRING(64) NOT NULL, ...\r\n-- )\r\n-- PRIMARY KEY (OrderId);\r\n\r\n-- Define the transactional queue table\r\nCREATE QUEUE OrderAgentTasks (\r\n OrderId STRING(64) NOT NULL,\r\n TaskId STRING(64) NOT NULL,\r\n TaskType STRING(64) NOT NULL,\r\n Payload JSON NOT NULL\r\n) PRIMARY KEY (OrderId, TaskId, TaskType), INTERLEAVE IN Orders;\r\n\r\n-- Inside a Read-Write Transaction:\r\n-- 1. Update business state atomically\r\n\r\n-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET Status = \'REFUND_APPROVED\',\r\n UpdatedAt = PENDING_COMMIT_TIMESTAMP()\r\nWHERE OrderId = @orderId;\r\n\r\n-- 2. Enqueue the asynchronous agent action in the same transaction\r\nINSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload)\r\nVALUES (\r\n @orderId,\r\n @taskId,\r\n \'EXECUTE_REFUND\',\r\n JSON \'{"action": "execute_refund", "amount": 49.99}\'\r\n);\r\n\r\n-- COMMIT;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cd2e010>)])]>

This ensures that the EXECUTE_REFUND task exists if and only if the order status successfully transitioned to REFUND_APPROVED.

2. Temporal scheduling and atomic cancellation

For workflows that depend on time — such as waiting up to 72 hours for a manager's approval before escalating — agents populate the system DeliverTime column to defer message visibility:

code_block: <ListValue: [StructValue([('code', '-- Schedule an automated escalation check-in 72 hours in the future\r\nINSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload, DeliverTime)\r\nVALUES (\r\n @orderId,\r\n @escalationTaskId,\r\n \'ESCALATE_UNAPPROVED_ORDER\',\r\n JSON \'{"action": "escalate_to_supervisor"}\',\r\n TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 72 HOUR)\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cd2edd0>)])]>

If the manager approves the request after four hours, your application doesn't have to deal with phantom escalation alerts firing days later. In a single transaction, you update the order status and cancel the pending escalation task using a standard SQL DELETE:

code_block: <ListValue: [StructValue([('code', "-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET Status = 'MANAGER_APPROVED',\r\n ApprovedBy = @managerId\r\nWHERE OrderId = @orderId;\r\n\r\n-- Atomically cancel the pending delayed escalation task. `ASSERT_ROWS_MODIFIED 1` will\r\n-- act as a safeguard and cause a statement level error.\r\n\r\n-- A statement level error can be captured and the transaction can be\r\n-- user-aborted/cancelled in case the queue entry was already deleted.\r\n-- Otherwise the transaction will complete successfully regardless if the \r\n-- queue entry still exists and you'll only know if a queue entry was deleted by\r\n-- checking the number of rows affected by the DELETE.\r\nDELETE FROM OrderAgentTasks\r\nWHERE OrderId = @orderId\r\n AND TaskId = @escalationTaskId\r\n AND TaskType = 'ESCALATE_UNAPPROVED_ORDER',\r\nASSERT_ROWS_MODIFIED 1;\r\n\r\n-- COMMIT;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cd2de90>)])]>

3. Streaming consumption, lease renewal, and atomic acknowledgment

Downstream agent workers consume tasks using the RECEIVE_<QueueName> table-valued function (TVF) over a streaming SQL connection (ExecuteStreamingSql). Spanner automatically manages message leases, returning a unique SpannerLeaseToken and expiration timestamp with each leased task:

code_block: <ListValue: [StructValue([('code', "-- Step 1: Consume tasks via a long-lived streaming SQL query\r\nSELECT\r\n OrderId,\r\n TaskId,\r\n TaskType,\r\n Payload,\r\n SpannerLeaseToken,\r\n SpannerLeaseExpirationTimestamp\r\nFROM RECEIVE_OrderAgentTasks(max_duration => '20m');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cd2c790>)])]>

Because AI agent tasks often involve multi-turn LLM reasoning or external API calls that take longer than default lease windows, workers can actively extend their lease using the RENEWLEASE_<QueueName> function:

code_block: <ListValue: [StructValue([('code', '-- Step 2: Extend lease ownership during long-running agent execution\r\nSELECT *\r\nFROM RENEWLEASE_OrderAgentTasks(lease_tokens => [@leaseToken]);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cd2cfd0>)])]>

When the agent finishes executing its external tool (passing TaskId as the external API's idempotency key), it opens a read-write transaction to record the final state and acknowledge the message by deleting it with ASSERT_ROWS_MODIFIED 1:

code_block: <ListValue: [StructValue([('code', "-- Step 3: Atomically checkpoint agent results and ACK the message\r\n-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET RefundTransactionId = @externalRefundId,\r\n Status = 'REFUND_COMPLETED'\r\nWHERE OrderId = @orderId;\r\n\r\nDELETE FROM OrderAgentTasks\r\nWHERE OrderId = @orderId\r\n AND TaskId = @taskId\r\n AND TaskType = @taskType\r\nASSERT_ROWS_MODIFIED 1;\r\n\r\n-- COMMIT;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cd2ea10>)])]>

Using ASSERT_ROWS_MODIFIED 1 protects your system against lease-expiration races. If a worker stalled due to a network pause and its lease expired, another worker may have already processed and deleted the task. When the stalled worker resumes and attempts to execute the statement, ASSERT_ROWS_MODIFIED 1 detects that the queue row is already gone and throws a statement-level error. Catching that error and aborting that transaction prevents stale workers from overwriting newer database state.

Spanner change streams vs. Spanner queues

Spanner change streams capture database data changes (inserts, updates, and deletes) in near real-time for downstream integration and auditing. While both change streams and queues allow applications to react to data changes, Spanner change streams are designed for continuous change data capture (CDC) and data streaming to downstream analytics or storage. In contrast, Spanner queues are explicitly designed for transactional task orchestration, supporting native message leases, scheduled deliveries, SQL-based pulling, and atomic acknowledgments within read-write transactions.

Get started

Spanner provides a unified foundation for agentic data, combining relational, hybrid search, graph, and key-value capabilities under strict global consistency. Spanner queues completes the agentic loop by enabling agents to transition seamlessly from reasoning over data to executing transactional actions within a single unified platform. Spanner queues are now generally available.

Sign up for the Spanner 90-day free trial and read up our public documentation to start building resilient, exactly-once agentic workloads by creating a queue table in your Spanner database today.

GKE CPU startup boost: Accelerate app starts without over-provisioning

Fri, 02 Oct 2026 16:00:00 +0000

Whether you’re launching microservices in response to sudden traffic spikes, deploying new software releases, or scaling up application replicas, pod startup time is critical to maintaining a fast, responsive user experience for applications running on Google Kubernetes Engine (GKE).

Yet, platform engineers and developers face a persistent dilemma: Applications often demand significantly more CPU power during startup than they do during steady-state operations. Sizing CPU requests for normal, steady-state usage leads to CPU throttling during launch, which can result in sluggish cold starts and readiness probe timeouts. On the flip side, over-provisioning baseline CPU requests to satisfy short-lived startup bursts wastes valuable compute resources, inflating infrastructure bills.

Today, we are excited to announce CPU startup boost for GKE in preview. Integrated directly into GKE's Vertical Pod Autoscaler (VPA), CPU startup boost dynamically elevates a container's CPU allocation during initialization and seamlessly scales it back to baseline steady-state levels once the application is ready - all without restarting your containers.

Why modern applications need extra CPU at boot time

When a new container launches, it may perform intensive initialization tasks before it begins serving user requests. Depending on your tech stack, the following startup workloads require substantial CPU cycles:

Java JVM applications: Frameworks like Spring Boot require high CPU burst capacity for class loading, classpath scanning, instantiating dependency injection containers, and running Just-in-Time (JIT) compilation.
Node.js servers: Apps parse JavaScript files, build complex module dependency trees (require/import), and execute V8 engine optimization and JIT compilation passes during initial execution.
Python and AI/ML microservices: These services spend initial cycles importing heavy libraries (such as PyTorch, NumPy, or LangChain), compiling .pyc bytecode, establishing ORM database schemas, and pre-loading cache structures.

If you size CPU requests strictly for steady-state performance, these initialization workloads experience CPU throttling on launch, delaying readiness probes. To prevent slow cold starts, teams frequently overprovision CPU requests. However, once the application stabilizes, those extra CPU resources sit idle, increasing your cloud spend without adding value.

How CPU startup boost can help

CPU Startup Boost solves this by giving your workloads temporary vCPU "boosts" during launch, and automatically returning them to baseline once initialization completes.

Key benefits:

Faster cold starts: Reduce application initialization times by up to 2x, accelerating auto-scaling responsiveness during unexpected traffic surges.
Optimized cloud spend: Right-size steady-state CPU requests to fit actual runtime needs rather than paying for idle startup headroom.
Zero pod restarts: Dynamic resource resizing happens live inside the running container.
Flexible policy controls: Apply simple pod-level multiplier factors (e.g., 2x CPU during startup) or define granular, container-specific rules for complex multi-container pods.

Under the hood: Kubernetes In-place Pod Resize

Historically, changing a pod's resource requests or limits required deleting and recreating the pod. This disruptive process triggered container restarts, cache invalidation, and node rescheduling overhead.

To fix that, CPU startup boost builds on Kubernetes In-place Pod Resize (IPPR).

Tracked under KEP-1287, IPPR introduced dynamic, in-place resource mutation. Introduced as Alpha in Kubernetes 1.27, promoted to Beta in v1.33, and graduating to General Availability (GA) in v1.35, IPPR allows the Kubernetes control plane and kubelet to update container CPU and memory requests on running pods without restarting the container process.

GKE leverages IPPR within the VPA to apply startup CPU boosts at pod admission and smoothly step them down post-readiness.

How CPU startup boost works (pod lifecycle overview)

CPU startup boost operates across three distinct phases:

Admission phase: When you deploy a pod, the VPA admission webhook intercepts the creation request. It calculates the elevated CPU request based on your policy (e.g., 2x multiplier or +2 vCPUs) and injects the boosted CPU request along with tracking annotations into the pod spec.
Startup phase: The pod is scheduled and initialized with the boosted CPU allocation. Your application completes class loading, JIT compilation, or module parsing at top speed without experiencing CPU throttling.
Unboosting phase: As soon as the pod's readinessProbe passes (plus any configured durationSeconds cooldown delay), the VPA updater issues an in-place resize request. The CPU request steps back down to your baseline level while the container continues running uninterrupted.

Prerequisites and availability

CPU startup boost is available today in preview on GKE:

GKE version: Version 1.36.0-gke.4447000 or later on Standard and Autopilot clusters.
Cluster Modes: Enabled natively on GKE Autopilot (VPA is active by default). On GKE Standard, simply ensure Vertical Pod Autoscaling (VPA) is enabled.
Workload Support: Works with standard Kubernetes controllers, including Deployments and StatefulSets.

Getting started: Configuring CPU startup boost

Configuring CPU startup boost is as simple as adding a startupBoost section to your VerticalPodAutoscaler manifest.

Example 1: Pod-level boost with fixed steady-state (`updateMode: "Off"`)

If you want to use VPA purely for startup boost while keeping steady-state CPU requests locked to your manifest definitions, set updateMode to "Off":

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: java-app-startup-boost\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: java-app\r\n updatePolicy:\r\n updateMode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 2\r\n durationSeconds: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f457bd0>)])]>

In this example, GKE doubles the container's CPU request during launch and holds the boosted allocation for 10 seconds after readiness probes pass before scaling back to baseline.

Example 2: Combining startup boost with continuous VPA auto-scaling

If you want GKE to boost CPU during launch and continuously optimize steady-state resources post-startup, set updateMode to "InPlaceOrRecreate":

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: nodejs-app-vpa\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: nodejs-service\r\n updatePolicy:\r\n updateMode: "InPlaceOrRecreate"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 3\r\n durationSeconds: 15'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f4573d0>)])]>

Example 3: Granular container-level boost

For pods running sidecars (such as logging agents or service mesh proxies) that do not require extra CPU on boot, target specific app containers:

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: app-container-boost\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: API-gateway\r\n updatePolicy:\r\n updateMode: "Off"\r\n resourcePolicy:\r\n containerPolicies:\r\n - containerName: "web-app"\r\n mode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Quantity"\r\n quantity: "2"\r\n durationSeconds: 5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f455f90>)])]>

Verifying startup boost in your cluster

You can verify that GKE applied and downscaled the startup boost using kubectl:

1. Inspect pod annotations: Check for the vpaCpuStartupBoost tracking annotation:

code_block: <ListValue: [StructValue([('code', 'kubectl get pod <POD_NAME> -o yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f455290>)])]>

Look for annotations indicating the original baseline and boosted CPU requests.

2. Monitor in-place resize events: Confirm that GKE downscaled the CPU request back to baseline after readiness:

code_block: <ListValue: [StructValue([('code', 'kubectl get events --field-selector reason=InPlaceResizedByVPA'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f456450>)])]>

An event with reason=InPlaceResizedByVPA confirms successful in-place downscaling post-startup.

Best practices for production workloads

Pairing with Horizontal Pod Autoscaler (HPA): When using HPA alongside CPU startup boost, ensure a robust readinessProbe is defined and keep durationSeconds short (e.g., 0s–10s). This prevents HPA from falsely interpreting initialization CPU spikes as high steady-state load.
Handle traffic spikes with GKE capacity buffers API: By reducing the startup tax at scale, you can achieve higher workload density on fewer nodes to improve overall utilization. Consider adopting the GKE capacity buffers API to absorb sudden traffic surges with minimal operational overhead while maintaining strict SLOs.
GKE Autopilot resource ratios: On GKE Autopilot, remember that pods must maintain valid CPU-to-memory ratios. Ensure baseline memory allocations accommodate the boosted CPU ratio during startup.

Get started today

CPU startup boost gives GKE users the best of both worlds: lightning-fast cold starts for CPU-intensive workloads like Java, Node.js, and Python, paired with maximum resource efficiency and lower cloud costs.

Ready to accelerate your GKE workloads?

Explore the GKE CPU startup boost documentation.
Learn more about Vertical Pod Autoscaling on GKE.
Try CPU startup boost on your GKE Standard or Autopilot clusters running GKE 1.36.0-gke.4447000 or later!

What’s new with Google Cloud

Fri, 02 Oct 2026 16:00:00 +0000

Want to know the latest from Google Cloud? Find it here in one handy location. Check back regularly for our newest updates, announcements, resources, events, learning opportunities, and more.

Tip: Not sure where to find what you’re looking for on the Google Cloud blog? Start here: Google Cloud blog 101: Full list of topics, links, and resources.

aside_block: <ListValue: []>

Sept 28 - Oct 2

Claude Sonnet 5.5 is now available on Google Cloud. Built for focused coding and knowledge work, it delivers stronger performance for feature development, and creating presentation-ready documents, while offering more intelligence with a lower cost per task for most work at faster speed.

Deploy Sonnet 5.5 directly from Model Garden with Google Cloud’s enterprise security, scale, and governance built in. Try it now.
Mastering Storage Management with Storage Intelligence
In our new blog, explore practical strategies to modernize storage operations using Storage Intelligence Advisor and enhanced Batch Operations. See how customers like Shipt and Palo Alto Networks are using these features to manage their estates at scale. Today, Storage Intelligence is used by 25 of the top 50 GCS customers. 2 in 3 customers have Storage Intelligence enabled for over 90% of their storage footprint.

Explore best practices on our blog
Cut Gen AI costs by 70% with Apigee X dynamic routing
Generative AI deployments face a harsh cost-performance trade-off: static model selection either wastes budget or compromises quality. Discover how to build an Intelligent AI Gateway using Apigee X to dynamically evaluate prompt complexity in real-time. This new blueprint automatically routes simple queries to lightweight models (like Gemini 3.5 Flash Lite) and complex reasoning tasks to advanced models (like Gemini 3.7 Flash), achieving over 70% cost savings without sacrificing output quality.

Read the guide to optimize your Gen AI architecture
AI Agent Clinic launches new hands-on session on production agent evaluations
A new episode of the AI Agent Clinic is now available showing organizations how to move past manual "vibe checks" to build robust, production-grade agent evaluations. In this hands-on session, Google Cloud engineer Dani Zamora and Matthew Feroz (Merge) take DocsHound, an open-source LangGraph agent, and build an end-to-end eval pipeline in under an hour. Learn how to standardize multi-turn traces across any framework using OpenTelemetry and OpenInference, pair LLM judges with deterministic checkers, and catch silent quality regressions before shipping.

Watch here
Drive AI impact: Join Google's Agentic Data Cloud event on Nov 4
Every enterprise plans to adopt agentic AI within two years, but data bottlenecks hold them back—AI accesses just 45% of enterprise data today (MIT, 2026). Google's Agentic Data Cloud provides the trustworthy foundation and real-time context AI needs. Join our product leaders November 4th to explore the latest innovations across databases, analytics, business intelligence, and storage, and get direct answers in our executive Q&A with Google Data Cloud VP & GM Andi Gutmans.

Register today!

Sept 21 - Sept 25

Master MCP tool authorization and agent governance with Apigee
While the Model Context Protocol (MCP) solves interoperability for autonomous AI agents, chained actions like CRM edits or database queries quickly expose systems to unauthorized execution. Join our technical deep dive on Thursday, October 1, 2026, at 5:00 PM CEST featuring Christophe from Google Cloud. Learn how positioning Apigee between MCP clients and enterprise backends enables fine-grained authorization (FGA), complete audit trails, and policy evaluation via emerging standards like OpenID AuthZEN.

Language and accessibility note: This session will be hosted in French, but non-French speakers can follow along seamlessly by turning on Google Meet live translated captions to read in English, Spanish, German, Portuguese, or Italian.

Register for the October 1 Community TechTalk
Apigee Trace Viewer Tutorial: Capturing & Analyzing Proxy Traces
Streamlining API proxy debugging just got easier with a new tutorial by Apigee Customer Engineer Tyler Ayers. The guide covers end-to-end instructions for capturing debug traces in both Google Cloud Apigee X (or Hybrid) and the local Apigee Emulator, extracting trace JSON data via the web UI or automated REST APIs, and analyzing execution flows, variable mutations, and latency bottlenecks using the open source Apigee Trace Viewer.

Read the Apigee Trace Viewer guide today.
Automate Apigee proxy testing locally
Catching errors early saves time and money. A new tutorial by Apigee customer engineer Tyler Ayers shows how to use the Apigee Local Emulator for automated testing. Learn to run tests locally, integrate them into CI/CD pipelines, and deploy on Google Cloud Run for shared sandboxes. This approach provides instant feedback and zero cloud costs, helping teams speed up deployment cycles.

Read the tutorial
Scale your enterprise multi-agent systems with Apigee
Deploying multi-agent architectures in production introduces critical hurdles around security, operational control, and runtime expenses. Discover how Apigee API Hub provides a central discovery surface to eliminate agent sprawl across tools, Model Context Protocol (MCP) servers, and enterprise APIs. Learn how to turn existing backend services into secure MCP tools using Agent Gateway guardrails, while applying semantic caching and intelligent model routing to keep compounding token costs predictable.

Join Google Cloud in Chicago in Oct.15 for The AI Evolution. Reserve your seat for Chicago

Automate Apigee proxy testing with the Apigee Local Emulator
Waiting on remote deployments to validate API proxy logic slows down release cycles and increases infrastructure overhead. Join Nigel Walters on Thursday, October 8, 2026, at 5:00 PM CEST for a Community TechTalk on shift-left testing for Apigee. Discover how to use the Apigee Local Emulator and apigee-emulator-service to run sub-second assertion suites on local machines, automate CI/CD checks in GitHub Actions, and deploy ephemeral preview sandboxes on Google Cloud Run.

Register for the October 8 Community TechTalk
Now in Public Preview: AI-assisted EKS-to-GKE migrations with deterministic guardrails
Migrating complex Kubernetes estates from AWS EKS to GKE is traditionally high-friction and error-prone. Now in Public Preview, GKE Agentic Migration is an open-source agent plugin that replaces ad-hoc LLM prompting with an AI-assisted migration workflow protected by deterministic guardrails.

Running locally in your development harness, it indexes source IaC, maps cloud-specific primitives (such as Karpenter to Custom Compute Classes), and validates configurations offline—delivering reviewable pull requests and data-migration runbooks with zero live cluster mutations.

Learn more in the announcement blog and try the plugin on GitHub.
Claude Opus 5.5 is now available on Google Cloud. Built for everyday complex tasks, it delivers stronger agentic coding, research, and analysis while handling long-running work at a lower cost per token. Google Cloud continues to provide enterprise customers with broad model choice to build, deploy, and scale their AI agents securely.

Try it here.
Import Delta Lake tables with Dataflow Job Builder!
Migrating to borderless Lakehouse just got a lot easier. You can now import Delta Lake tables stored in Cloud Storage using Dataflow Job Builder, a no-code/low-code interface for authoring Dataflow pipelines. Because Dataflow is a fully managed service, you are spared the overhead of provisioning and managing virtual machines. For step-by-step guidance, check out the documentation here.

Sept 14 - Sept 18

Storage Intelligence Advisor for Google Cloud Storage is now GA
Google Cloud Storage customers can now manage cloud storage more effectively with Storage Intelligence Advisor, delivering curated metrics, automated anomaly detection, and actionable recommendations right out of the box, with zero setup required.

Advisor baselines activity across your projects and automatically detects four key anomalies: surges in operations, unexpected rises in cross-region egress, and spikes in errors. Each finding includes deep drill-down visibility into the resources driving the change, alongside prescriptive steps to remediate issues before they impact performance or cost.

Learn more to get started with Storage Intelligence Advisor.
Build private WebSockets from Apigee X to Cloud Run
Real-time AI agents and streaming architectures often require persistent, bidirectional connections. A new implementation guide by Apigee Customer Engineer Joel Gauci demonstrates how to establish private southbound connectivity between Apigee X and Cloud Run. Using Private Service Connect (PSC) and a Regional Internal Application Load Balancer, teams can enforce API governance and security policies at the edge while keeping backend services completely isolated from the public internet.

Explore the step-by-step guide and open-source code
Connecting Gemini Enterprise Agent Runtime to Apigee with Private Service Connect
Deploying autonomous AI agents often presents security, compliance, and cost challenges. A new reference guide details how to build an end-to-end, private architecture between Gemini Enterprise Agent Runtime and Apigee. This design helps protect internal backends and manage token quotas.

Read the full community guide and deploy the code
Discover what’s new and next in Apigee
As enterprise architectures adapt to generative AI and autonomous workflows, Apigee is expanding its proven platform capabilities to support modern AI gateway use cases alongside traditional API management. Join our session on Thursday, September 24, featuring Apigee Product Manager Geir Sjurseth. Get an inside look at recent product releases, explore architectural patterns for securing models and agents, and bring your questions for the live Q&A.

Register for the September 24 Apigee product update
Managed Service for Apache Kafka supports clusters with public Internet access!
With Managed Kafka public clusters, you can now produce and consume messages from clients outside your VPC—including your local machine, for faster, frictionless testing. Public clusters unlock use cases like IoT devices, retail storefronts, and telco network towers. Enable public access on new or existing clusters via the Google Cloud console, gcloud CLI, or REST API. Spin up your first public cluster, or reach out to kafka-hotline@google.com with questions.
Stream data directly into Bigtable using Bigtable subscriptions, now in Preview!
You can write Pub/Sub messages to a Bigtable table with zero ETL with Bigtable subscriptions. No pipelines, no code, delivered by the serverless, zero-ops experience you already know with Pub/Sub. Power your AI workloads, from model telemetry to real-time context engineering, without the overhead of managing complicated ETL pipelines. Built to be dependable, with native support for dead-letter topics. Try the feature today!

Sept 7 - Sept 10

Why Your Voice Agent Needs Session Auditing
Moving voice agents to production demands robust quality monitoring. This guide dives deep into the inner workings of the Agent Development Kit (ADK) responsible for audio session auditing. Learn how the ADK's save_live_blob feature intercepts, buffers, and stores raw audio chunks during active Gemini Live sessions. We explore building an automated post-processing pipeline to seamlessly stitch these fragments into cohesive, playable audio files. Discover how to leverage these vital audio audit trails to monitor real-world interactions, diagnose failures, and ensure enterprise-grade reliability. Read the full guide here.
AlloyDB Omni Red Hat RPM Orchestrator now Generally Available
AlloyDB Omni Red Hat RPM orchestrator is now Generally Available. The AlloyDB Omni Red Hat RPM orchestrator offers a new way to manage PostgreSQL-compatible workloads on bare metal or VM platforms, combining the high performance of AlloyDB, access to generative AI features and Gemini models to build AI agents and applications, and full automation. The orchestrator simplifies cluster provisioning and lifecycle management by allowing you to define reference architecture specifications, customizable by adjusting instance parameters, node configurations, and networking options — discover all details in full blog post.

Aug 31 - Sept 4

Automate VM guest software lifecycle with VM Extension Manager, now GA
Google Cloud VM Extension Manager is now generally available, eliminating the need for custom startup scripts to manage guest OS extensions across Compute Engine fleets. Define declarative, project-wide policies that enforce desired software states across all regions and zones. Benefit from continuous drift detection with automatic self-healing, multi-zone phased rollouts with automated rollbacks on failure, and centralized fleet health visibility integrated with Cloud Monitoring.

Explore VM Extension Manager documentation
Assess Apigee migrations without a target environment
Planning a migration to Apigee X or Hybrid? You can now assess your legacy Apigee Edge SaaS or OPDK environment earlier in your planning cycle. Using the updated --skip-target-validation flag in the Apigee Migration Assessment Tool, teams can generate a full inventory and establish scope baselines before target infrastructure or IAM credentials are provisioned.

Read the guide to learn more.
Claude Fable 5.1 is now available on Agent Platform. It brings performance improvements over Fable 5 across reasoning, full-lifecycle coding, multi-tool workflows, and knowledge work.

Anthropic also announced Enterprise Frontier Safeguards, a solution that gives customers the option to safely deploy Anthropic’s most capable models while storing their data in cloud infrastructure they control.

We continue to offer enterprise customers options across frontier models to build, deploy, and scale securely on Google Cloud.

Aug 24 - Aug 28

Grok 4.6 is now available in Preview on Gemini Enterprise. xAI's most capable model, built for coding, agentic tasks, and knowledge work, Grok 4.6 joins Grok 4.3 and Grok 4.20 in Model Garden and becomes the flagship of the Grok family. It supports reasoning, function calling, and structured output for multi-step agentic workflows, and accepts text and image input.

Get started today
Empowering autonomous agents with advanced security governance
AI agents offer incredible productivity gains, but granting them access to read emails, query databases, and trigger APIs introduces critical new security risks. In fact, 79% of tech leaders cite security and governance as their biggest challenge to scaling AI. Traditional tools are no longer enough to handle automated threats like prompt injection and dynamic permissions. Discover how forward-thinking enterprises are using secure-by-default design, agent identity governance, and human-in-the-loop controls to deploy agents with confidence.

Read more
Stateful processing is available in BigQuery continuous queries in Preview
Stateful operations significantly expand what’s possible with BigQuery continuous queries. This feature allows users to leverage functions like JOINs, aggregations, and windowing functions directly in their streaming queries. Now you can calculate metrics over time (for example, a 30-minute average) to power your downstream applications and AI agents with much richer, real-time signals.
Try out our feature here and share your feedback with bq-continuous-queries-feedback@google.com!
Synthetic data generator tool is available for Managed Service for Kafka
You’ve launched your first Kafka cluster. Now what? The next thing to do is to produce some data to the cluster, but that involves modifying a client application somewhere or spinning up a virtual machine. The synthetic data generator tool, now generally available, can start sending mock data to your cluster in 3 clicks, and will get data streaming into your cluster in less than two minutes. The perfect utility for those moments you just want to test your cluster and new features. Try our quickstart today!
Dataflow pipeline updates are faster & more flexible
Dataflow pipeline updates can now stop-and-replace pipelines, a major addition to the existing in-place-update feature. The new parallel pipeline option accelerates the migration between the old & new pipeline, resulting in reduced disruption to your business. You can also set a timeout on drains that prevents runaway costs for your pipeliness in the event of stuck processing. This feature is generally available. Try it here!

Aug 17 - Aug 21

Webinar: Agent Identity as the backbone for secure AI innovation
An AI agent with a stolen API key looks identical to a legitimate one. As autonomous agents scale across enterprise systems, static credentials and legacy IAM policies can no longer keep up with machine-speed execution. Join Shaun Liu, Product Manager at Google Cloud, on August 27 at 1 PM ET to explore Google Cloud’s vision for unifying agent, human, and nonhuman identity into a workload-centric platform using verifiable cryptographic identities (SPIFFE, ID-JAG, OAuth).

Register for the webinar now

Aug 10 - Aug 14

Diagnosing Apigee Hybrid Cassandra Read Latency for Peak Performance
Diagnose real-time Cassandra read latency and resolve API key verification bottlenecks in Apigee Hybrid with this step-by-step troubleshooting guide. Learn how to deploy a debugging client and query performance tables to maintain sub-millisecond response times.

Read the Apigee Hybrid Cassandra Troubleshooting Guide
Keep moving with agents! The All Things Agentic Hackathon is officially live.
We're challenging builders to build next-generation agents that take on the busy work and handle the heavy lifting in the background using Gemini 3.5 and Google Cloud. Compete for your share of $190,000 in prizes, cash, and Google Cloud credits! Submissions are open from August 3, 2026, to August 31, 2026.

Learn more and register. Sign up for GEAR to get exclusive updates and your badge. #AllThingsAgenticHackathon
Accelerate PostgreSQL migrations using Gemini in Database Migration Service
Enterprise database migrations often stall during the "last mile" of translating legacy stored procedures, triggers, and custom functions from Oracle or SQL Server. Database Migration Service (DMS) now provides AI-assisted code conversion powered by Gemini in Databases. By combining deterministic compiler rules for 1:1 syntax with Gemini contextual synthesis for complex procedural blocks, DMS converts legacy code into native PostgreSQL and AlloyDB with full schema awareness and side-by-side validation.

Read the full blog post to learn how to streamline your database code conversion.
Compute Flex CUDs now available for G2 and G4 GPU VMs
Compute Flexible Committed Use Discounts (Flex CUDs) are now available for G2 (NVIDIA L4) and G4 (NVIDIA RTX Pro 6000) VMs. You can now lock in predictable savings while retaining the flexibility to adapt across VM families, migrate between regions, and combine general-purpose compute, GKE, Cloud Run, and G2 & G4 GPU VMs under a single spend commitment. Flex CUDs for G-series VMs let you lock in savings today while preserving the agility to upgrade to latest hardware without disruption!

Explore VM instance pricing or learn more about Flex CUDs.
Rapid Bucket accelerates the training and checkpoint performance in PyTorch Ecosystem via GCSFS
With the release of GCSFS 2026.8.0, organisations can now unlock maximum ROI from their AI/ML infrastructure by eliminating data starvation on GPUs in PyTorch ecosystem when they are using Frameworks like Dask, Pandas, PyTorch , PyTorch Lightning, Hugging Face Datasets, Ray dataetc. By making adaptive concurrent prefetching the default, GCSFS dynamically predicts and background-fetches sequential read patterns—boosting single-file throughput by 5x, and scaling up to 21 GiB/s , saturating the NIC when paired with Rapid Bucket. Saturating the NIC translates to significantly improved accelerator goodput and reduced training wait times with zero integration friction. Training and checkpoint restore workflows benefit from intelligent memory management that automatically drains the buffer during random reads to completely avoid bandwidth or memory penalties.

Aug 3 - Aug 7

Navigate data sovereignty and AI innovation with hybrid cloud
For enterprises facing strict compliance rules, keeping sensitive data on-premises often means missing out on cutting-edge AI. Data from the 2026 State of AI Infrastructure report reveals that 52% of IT leaders are adopting hybrid cloud strategies to bridge this gap. Our latest blog post explores how Google Distributed Cloud (GDC) helps organizations deploy connected or air-gapped models to run advanced AI entirely within secure environments—mitigating geopolitical risks without sacrificing innovation. Read more.
SAP and Google Cloud Launch BDC Connect for BigQuery
For years, enterprises have struggled with the cost, risk, and complexity of moving mission-critical SAP data into advanced analytics platforms. The general availability of SAP Business Data Cloud (BDC) Connect for BigQuery marks a turning point. By introducing revolutionary zero-copy, bi-directional data sharing, this new capability seamlessly bridges SAP systems with Google Cloud's powerful data and AI ecosystem. Instead of wrestling with manual data duplication and lost business context, organizations can now eliminate silos, dramatically lower their analytics costs, and rapidly deploy trustworthy, agentic AI solutions grounded in real-time operational reality. Read the full announcement to learn how to transform your data strategy.
Google Cloud Cortex Framework version 7 is now generally available!
This release helps you modernize your data architecture for AI agent readiness, enabling you to quickly deploy, customize, and extend robust data products while simplifying orchestration and reducing infrastructure overhead. It provides data product accelerators for SAP-sourced data to build trusted, high-quality data products ready for advanced analytics and agentic use cases. The Framework integrates with Google Cloud products including BigQuery, Dataform, Knowledge Catalog, and Gemini Enterprise Agent Platform. Learn more in our announcement blog, technical documentation, or try a demo deployment today.
From API Management to AI Gateway with Apigee
Massive LLM adoption unlocked automation but exposed critical vulnerabilities, from unpredictable token costs to security risks like prompt injection. Without central management, organizations face accelerated technical debt. Learn how to transform Apigee into an enterprise AI Gateway to centralize governance. This architectural roadmap details how to utilize semantic cache to optimize token costs, implement prompt protection policies for security, and productize tools using the emerging MCP standard.

Read the full architectural roadmap on the Apigee Community Hub
Centrally govern enterprise AI traffic with Apigee AI Gateway
Manage, track, and secure model communication across your entire infrastructure from a single pane of glass. In a new video walkthrough, Principal Architect Tyler Ayers demonstrates how Apigee AI Gateway simplifies agentic governance. Learn how to transparently proxy model traffic, log real-time token counts, and apply runtime security quotas without impacting your developer workflow.

Watch the Apigee AI Gateway demo
Maximize Provisioned Throughput Utilization
Sudden traffic micro-spikes can exceed per-second quotas, triggering 429 errors or forcing overflow into shared resource pools. A new architectural guide demonstrates how to build a serverless "shock absorber" using Cloud Run and Google Cloud Tasks. By decoupling request ingestion from execution, this queue-based pattern flattens volatile traffic bursts and smoothly drips requests to Gemini at your exact quota rate, maximizing Provisioned Throughput utilization while eliminating job failures during peak usage. Read the step-by-step setup guide.
Eliminate security blindspots in agentic tool interactions
Unmonitored agentic tool calls via the Model Context Protocol (MCP) can introduce critical security risks to your enterprise architecture. Join our technical deep dive on Thursday, August 13, to discover how to position Apigee as a centralized security gateway. Featuring the new ParsePayload policy and payload operations groups in API Products, this session demonstrates how to enforce granular tool filtering, manage execution quotas, and scale secure agent ecosystems without impeding developer velocity.

Register for the August 13 Community TechTalk

Jul 27 - Jul 31

Data Cloud and Apigee CDMX: The AI Agent Evolution | August 12, 2026
Enterprise AI demands evolution beyond basic conversational assistants. To generate real value, AI models must connect with the organization's core systems and live data sources. Join us this August 12 at Google CDMX for the exclusive event AI Evolution: Powering Tomorrow's Enterprise. Learn how to design an agile and secure ecosystem by unifying the power of Gemini, Apigee, and data agent technologies through practical demonstrations led by Google Cloud engineers.

Secure your spot for the in-person session in Mexico City Register now!
Vast Edge, built on GCP, launches the first live recovery interface for cloud backups, enabling IT teams to inspect backup contents in real time. This transforms backups from a blind, log-based process into an interactive platform where teams can instantly search, preview, and validate the exact data available for restore.

This platform protects Google Workspace, NetSuite, Salesforce, Workday and many SaaS environments, providing complete visibility and enterprise-grade oversight.

Visit Vast Edge Backup & Disaster Recovery and get a free trial of their backup solutions on the GCP Marketplace for Google Workspace Backup, NetSuite Backup, Salesforce Backup, and Workday Backup.

Jul 20 - Jul 24

Claude Opus 5, Anthropic’s latest model, is now available on Agent Platform. It brings performance improvements over Opus 4.8 across coding, long-running agents, and knowledge work.The model is Zero Data Retention (ZDR) compatible. For safety, high-risk workflows — such as penetration testing or exploit generation — it will notify you and fall back to Opus 4.8.We’re excited to continue to offer enterprise customers options across frontier models to build, deploy, and scale AI securely. Try it here.
Apigee Northam Roadshow 2026 | The AI Agent Evolution: Powering Tomorrow's Enterprise
AI is evolving. As your organization deploys autonomous agents, the integration between APIs and models becomes critical. Join Google Cloud specialists for an exclusive day of deep-dive sessions and live demos. Discover how the unified power of Apigee and the Google Cloud Agent Platform allows you to build, govern, and scale high-performance AI agents with complete control. Call to Action: Register for Sunnyvale | Register for NYC | Register for Chicago
Deploy an Apigee Proxy for MCP Registry Discovery
Learn how to deploy an Apigee X proxy to format Apigee API Hub data into the Model Context Protocol (MCP) Registry format. This tutorial by Tyler Ayers guides developers through cloning the sample repository, deploying using the Apigee Feature Templater (aft), and testing the endpoint to make API data easily discoverable by coding agents.

Read the full community tutorial to get started.
Simplify AI Infrastructure: Getting Started with Apigee AI Gateway
Managing a complex AI landscape with multiple backend environments can present significant operational and governance challenges. A new tutorial walks you through how to build a unified API proxy using Apigee AI Gateway. By establishing a single, secure entry point for all model traffic, teams gain access to real-time analytics, comprehensive tracing, and financial operations auditing—completely seamlessly, and with absolutely no modifications required to client environments or user configurations.

Read the step-by-step setup guide
Your AI agents are ready. Is your data?
The biggest bottleneck to scaling AI isn't the models—it's giving them access to business context. As enterprises move to proactive systems of action, legacy infrastructure often buckles under the nonlinear speed of AI agents. Google Cloud’s new Agentic Data Cloud, built on AI-native infrastructure, solves this by unifying data, AI models, and operational databases. Discover how a borderless Lakehouse and active Knowledge Catalog can empower your AI agents with trusted, real-time context without unnecessary engineering overhead. Read more.
Secure and govern your AI at Apigee AI Horizon in London
Moving AI from basic prompts to complex agentic workflows requires trust and control. Join us on Tuesday, 1st September 2026 at Google London for our 5th edition of Apigee AI Horizon. Discover how Google Cloud product leaders and architects are using Apigee and Model Armor to secure LLM APIs, implement policy controls, and manage token consumption. Do not miss this one—register soon!

Secure your spot for AI Horizon London

Jul 13 - Jul 17

Resource-Based CUD Sharing is Now Enabled by Default
Starting June 16, 2026, the default setting for Google Cloud Resource-based Committed Use Discount (CUD) sharing will change from disabled to enabled for new billing accounts and eligible existing accounts without active CUDs. This update automatically maximizes your savings by pooling underutilized discounts across your resources.

You retain full control and can adjust your CUD sharing preferences at any time by changing your CUD scope configuration. For instructions, see Enable CUD sharing or Disable CUD sharing.
Webinar for India: Google Cloud for EdTech: Optimizing Traffic and Token Governance at Scale
API traffic surges and AI model integration are reshaping the EdTech landscape. Join Satyam Maloo for the webinar Google Cloud for EdTech: Optimizing Traffic and Token Governance at Scale on July 23, 2026. Learn to implement advanced rate limiting, gain granular token visibility, and leverage real-time analytics to govern your platform effectively. Whether you’re scaling for peak academic seasons or integrating complex AI workflows, this session provides the infrastructure blueprint you need.

Register Now
Scaling AI Agents: Treat prompts like software artifacts
As AI agents move into production, monolithic system prompts often result in configuration drift, merge conflicts, and silent runtime failures. The solution is adopting a Prompts-as-Code architecture. By breaking prompts into modular skill files and using a build-time transpiler, engineering teams can introduce dependency resolution, static validation, and CI/CD rigor to their agent's control plane. Stop manually editing massive text files and start building deterministic, reliable agent infrastructure.

Read more here.

Jul 6 - Jul 10

Webinar: Introducing Google Cloud NGFW Enterprise advanced malware protection - powered by Palo Alto Networks
Discover the new Cloud NGFW advanced malware sandbox, arriving in preview later this year. Powered by Palo Alto Networks Advanced Wildfire, it leverages data from 70,000+ customers to help defeat advanced malware. Join us on July 16 at 11 AM EDT to learn how to build a resilient, zero-trust cloud infrastructure that protects your apps and data, wherever they reside.

Register for the webinar now
Safely run AI-generated code in Cloud Run sandboxes
Cloud Run sandboxes, now in public preview, are lightweight, isolated execution boundaries that you can spawn near-instantly within your existing Cloud Run service instances.

Whether you need to let an LLM run a dynamically generated Python script to calculate business margins or spin up a headless browser to perform web research, Cloud Run sandboxes give you a secure, isolated sandbox to run these tasks without leaving your serverless environment.

Read the blog to learn more and get started today.
Australia API Horizon: Scaling Enterprise Governed AI Agents
The transition from AI chatbots to autonomous agents is the most critical integration point for your business. Join Google Cloud at our upcoming events to explore exclusive deep-dive sessions on architecting for the agentic era.

Discover how to use Apigee as an intelligent AI Gateway to govern, secure, and scale high-performance architectures. You will learn to seamlessly build AI tools from your existing APIs and maintain control over your entire ecosystem.

Join us in your preferred city:
Build highly available, multi-region services on Cloud Run
Maintaining uptime for business-critical applications just got a lot easier on Cloud Run. Service health, now Generally Available, automates cross-region failover by leveraging readiness probes for instance-level health checks with a simple, two-click setup. You can configure service health with global external Application Load Balancers for public-facing applications or cross-region internal Application Load Balancers for private networking traffic.

Learn how to configure service health for Cloud Run.
Report: 83% of organizations need infrastructure upgrades for agentic AI
The shift from conversational bots to autonomous agents is breaking legacy systems. Our new State of AI Infrastructure report details how engineering leaders are adapting to these massive new workloads. To eliminate inference bottlenecks, control hidden scaling costs, and manage agent sprawl, the industry is rapidly moving toward fluid compute, centralized governance, and unified, co-designed architectures.

Explore our key infrastructure insights
Stop tinkering, start scaling: the industrialized AI Playbook
Did you know that only 5% of custom AI investments actually return measurable business value? The problem isn’t the technology—it’s how organizations are wired to run it.

In this compelling read, Google Cloud Consulting breaks down the operational blueprint that bridges the stark gap between "cool tech experiments" and real, P&L-impacting enterprise ROI.

Read the full article on Medium
AI Agent Clinic: Slashing App Latency by 80%
Prototyping an AI agent is easy, but scaling for live traffic presents unique challenges. In the latest AI Agent Clinic, our technical experts partner with a developer to optimize PlaybackIQ, a live football analysis agent. This session demonstrates how to use OpenTelemetry to trace bottlenecks in the Gemini Enterprise Agent Platform and deploy to Cloud Run for high-concurrency scaling, achieving an 80% reduction in response time. Learn production-grade debugging strategies to optimize your own LLM applications.

Watch the 60-minute teardown

Jun 29 - Jul 3

Claude Sonnet 5, Anthropic’s latest model, is now available on Agent Platform.
This addition serves as a drop-in replacement for Sonnet 4.6, giving organizations expanded choice for task completion across enterprise workflows. It features enhanced reasoning, cleaner code generation, and computer use capabilities for desktop and browser workflows.

By continuing to rapidly bring frontier models to our platform, Google Cloud offers an uncompromised choice of the industry's best technology to build, test, and scale enterprise-grade AI.

Get started today.
Automate your AI governance with Apigee and YAML
Manual API gateway configurations can quickly slow down your AI engineering velocity. Join the Apigee community on Thursday, July 16, to discover an automated, declarative blueprint for model garden management. Learn how a simple, repeatable YAML pattern lets your AI practitioners instantly spin up secure, policy-backed enterprise configurations without friction. Bring your questions and connect during our live Q&A session.

Register for the July 16 Community TechTalk
Build next-generation AI portals for autonomous agents
Standard developer portals were designed for human developers to subscribe to static APIs. Today, autonomous agents, LLM toolkits, and dynamic runtimes demand a central nervous system for governance. Join our technical deep dive on Thursday, July 23, to explore Apigee's new AI Portals solution. You will see exactly how to deploy full-service, MCP powered hubs to safely manage enterprise self-service for models, tools, and agents.

Register for the July 23 Community TechTalk
Protect your infrastructure from advanced cyberattacks at the API layer (Presented in Portuguese)
In an era of increasingly sophisticated threats, relying solely on traditional firewalls leaves critical data gaps. Join our technical community TechTalk on Thursday, July 30—conducted in Portuguese—to learn how to proactively mitigate risks directly at the gateway layer. This session demonstrates how to configure and govern essential Apigee security policies to build a robust line of defense, ensuring maximum availability and complete integrity for your enterprise microservices.

Register for the July 30 Portuguese Community TechTalk

Jun 22 - Jun 26

Accelerate TPU model loading while saving RAM on GKE.
Large model cold starts often stall scaling and leave high-value TPUs idle. The open-source Run:ai Model Streamer now natively supports TPUs with Google Cloud Storage in TPU vLLM 0.18.0. This integration accelerates inference pipelines on GKE by streaming tensors directly into CPU memory, bypassing local disk bottlenecks and the "double-buffering" trap. In benchmarks, loading a 480B parameter model was over 2x faster while cutting peak host memory usage by half. Read the full guide and get started today.
Stop Training Blind: Scaling AI with the New OpenTelemetry-Based TPU AI Telemetry Collector Agent
Google Cloud’s new AI Telemetry Collector agent standardizes TPU monitoring using OpenTelemetry. It optimizes enterprise ML workloads by identifying silent failures and providing zero-cost operational metrics without draining host CPU cycles. The agent seamlessly routes telemetry to Google Cloud Monitoring or Prometheus and custom Grafana setups. Pre-installed on Google-optimized Ubuntu images or available via Docker, it tracks memory, network latency, and core utilization to maximize multi-node training efficiency.

You can read more of this capability by clicking this link.

Jun 15 - Jun 19

Join us for a deep dive into agentic AI control with AppyThings
Your integrations aren’t failing—they are evolving. When users interact with AI agents, they no longer arrive directly at your site, resulting in experiences stripped of your context, expertise, and intended experience. Join us on Thursday, June 25, for a community tech talk in partnership with AppyThings to learn how to solve this new gateway challenge. We will explore how MTN laid an integration foundation with the Model Context Protocol (MCP) to deliver accurate, consistent experiences. Our technical experts will demonstrate how to leverage Apigee as a centralized tools management solution to govern agent access.

Register for the session
Optimize Spot VM Deployments with Capacity Advisor for Spot, Now in Public Preview
Google Compute Engine has launched Capacity Advisor for Spot to Public Preview, now open to all customers. This tool turns Spot capacity discovery into a data-driven process by providing real-time deployment recommendations to maximize obtainability and minimize preemption risks. Query the Capacity Advisor API for obtainability and minimum estimated uptimes, or use the new Console UI featuring a global availability map, spot price lookups, and historical preemption rate trends to visually find the most cost-efficient compute capacity.

Get started today to start optimizing your Spot VM deployments!
Build a multi-tenant agentic AI system
When scaling generative AI across different business units, your teams need specialized AI agents with unique operational rules and tools. Our new reference architecture helps you build a centralized multi-tenant platform to prevent fragmented silos, eliminate data exposure risks, and maintain unified compliance. Read the guide to design and deploy a multi-tenant agentic AI system in Google Cloud.
How to Configure Gemini Enterprise to Connect to a Custom MCP Server
The Gemini Enterprise MCP Connector was a big announcement at Google Cloud Next because it introduces the ability to connect Gemini Enterprise to MCP servers. This blog post provides a step-by-step guide on how to configure your first Custom MCP Server connector using the Google Maps Ground Lite MCP server as an example. Once you understand this flow, you can configure multiple MCP servers with Gemini Enterprise to bring all the context you need.

Jun 8 - Jun 12

Simplify Multi-Cloud Planning with Cloud Location Finder, now Generally Available
Cloud Location Finder provides up-to-date data on public regions, zones, and Google Distributed Cloud Connected locations across Google Cloud, AWS, Azure, and OCI. You can now programmatically discover locations based on provider, proximity, territory, and carbon footprint to optimize your global infrastructure strategy for performance, compliance, and sustainability.

Get started for free today

Jun 1 - Jun 5

Modeling the physical world with BigQuery Graph
Managing complex supply chains requires more than just spreadsheets; it requires a digital replica of the physical world. In this post, Guru Rangavittal and Candice Chen explore how BigQuery Graph enables organizations to build a digital twin by turning physical assets into an interconnected map of nodes and edges. By moving beyond traditional relational databases, businesses gain real-time clarity into operations—from executing surgical ingredient recalls to analyzing weather-driven logistics risks. Discover how BigQuery Graph transforms reactive firefighting into proactive, precision modeling, allowing you to see critical connections in seconds and future-proof your supply chain.
Apigee for AI: Govern LLMs and MCP Servers (Presented in Spanish)
Learn how to securely transition your AI initiatives from experimental prototypes to enterprise-ready deployments. Join Luis Cuellar on June 18 for a technical deep dive (presented in Spanish) exploring Apigee’s latest AI gateway capabilities. Discover how to centralize governance over Model Context Protocol (MCP) servers, protect Large Language Models (LLMs) with robust API gateway security policies, and manage token-based quotas.

Register for the June 18 Spanish Community TechTalk

May 25 - May 29

Anthropic’s Claude Opus 4.8 is now available on Gemini Enterprise Agent Platform. As we continue to expand our platform's model offerings, this addition gives organizations more options for handling complex, multi-stage enterprise workflows. Claude Opus 4.8 brings strong capabilities in agentic coding, allowing developers to manage extensive refactors and tracking dependencies over extended sessions.
API Horizon Munich July 6, 2026: Orchestrating the Next Era of AI and APIs
Master the orchestration of next-gen AI and digital ecosystems. Join Google Cloud experts and DACH tech leaders on July 6 for an exclusive look at the Apigee roadmap, Agent Management, and Model Context Protocol (MCP). Gain real-world insights and connect with the regional integration community.

Register now
Securing AI Agents: The Extended Agent Gateway Pattern
Learn how to prevent autonomous AI agents from invoking unauthorized APIs. Join Apigee Specialist Joel Gauci on June 4 for a technical deep dive into the Extended Agent Gateway pattern. This session covers enforcing Fine-Grained Authorization (FGA), implementing secure token exchange, and establishing Model Context Protocol (MCP) governance at the API gateway layer to protect enterprise backend services.

Register for the June 4 Community TechTalk
API-to-Agent Security: Exposing REST APIs to Gemini Enterprise via MCP
Connect Gemini Enterprise agents to core data without creating security hazards. Join Google Cloud Specialist Nigel Walters on June 11 to learn how to instantly transform legacy REST APIs into secure Model Context Protocol (MCP) servers. We’ll cover how to safely register tools with Gemini while enforcing gateway-level guardrails like rate limiting and access control policies.

Register for the June 11 Community TechTalk

May 18 - May 22

Chinese Webinar | June 4: AI Command and Control
As AI agents move from experimental pilots to core enterprise functions, governance has become a critical next step. Join Google Cloud on June 4th at 10:00 AM (Beijing Time) to learn how to build a secure AI management layer architecture. We'll explore how to develop governed MCP (Model Context Protocol) endpoints, manage tool access to enterprise data, and leverage robust audit logs to operationalize AI. This session also includes a practical demonstration of these governance frameworks on Google Cloud.

Register here
GCP Announces New Features to Benchmark and Optimize LLMs for On-Device Use Cases
Deploying fine-tuned LLMs from GCP to edge devices like smartphones is complex due to fragmented hardware. Google AI Edge Portal bridges this gap, giving GCP developers the ability to test AI performance on 120+ Android devices, representing the full diversity of high, medium, and low tier smartphones on the market today. This week at I/O, we announced brand new capabilities to benchmark and debug LLM performance across these devices. Sign-up to utilize these new features in private preview today.

May 11 - May 15

Build Your AI & MCP Control Tower for Universal Governance
Master the future of agentic security with Apigee. Join our Community TechTalk on May 21 to discover how Apigee serves as a central "Control Tower" for the Model Context Protocol (MCP). We will explore how new JSON-RPC tool authorization enables fine-grained access policies across your organization, ensuring secure and scalable AI deployments. Whether managing internal tools or external users, learn to govern your agentic ecosystem with absolute precision. This session is designed for global coverage across EMEA and AMER regions.

Register for the May 21 Community TechTalk

Apr 27 - May 1

Master Your Launch: The Apigee Production Go-Live Checklist
Ensure a secure launch with the Apigee production guide. Join Nicola Cardace on May 28 to explore security guardrails, including IAM roles, mTLS configurations, and encrypted KVM migrations. Scheduled at 11 AM EDT / 5 PM CEST to support EMEA and AMER teams, this TechTalk provides the technical roadmap you need to flip the switch with absolute confidence.

Register for the May 28 Community TechTalk
Transforming APIs into Governed Agentic Tools on the Google Cloud Agentic Platform
Turn your APIs into secure, governed agentic tools on the Google Cloud Agentic Platform. Join Specialist Christophe Lalevée on May 7 for a technical deep dive into AI productization. Scheduled at 5 PM CEST / 11 AM EDT to maximize coverage for developers across EMEA and AMER, this session explores the integration and governance frameworks required to scale enterprise-ready AI with confidence.

Register for the May 7 Community TechTalk
Fractional G4 VMs are Generaly Available, providing a highly efficient and cost-effective entry point for AI and graphics workloads. These new configurations, using NVIDIA virtual GPU (vGPU) technology, allow you to leverage the power of the NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs in flexible, smaller increments, so you can right-size your infrastructure to match the specific demands of your applications. By providing more granular access to advanced hardware, fractional G4 VMs let you optimize resource allocation and reduce overhead without sacrificing performance. You can now select from additional GPU slice sizes for your specific needs:
- 1/2 GPU: Ideal for more intensive tasks such as LLM inference, robotics sensor simulation, and high-fidelity 3D rendering.
- 1/4 GPU: Optimized for mainstream workloads, including mid-range creative design, video transcoding, and real-time data visualization.
- 1/8 GPU: Great for lightweight applications such as remote desktops, productivity tools, and entry-level streaming services.
Transitioning AI from a sandbox prototype to an enterprise-grade system is a major hurdle. A monolithic script won't suffice for widespread deployment. To achieve true scale and reliability with Gemini, organizations must adopt service-oriented micro-agent architectures, establish Zero-Trust security, and implement rigorous EvalOps. Master the "Agentic Maturity Ladder" to ensure your AI & Agentic solutions are robust, secure, and ready for the real world.

Watch the deep dive and read the developer blog to learn more.
ML Development in VS Code with Google Cloud Power: Workbench Extension Now Available
Data scientists and developers can now combine the local productivity of VS Code with the scalable infrastructure of Google Cloud. The new Google Cloud Workbench Notebooks extension allows you to connect to and run notebooks on managed cloud environments directly within your local IDE. This integration streamlines the ML lifecycle by eliminating context switching and providing high-performance compute for complex workloads in a familiar interface. As part of our commitment to the developer ecosystem, the extension is fully open-sourced to support community-driven innovation.
- Install from Marketplace: GoogleCloudTools.workbench-notebooks
- Contribute on GitHub: colab-enterprise-vscode

Apr 20 - Apr 24

Announcing the 2026 Google Cloud Partners of the Year
Google Cloud is honored to celebrate the winners of the 2026 Partner of the Year awards! These awards recognize an exceptional group of partners across AI, Security, Infrastructure, and more, who have demonstrated a commitment to customer success. From global system integrators to specialized startups, these winners are leveraging the power of Google Cloud to solve complex challenges and drive digital transformation worldwide. Join us in congratulating these organizations for their innovation, collaboration, and impactful results over the past year.

See the 2026 Partner Award winners

Apr 13 - Apr 17

We're excited to announce the Public Preview of Datastream’s metadata integration with Knowledge Catalog. This is the first step in our vision to provide a centralized, "single pane of glass" for all Datastream assets. The enhancement automatically synchronizes Streams, Connection Profiles, and Private Connections, eliminating data silos. It enhances discoverability, allowing you to search for Datastream assets using the same interface as BigQuery tables. Centralized governance is also provided, making your real-time data estate more transparent and easier to manage.
Upgrading Apigee OPDK to 4.53 with OS Modernization
Modernize your infrastructure using Google’s official, sequential upgrade path. Our Technical expert, Rakesh Talanki outlines how to upgrade Apigee OPDK to v4.53 while migrating to a supported OS (RHEL 8.x/9.x). This guide covers the "build-out" methodology, including multi-data center syncing, to ensure a stable, zero-downtime transition

Read the guide
Cloud Run Worker Pools and CREMA: Powering Serverless AI at Scale
Google Cloud has announced the General Availability of Cloud Run worker pools, a new resource type designed specifically for pull-based, non-HTTP workloads. Unlike traditional Cloud Run services that scale based on request traffic, worker pools provide an "always-on" environment for background tasks like processing message queues or running large-scale AI inference. To support this, Google Cloud also open-sourced the Cloud Run External Metrics Autoscaler (CREMA). Built on KEDA, CREMA enables queue-aware autoscaling for worker pools, allowing them to dynamically scale based on external signals like Pub/Sub backlog or Kafka lag.
Apigee Model Context Protocol (MCP) now Generally Available
Expose enterprise APIs as MCP tools for agentic AI applications with the General Availability of MCP in Apigee. This update allows developers to transform APIs into AI-ready tools using OpenAPI Specifications, removing the need for local MCP servers or additional infrastructure. With managed endpoints and semantic search in API hub, you can now provide AI agents with secure, governed access to enterprise data at scale.

Explore the MCP overview

Apr 6 - Apr 10

Community TechTalk: Powering Retail Agents with ADK, UCP & Apigee X
Move beyond basic chatbots to secure, transactional AI experiences. Join our Community TechTalk on April 16 to learn how Apigee X and Gemini build a "Trust Layer" for AI shopping assistants using UCP standards. We’ll demonstrate how to block prompt injections with Model Armor and implement cost governance via token limits to secure the path from discovery to purchase.

Register for the TechTalk
Implement multimodal capabilities in your AI agents
Explore three new reference architectures for building sophisticated multi-agent AI systems that can process and analyze multimodal data. To analyze disparate multimodal data and produce a high-confidence classification, see Classify multimodal data. To create a fluid conversational AI that processes audio and video streams in real time, see Enable live bidirectional multimodal streaming. To consolidate fragmented multimodal data into a searchable knowledge graph, see Multimodal GraphRAG resource orchestration.
Automate SecOps workflows with an agentic AI system
To accelerate incident response and reduce manual toil for your security team, you need a system that can automate remediation playbooks. Our new reference architecture helps you build an AI agent that orchestrates complex triage and investigation workflows across disparate security tools, such as SIEM, CSPM, and EDR, from a single interface. See the full guide to orchestrate security operations workflows.

Mar 30 - Apr 3

ASEAN Webinar | April 30: Mastering Agentic Governance at Scale with GCP
As AI agents move from experimental pilots to core enterprise functions, governance is the critical next step. Join Google Cloud experts Shilpi Puri & Wely Lau for a webinar on April 30th at 11:00 AM SGT to learn how to architect a secure AI Management layer. We’ll explore developing governed MCP endpoints, managing tool access to enterprise data, and operationalizing AI with robust audit logs. The session includes a live demo of these frameworks in action on Google Cloud.

RSVP here.

Mar 23 - Mar 27

Turn your API sprawl into an agent-ready catalog
As organizations scale, APIs often become scattered across multiple gateways, creating "blind spots" that hinder AI adoption. To solve this, we’ve introduced two new capabilities for Apigee API hub: a new integration with API Gateway to automatically centralize API metadata into a single control plane, and a specification boost add-on (now in public preview). This add-on uses AI to enhance your API documentation with the precise examples and error codes that AI agents need to function reliably.

Read the full blog post to get started.
Webinar | April 16: AI Command & Control
As AI agents move from experimental pilots to core enterprise functions, governance is the critical next step. Join Google Cloud expert Satyam Maloo for a webinar on April 16th at 11:00 AM IST to learn how to architect a secure AI Management layer. We’ll explore developing governed MCP endpoints, managing tool access to enterprise data, and operationalizing AI with robust audit logs. The session includes a live demo of these frameworks in action on Google Cloud.

RSVP here.
Modernizing and Decoupling Event Ingestion with Apigee
In modern cloud-native architectures, decoupling producers from consumers is critical for building resilient systems. While Google Cloud Pub/Sub provides a scalable backbone, exposing it directly to external clients can introduce security and management overhead. This new guide explores how to leverage Apigee as an intelligent HTTP ingestion point. Learn how to handle security, mediation, and traffic control before messages reach your internal bus using the PublishMessage policy or Pub/Sub API.

Read the full guide.

Mar 16 - Mar 20

Gemini-powered Assistant in BigQuery Studio Gets Context-Aware Upgrades
The Gemini-powered assistant in BigQuery Studio has been transformed into a fully context-aware analytics partner, supporting your entire data lifecycle. The new capabilities include intelligent resource discovery, which uses Dataplex Universal Catalog search to find resources across projects and deep dive into metadata using natural language. You can now automate tasks, such as scheduling production-grade queries directly through the chat interface, and instantly troubleshoot long-running or failed jobs with root cause analysis and cost control auditing.

Explore the full range of what the assistant can do.

Mar 9 - Mar 13

Want to use Gemini to develop code and don't know where to start?
This article includes a couple of examples of developing code with Gemini prompts; it identified changes that were needed to be made to get the code working. The article also refers to other examples that are available on github.

Mar 2 - Mar 6

Introducing Gemini 3.1 Flash-Lite, our fastest and most cost-efficient Gemini 3 series model. Built for high-volume developer workloads at scale, 3.1 Flash-Lite delivers high quality for its price and model tier. Gemini 3.1 Flash-Lite can tackle tasks at scale, like high-volume translation and content moderation, where cost is a priority. And it can also handle more complex workloads where more in-depth reasoning is needed, like generating user interfaces and dashboards, creating simulations or following instructions.

Starting today, 3.1 Flash-Lite is rolling out in preview to enterprises via Vertex AI and developers via the Gemini API in Google AI Studio.
TechTalk: Implementing Device Authorization Grant (RFC 8628) for Apigee
Learn how to authorize "headless" devices like Smart TVs or AI agents that lack keyboards and browsers. Join our Community TechTalk on March 19 (5PM CET / 12PM EDT) to go under the hood of Apigee X/Hybrid. We’ll cover the real-world mechanics of state management, polling, and human-in-the-loop security patterns for devices and autonomous agents.

Register for the TechTalk

Feb 23 - Feb 27

Pro-level image generation gets faster and more accessible with Nano Banana 2
Nano Banana 2 is our state-of-the-art image generation and editing model. It delivers Pro-level image generation and editing at the speed you expect from Flash — making the quality, reasoning, and world knowledge you loved about Nano Banana Pro more accessible. Learn more about the model here.

The Intelligent Path to Compliance: Transforming Regulatory QC with Google Cloud
Reducing "Refuse to File" (RTF) risks and submission cycle times is critical for life sciences leaders. Google Cloud’s Regulatory Submission Semantic QC Auditor leverages Gemini and RAG architecture to transform Quality Control from a manual burden into an active, intelligent workflow.

By automating semantic cross-referencing, narrative coherence checks, and dynamic guidance-based auditing, this solution ensures rigorous accuracy and auditability. Operating within a secure GxP-ready environment, it empowers teams to detect subtle inconsistencies and generate remediation plans without sacrificing data privacy.

Learn more.
Stop typing, start interacting! The Gemini Live Agent Challenge is here. Build immersive agents that can help you see, hear, and speak using Gemini and Google Cloud. Compete for your share of $80,000+ in prizes and a trip to Google Cloud Next '26!

Submissions are open from February 16, 2026 to March 16, 2026. Learn more and register at geminiliveagentchallenge.devpost.com

Feb 9 - Feb 13

Introducing Gemini 3.1 Pro on Google Cloud.
3.1 Pro is a noticeably smarter, more capable baseline for complex problem-solving. We’re shipping 3.1 Pro at scale, building upon our goal to help you transform your business for the agentic future. Learn more about the model’s capabilities here. Gemini 3.1 Pro is available starting today in preview in Vertex AI and Gemini Enterprise. Developers can access the model in preview via the Gemini API in Google AI Studio, Android Studio, Google Antigravity, and Gemini CLI.
Automate Storage Compatibility with GKE Dynamic Default Storage Classes
Managing storage across mixed-generation VM clusters in GKE just got easier. With the new Dynamic Default Storage Class, Google Kubernetes Engine automatically selects between Persistent Disk (PD) and Hyperdisk based on a node's specific hardware compatibility. This abstraction eliminates the need for complex scheduling rules and manual pairing, ensuring your volumes "just work" regardless of the underlying infrastructure. By defining both variants in a single class, you reduce operational overhead while maintaining peak performance and cost-efficiency across your entire cluster.

Explore automated disk type selection
Community TechTalk: AI-Powered Apigee Development with strofa.io
Join the Apigee community on February 26 for a deep dive into strofa.io. Guest speaker Denis Kalitviansky will demonstrate how this new AI-powered tool automates and orchestrates Apigee development, from local emulators to large-scale hybrid environments. Discover how to scale your API management and streamline team collaboration using the latest in AI-driven automation.

Register now to reserve your spot.

Jan 26 - Jan 30

Simplify API Governance with Native OpenAPI v3 Support
Eliminate integration debt and accelerate deployment velocity with the General Availability of OpenAPI v3 (OASv3) support for API Gateway and Cloud Endpoints. You no longer need to downgrade modern specifications to OASv2. Instead, you can now define API contracts and enforce critical policies—including telemetry, quotas, and security—using native Google-specific extensions directly within your OASv3 files. This update ensures your APIs are secure by design while remaining fully compatible with the modern developer ecosystem and Google Cloud’s AI services.

Get started with OpenAPI v3 on API Gateway and Cloud Endpoints.

Accelerate API Testing with the New Open Source API Tester
Start validating your APIs with API Tester, a simple, YAML-based Test Driven Development (TDD) framework. Designed for the Apigee community, this tool allows you to write human-readable tests, run them instantly via a web client or CLI, and perform deep unit testing on Apigee proxies. With native support for JSONPath assertions and Apigee shared flows, you can verify everything from payload data to internal variables like proxy.basepath without leaving your terminal.

Explore the API Tester guide and start testing your proxies today.
Secure Sensitive Data with Kubernetes Secrets in Apigee hybrid
Enhance security in Apigee hybrid by accessing Kubernetes Secrets directly within your API proxies. This hybrid-exclusive feature keeps sensitive credentials within your cluster boundary and prevents replication to the management plane. It supports strict separation of duties: operators manage secrets via kubectl, while developers reference them as secure flow variables—ideal for high-compliance and GitOps workflows.

Implement Kubernetes Secrets in your hybrid proxies.
See the Console in a Whole New Light: Dark Mode is Now Generally Available in Google Cloud
Elevate your cloud management workflow with Dark Mode, now generally available in the Google Cloud console. We have delivered a modern, cohesive, and accessible experience reimagined for maximum comfort and productivity—especially during extended working hours and low-light environments. Dark Mode can be enabled automatically based on your operating system's preference, or manually through the Settings -> Appearance menu.

Switch to Dark Mode today to enjoy a modern, comfortable, and productive environment!
Apigee X Networking: PSC or VPC Peering?
Deciding how to connect Apigee X? Watch this video to compare Private Service Connect and VPC Peering. We break down northbound and southbound routing, IP consumption, and how to reach targets on-prem or in the cloud. Learn to simplify your architecture and avoid common networking "gotchas" for a smoother deployment.

Watch the video.

Jan 19 - Jan 23

Bridge the Gap: Excel-to-API Conversion in Apigee Portals
Give your customers more ways to connect! This new article by Tyler Ayers explores how to extend the Apigee Integrated Portal to support direct Excel file uploads. By leveraging SheetJS and custom portal scripts, you can enable users to upload spreadsheets, preview data, and submit it directly to your APIs, all without writing a single line of integration code themselves. It’s a powerful way to simplify onboarding for those who aren't yet API-ready.

Learn how to build it.
Elevate your applications with Firestore’s new advanced query engine
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.

Learn more about Firestore pipeline operations.

How to implement long-term AI agent memory in AlloyDB and Memorystore for Valkey

Fri, 02 Oct 2026 07:00:00 +0000

Enterprise AI agents need persistent memory to execute complex, multi-day workflows and long-horizon tasks. In this blog, we examine how a 2-tier memory architecture using Memorystore for Valkey for short-term buffer memory and AlloyDB AI for long-term persistent memory can help reduce token spend by up to 70%, while maintaining critical data and enterprise guardrails.

Imagine building a personalized travel agent designed to help users book vacations. The user interacts with the agent many times over the course of several days, asking questions that range from brainstorming itineraries to actual purchase intent. To provide a truly seamless experience, this agent must remember flight preferences (e.g. “I only want non-stop flights”), hotel budgets, and dietary restrictions (e.g. “I need Gluten Free dining options”) established in previous sessions. More importantly, it has to hold onto these core facts even when the conversation gets deep into the weeds of sightseeing recommendations and itinerary planning. The agent must ensure that all the follow-up questions and exciting details about places to visit doesn’t cause it to forget or overwrite the user's fundamental requirements and decisions.

Stateful workflows inherently conflict with LLM’s stateless nature

AI agents are being used for multi-turn conversations and long-running workflows, but large language models (LLMs) remain stateless across sessions. When a user returns to an agent days later, the model starts with an empty context window. Unless your application is built to reconstruct past context using long-term agent memory, your users have to explain their goals and context all over again, resulting in a frustrating and fragmented experience.

With million-token context windows now the norm, a common shortcut to this problem is "context stuffing" - dumping everything you can fit into the prompt at every turn, from raw chat histories to tool execution logs. In fact, this was a common pattern in the early days of AI model usage. But this shortcut quickly creates issues at scale: token costs multiply with every message, response times can drag out past 30+ seconds for otherwise simple prompts, and the model starts suffering from "lost in the middle" degradation, overlooking critical instructions buried in mountains of prompt text.

Another common workaround is to use rolling summaries; asking an LLM to periodically compress older messages into a summary paragraph. While this trims prompt size, LLM-based summarization is inherently lossy. After a few rounds of compression, subtle but important details get filtered out as background noise. A few turns later, your agent quietly breaks the exact constraints you set earlier. Clearly, you need a more scalable approach for keeping a memory from previous conversations or multi-turn tasks, but without degrading the experience or creating new bottlenecks.

Implementing a 2-tier memory architecture

To build reliable, cost-effective enterprise agents that respect your guardrails and constraints, we recommend a 2-tier memory architecture:

Short-term session buffer: Caches active conversation turns in memory using a token-bounded sliding window, allowing the context window size to remain stable across multiple rounds, even across devices, while keeping the latest messages fresh. This tier requires sub-millisecond, high-throughput lookups on every turn, making Memorystore for Valkey well suited for maintaining active session state.
Long-term persistent memory: Stores important facts, user preferences, and episodic facts across sessions. This tier requires transactional integrity, data governance, and hybrid retrieval across relational data and vectors - capabilities provided natively by AlloyDB AI.

While it’s possible to store both long-term memory and active session buffers directly in a relational database, a two-tier architecture with an in-memory cache provides better performance and scalability. Active session buffers are highly ephemeral and require sub-millisecond, high-throughput updates on every single conversation turn. Handling these rapid-fire writes in an in-memory key-value cache prevents write amplification and table bloat in your relational database, which would otherwise require frequent row deletions and intensive vacuuming. This is analogous to adding a caching tier in front of your database to offload high-frequency lookups for hot rows. The division of labor keeps your primary database lean and responsive, allowing it to focus its resources on what it is designed for: transactional consistency, complex hybrid vector search, and long-term analytical query execution.

By pairing short-term caching in Memorystore for Valkey with native AlloyDB AI capabilities, you can run entity extraction, memory compaction, cross-session memory, and hybrid retrieval directly inside the database tier, keeping active prompts lean, fast, and cost-efficient.

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

Understanding the four memory types

To organize long-term agent state effectively, we further divide agent memory into four complementary types across the short-term and long-term storage tiers we described above:

Memory type	What it stores	Storage layer	Lifespan
Buffer (Short-term)	Recent raw conversation turns	Memorystore for Valkey	Active session
Summary memory	Compressed history of older turns, commonly referred to as “compaction”	Memorystore for Valkey	Multi-turn window
Episodic memory	Past actions, events, and tool outputs	AlloyDB for PostgreSQL (Hybrid retrieval with structured SQL + full-text search + vector)	Permanent
Entity & rule memory	User preferences, constraints, and vetoes	AlloyDB for PostgreSQL (Hybrid retrieval with structured SQL + full-text search + vector)	Permanent

By isolating short-term conversation context from structured long-term rules, your agent retrieves relevant context on demand without filling token windows with raw interaction logs.

The tiered memory architectural blueprint

The diagram below outlines the read and write paths connecting the application orchestration layer, the Memorystore for Valkey short-term buffer, and the AlloyDB AI long-term repository:

The system operates across two coordinated execution paths:

The read path: When a user asks a question, the application fetches the active sliding window from Memorystore for Valkey, runs in-database query normalization using ai.generate, and queries AlloyDB using ai.hybrid_search to retrieve scoped entity rules and relevant episodic facts.
The write path: After generating the response, the turn is immediately cached in Memorystore for Valkey. An asynchronous background queue worker extracts structured entities from the exchange and writes them directly into AlloyDB, where transactional auto-embeddings immediately compute and store vector representations in the database.

Business impact and ROI

In our benchmark testing across multi-turn development dialogues (45+ turns with heavy tool executions), separating short-term caching from long-term persistence delivered measurable cost and performance improvements compared to naive context stuffing:

Metric / dimension	Naive context stuffing	Tiered memory (AlloyDB + Valkey)	Net business impact
Active prompt size (turn 45)	747,033 tokens	83,262 tokens	88.9% smaller prompt
Turn 45 response latency	33.5 seconds	6.7 seconds	80.0% faster response
Per-turn response wait time	33.5 seconds	4.2s – 6.7s	36% to 80% reduction
Cumulative session tokens	17.9M tokens	4.09M tokens	72.0% token & cost savings
Rule & constraint recall	Degrades over turns	Does not degrade	ACID-preserved recall

Note: The metrics above reflect internal benchmark results from a simulated developer workload that mimics a real-world enterprise AI pair-programming assistant interacting with a developer over multiple sessions, projects, and context switches. Actual savings and latencies vary based on prompt structure, query frequency, and data volume.

These results demonstrate how tiered memory changes agent unit economics: instead of an escalating cost curve on every additional turn, prompt sizes remain bounded, reducing ongoing LLM API expenses while keeping response times fast.

Core AlloyDB AI technical advantages

AlloyDB AI reduces the operational overhead of implementing persistent agent memory by embedding core AI functions directly into the database engine:

Transactional in-database auto-embeddings (ai.initialize_embeddings): AlloyDB automatically generates vector embeddings for text columns using a native integration with Agent Platform (formerly Vertex AI), generating up to 3,000 embeddings per second. Using incremental_refresh_mode => 'transactional', AlloyDB keeps embeddings up to date as source data changes within the same transaction, removing the need for custom embedding pipelines, external schedulers, or complex retry logic.
In-database generative AI functions (ai.generate): AlloyDB allows you to execute foundation models, such as Gemini, directly from SQL queries. You can use this for in-database query decomposition - breaking compound user questions into single-aspect sub-queries and resolving relative time phrases (like "last session") into explicit identifiers - without making separate roundtrips from your application.
Native hybrid search with built-in Reciprocal Rank Fusion (ai.hybrid_search): AlloyDB provides a built-in SQL function that executes Reciprocal Rank Fusion (RRF) directly inside the engine. It combines vector cosine similarity (<=> over HNSW or ScaNN indexes) with PostgreSQL full-text search (using BM25, RUM, or GIN) in a single database call, blending semantic matching with exact keyword retrieval while supporting metadata filter pushdown (filter_condition) for improved performance and deterministic scope isolation.
Direct Agent Platform integration with IAM credentials: AlloyDB connects directly to Agent Platform foundation models over Google Cloud's private network using Google Cloud IAM service account roles and database authentication, avoiding the need to store, rotate, or pass API keys in application code.
Unified operational, vector, and governance engine: AlloyDB consolidates relational business data, vector embeddings, full-text indexes, and enterprise permissions in a single ACID-compliant PostgreSQL database, avoiding data drift and integration complexity across separate operational and vector databases.

Key implementation patterns

Below are the core database patterns used to configure the 2-tier memory architecture. For complete, runnable Python and SQL scripts, refer to the companion AlloyDB Agent Memory Codelab.

1. Setting up schema and auto-embeddings

In AlloyDB, install the necessary extensions and define the agent_entities table with structured metadata, a generated tsvector column for full-text search, and a vector embedding column.

code_block: <ListValue: [StructValue([('code', "-- 1. Enable AI extensions\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;\r\nCREATE EXTENSION IF NOT EXISTS vector CASCADE;\r\nCREATE EXTENSION IF NOT EXISTS rum CASCADE;\r\n\r\n-- 2. Create structured entity & preference table\r\nCREATE TABLE IF NOT EXISTS agent_entities (\r\n entity_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n user_id TEXT NOT NULL,\r\n entity_name TEXT NOT NULL,\r\n project_id TEXT DEFAULT 'global',\r\n session_id TEXT,\r\n scope TEXT NOT NULL DEFAULT 'session',\r\n summary TEXT NOT NULL,\r\n summary_embedding VECTOR(768),\r\n summary_tsv TSVECTOR GENERATED ALWAYS AS (\r\n to_tsvector('english', entity_name || ' ' || summary)\r\n ) STORED,\r\n updated_at TIMESTAMPTZ DEFAULT NOW(),\r\n UNIQUE (user_id, entity_name)\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f454c90>)])]>

Then, generate embeddings using ai.initialize_embeddings. Using transactional mode ensures the embeddings are kept up to date as source data changes.

code_block: <ListValue: [StructValue([('code', "-- Register transactional in-database auto-embedding\r\nCALL ai.initialize_embeddings(\r\n model_id => 'text-embedding-005',\r\n table_name => 'agent_entities',\r\n content_column => 'summary',\r\n embedding_column => 'summary_embedding',\r\n incremental_refresh_mode => 'transactional',\r\n batch_size => 10\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f454490>)])]>

Finally, create the HNSW vector index and the RUM full-text search index to ensure your hybrid searches are fast and efficient.

code_block: <ListValue: [StructValue([('code', '-- Create vector and full-text indexes\r\nCREATE INDEX IF NOT EXISTS agent_entities_embedding_idx\r\n ON agent_entities USING hnsw (summary_embedding vector_cosine_ops);\r\n\r\nCREATE INDEX IF NOT EXISTS agent_entities_tsv_idx\r\n ON agent_entities USING rum (summary_tsv rum_tsvector_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42ef32d10>)])]>

2. Querying long-term memory with native hybrid search

On the read path, retrieve relevant long-term entities using ai.hybrid_search. This native SQL function executes Reciprocal Rank Fusion (RRF) directly in AlloyDB, seamlessly reranking and combining vector similarity search and full-text keyword search results in a single database query:

code_block: <ListValue: [StructValue([('code', 'def retrieve_hybrid_entities(\r\n conn,\r\n user_id: str,\r\n project_id: str,\r\n query_text: str,\r\n query_vector_literal: str,\r\n limit: int = 3\r\n) -> dict[str, Any]:\r\n """Queries long-term memory using AlloyDB native hybrid_search (RRF)."""\r\n filter_cond = f"user_id = \'{user_id}\' AND (project_id = \'{project_id}\' OR scope = \'global\')"\r\n \r\n search_inputs = [\r\n json.dumps({\r\n "data_type": "vector",\r\n "weight": 0.4,\r\n "table_name": "agent_entities",\r\n "key_column": "entity_name",\r\n "vec_column": "summary_embedding",\r\n "distance_operator": "<=>",\r\n "limit": 10,\r\n "query_vector": query_vector_literal,\r\n "filter_condition": filter_cond\r\n }),\r\n json.dumps({\r\n "data_type": "text",\r\n "weight": 0.6,\r\n "table_name": "agent_entities",\r\n "key_column": "entity_name",\r\n "text_column": "summary_tsv",\r\n "limit": 10,\r\n "ranking_function": "ts_rank",\r\n "query_text_input": query_text,\r\n "filter_condition": filter_cond\r\n })\r\n ]\r\n\r\n query_sql = """\r\n SELECT e.entity_name, e.summary, e.project_id, e.scope, e.updated_at\r\n FROM ai.hybrid_search(\r\n search_inputs => %s::JSONB[],\r\n include_json_output => false\r\n ) h\r\n JOIN agent_entities e ON e.entity_name = h.id\r\n WHERE e.user_id = %s\r\n LIMIT %s;\r\n """'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42ef33e90>)])]>

3. In-database memory compaction with AI functions

To manage long-term storage growth without writing custom pruning scripts, you can run automated extraction and compaction queries directly in AlloyDB to identify the important parts which can benefit from being stored. This pattern uses a SQL common table expression (CTE) with ai.generate to consolidate older episodic entries into a high-density summary:

code_block: <ListValue: [StructValue([('code', "-- Consolidate older episodic logs into a permanent summary\r\nWITH old_events AS (\r\n SELECT document AS content\r\n FROM langchain_pg_embedding\r\n WHERE cmetadata->>'user_id' = 'user_dev_42'\r\n AND created_at < NOW() - INTERVAL '30 days'\r\n ORDER BY created_at ASC\r\n LIMIT 50\r\n),\r\nconsolidated AS (\r\n SELECT ai.generate(\r\n 'Summarize these historical events into a dense memory paragraph:\\n' || string_agg(content, E'\\n'),\r\n model_id => 'gemini-3.5-flash'\r\n ) AS summary_text\r\n FROM old_events\r\n)\r\nINSERT INTO agent_entities (user_id, entity_name, summary, updated_at)\r\nSELECT 'user_dev_42', 'longterm_session_summary', summary_text, NOW()\r\nFROM consolidated\r\nWHERE summary_text IS NOT NULL\r\nON CONFLICT (user_id, entity_name)\r\nDO UPDATE SET summary = EXCLUDED.summary, updated_at = NOW();"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42ef31cd0>)])]>

For example, a long interaction regarding the complexities of changing flights with kids can result in a summary of “I prefer non-stop flights”.

4. Connecting the 2-tier memory architecture to an ADK agent

With the core 2-tier memory architecture configured, you can now extend the default ADK Memory provider to use this 2-tier memory architecture as shown in the accompanying Codelab (e.g. ADKTieredMemoryProvider). To attach the long-term memory to an ADK agent, you simply provide it as a tool (e.g. longterm_memory_tool) like this:

code_block: <ListValue: [StructValue([('code', 'from adk_memory_provider import ADKTieredMemoryProvider\r\n\r\nagent = Agent(\r\n name="adk_memory_agent", model=GEMINI_MODEL, instruction="Initial instruction",\r\n tools=[long_term_memory_tool, run_command_tool],\r\n before_tool_callback=guardrail.create_before_tool_callback(USER_ID, "CloudRetail")\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42ef33590>)])]>

Enterprise governance and multi-tenant security

Running agent memory in enterprise production environments requires strict security boundaries and access controls. First of all, we need to maintain scope and multi-tenant isolation. By indexing user_id, project_id, and scope columns in agent_entities and enforcing PostgreSQL Row-Level Security (RLS), you can isolate memory stores across departments, teams, and individual users within the same database cluster. Parameterized Secure Views (PSV) offer another layer of deterministic application-level security, helping you protect against malicious prompts and overly-broad SQL queries.

In addition, we need to provide automated memory lifecycle management as shown in the implementation pattern above. Combining scheduled SQL compaction queries with time-based partition pruning helps maintain predictable database footprint and query latencies over time. See the accompanying Codelab for more details on this approach.

Summary and next steps

Decoupling active context windows from persistent storage is a practical approach to building production-ready AI agents. By pairing Memorystore for Valkey for sub-millisecond session caching with AlloyDB AI for transactional long-term storage, you can achieve substantial token cost savings and faster response times while maintaining strict business rules throughout long-horizon tasks and many-turn agentic experiences.

To get started:

Step through the complete hands-on tutorial in the companion AlloyDB Agent Memory Codelab to deploy the working 2-tier memory architecture.
Learn more about database-side machine learning features in the AlloyDB AI documentation.
Explore guides on generating auto vector embeddings and running hybrid vector search.

Enabling Cloud Storage end-to-end checksums for improved data integrity and durability

Thu, 01 Oct 2026 16:00:00 +0000

At Google Cloud, we know that you count on us to maintain the durability and integrity of your data at all times, both at rest and in transit. And now we’re making it easier for developers to take advantage of native data integrity features in Cloud Storage, by enabling end-to-end checksumming by default in all the Cloud Storage SDKs.

Like in any disk-based storage system, bits can flip anywhere in their journey, from the application all the way down to the disk. Cloud Storage has always let clients provide a checksum of the object data being uploaded, and receive a checksum of the data being downloaded. Also since its inception, Cloud Storage stores a checksum for every object in its metadata, regardless of how the object was uploaded into Cloud Storage.

But until recently, ensuring end-to-end data integrity required extra work on the part of developers to calculate and provide checksums to Cloud Storage. Cloud Storage always calculates the crc32 (32-bit cyclic redundancy check) of data it receives and ensures data stored on disk matches this checksum. When a client request includes the object’s checksum, Cloud Storage ensures that this checksum also matches. However, when an upload request doesn’t include a checksum, that upload is vulnerable to a bit flip while the data is in-flight, prior to the server-side checksum computation. Not all customers and clients enable client-side checksums by default, leaving data in this phase unprotected.

To address this gap, the latest version of all Cloud Storage SDKs now internally checksums data being uploaded and passes this checksum to Cloud Storage, if it’s not provided by the application. The SDKs also support verifying the object’s checksum when an object is being downloaded.

Finally, there are many use-cases where applications download select ranges of objects instead of the full object. When using Cloud Storage SDKs with our gRPC API to perform a range read, the SDKs take advantage of gRPC’s built-in end-to-end range checksum, using it to verify the data it receives.

We highly recommend updating to our latest SDK versions to take advantage of these important integrity features.

And now, let’s peek under the hood

Ensuring continuous “chain-of-custody” between the data and its associated checksum from your application down to the disk platter, with no gap where a bit flip could go unnoticed, is quite challenging. And it’s critical to get this right: at our current scale of hundreds of thousands of Cloud Storage frontends, bit flips aren’t theoretical and do happen from time to time.

For instance, consider this simple example: when Cloud Storage receives your data in its frontend, this data gets encrypted with per-object encryption keys. This involves a data copy: the plaintext data is passed through an encryptor into a new memory buffer containing ciphertext. Extremely rarely, a bit in the source or destination memory buffer flips during this process. However, at our scale, extremely rare things happen routinely.

In this situation, we maintain chain-of-custody by reversing the whole process: after encrypting the data (1), we calculate a checksum that protects the ciphertext. Then we decrypt the ciphertext (2), and if the resulting plaintext doesn’t match the original (3), we throw everything away and start over. This adds up to a lot of extra CPU time spent on encryption and checksumming, but it’s a necessary step to ensure data integrity.

Another challenge is how data gets broken up and aggregated as it passes through layers of our stack. As data gets uploaded to Cloud Storage, it gets split up into chunks, each of which has its own checksum. To manage data efficiently at scale, Cloud Storage groups thousands of chunks together into a storage unit we call a shard file. These gigabyte-sized files are how Cloud Storage ultimately delivers data to our cluster-level storage system, Colossus. Internally, Colossus uses Reed Solomon encodings to spread data across many disks and protect against the failures of individual disks, machines, and racks. This requires chopping up the shard file data into blocks, each of which is again protected by a checksum.

To maintain chain-of-custody of the data as it goes through all these transformations, we take advantage of some nifty properties of cyclic redundancy checks (CRCs), for example, concatenation. When you have two data buffers that each have their own CRC, you can cheaply compute the CRC of the two concatenated buffers without having to re-checksum the data. This comes in handy in many situations, such as when concatenating chunks together into shard files: Colossus can cheaply determine the CRC of the entire shard file from its constituent chunks and store that in its metadata.

Ultimately, the data lands on disks managed by our “D” file server (our network attached disks). D stores inline checksums for each range of data within a Colossus block. Whenever data is read from the disk, it is verified at several layers: The Colossus client verifies the data it reads against D’s inline checksums, and the Cloud Storage frontend reads data chunk-by-chunk, verifying each chunk against its checksum before sending it to the client. These chunk-level checksums are what enable our gRPC protocol to provide a checksum for a range read that can be verified by our SDKs, all without losing chain-of-custody.

Chain of Custody: Maintaining Data integrity across Data transformations

The above image shows the data integrity handoff across multiple layers under the hood of Google Cloud Storage. On reads, checksums are verified inline at multiple layers to prevent silent corruptions.

Client passes full object checksum to Cloud Storage Frontends.
Data is split into chunks and individual chunk level checksums are computed.
Shard level checksums are computed based on concatenated chunk level CRCs.
Shards are stored across disk blocks with another level of block level inline checksums.

Here on the Cloud Storage team, we remain dedicated to maintaining the highest standards of data integrity for our customers. By making end-to-end checksumming the default in our SDKs and maintaining chain-of-custody throughout our internal storage stack, data remains exactly as intended from the moment of upload to the final download. This continuous vigilance reflects our commitment to protecting your data at any scale. To take full advantage of these protections, we recommend updating to the latest version of our SDKs.

Accelerating analytics: PayPal’s journey with Managed Service for Apache Spark

Thu, 01 Oct 2026 16:00:00 +0000

In a data-driven world, PayPal’s ability to deliver timely and actionable insights is central to staying ahead. At PayPal, data powers everything from fraud detection to user experience enhancements. Data is also central to unleashing the potential of agentic solutions and experiences.

Over time, though, our analytics environment had become a complex ecosystem of various technologies and solutions assembled on-premise to address growing demands. While this approach supported our needs at the time, it began presenting new challenges to scale and maintain.

Navigating a challenging analytics landscape

Due to expedited growth and acquisitions, our data analytics platform gradually turned into an uneven landscape. Each new platform or integration addressed a specific business need, but together, they increased operational overhead and introduced performance blockages. Scalability became increasingly difficult, and time-to-insight slowed as processes grew more complex.

Complexity breeds stagnation

PayPal’s legacy data analytics platform was powerful—handling petabytes daily—but it was also increasingly rigid following rapid growth. Scaling up during peak retail events or global launches meant months of planning, slow manual provisioning of hardware, and too often, a compromise between speed and cost.

As PayPal continued to scale globally, we recognized the need for a streamlined, unified infrastructure to drive data efficiency and accelerate innovation.

The solution: Unified, cloud-native analytics

To overcome these obstacles, we migrated our analytics workloads from legacy Hadoop on-premise platforms to Google’s Managed Service for Apache Spark.

Key reasons for this choice included:

Rapid provisioning and elastic scaling: Managed Spark enabled us to deploy clusters in minutes and scale based on processing needs, eliminating lengthy setup and idle resource costs.
Unified infrastructure: Standardizing on Apache Spark created consistency across teams while leveraging Managed Service for Apache Spark and other managed services reduced operational complexity.
Seamless integration: Native hooks into Google Cloud Storage (GCS), BigQuery, and other Google Cloud services streamlined end-to-end data movement.

This move enabled PayPal to modernize our data processing capabilities, leveraging the flexibility, scalability, and reliability of cloud-native solutions. By consolidating previously disparate workflows and batch jobs that run on multiple platforms onto a single cloud-based analytics platform, we reduced data silos and built a unified data foundation that provides faster, richer insights.

This empowered developers and application teams to focus on delivering business value rather than being limited by infrastructure. Crucially, this shift was about more than re-platforming. We fostered a new culture of experimentation, enabling teams to test, tune, and deploy analytics workloads quickly in response to changing business needs.

The results: Faster insights, lower overhead

The impact of our modernized Google Cloud-based ecosystem leveraging Managed Spark has been profound:

Processing times for core analytics workloads improved by 25%, enabling near real-time insights for key business operations.
SLA adherence rose substantially by 30%, even during traffic surges such as seasonal sales events.
Operational costs dropped as we consolidated tooling and reduced manual maintenance.

But perhaps most importantly, our engineers now spend less time firefighting and more time innovating, rapidly prototyping new analytics capabilities that deliver value to customers and partners.

Transitioning from a fragmented environment to a cohesive, cloud-native platform has fundamentally strengthened PayPal’s analytics capabilities. As business needs evolve, investing in a scalable, unified data foundation ensures that we can deliver insights with speed, precision, and impact—driving continued innovation for customers worldwide. Our journey with Managed Service for Apache Spark is an important step in building that modern analytics foundation.

Learn more about how you can get started with Managed Service for Apache Spark and BigQuery to build your Agentic Data Cloud today.

Democratizing Managed Lustre with lower cost and frictionless development

Thu, 01 Oct 2026 13:00:00 +0000

This is the first of a two-part series exploring how Google Cloud is bringing the foundational values of a high-performance parallel filesystem–TB/s throughput, sub-ms latency at high client scale, and POSIX support–to a broader set of use cases and users.

Historically, due to the cost and special purpose nature of parallel filesystems, colder data had to be stored outside of the filesystem and AI developers have had to maintain separate, slower environments for writing code, compiling libraries, and managing repositories. This fragmentation increases the toil of manual data staging, dataset copying, and managing disjointed namespaces.

Google Cloud Managed Lustre is solving these problems through our 6 cents/GB*month Dynamic Tier and by optimizing Managed Lustre performance for a range of development tasks and workloads – making Managed Lustre a “One-Stop Shop” for high-performance AI and HPC workloads.

Lower Cost: More Lustre for Less with the Dynamic Tier

The Managed Lustre Dynamic Tier provides sub-ms latency for hot data, which allows you to store all of your data in a single namespace, and costs only 6 cents/GB*month.

Throughput, capacity scale and client scale: Throughput scales linearly with capacity up to 80 PB, while sub-ms latency for hot data remains stable as you scale to tens of thousands of clients.
Single-flat fee: Predictable pricing. No independent charges for disk media types, data movement within the namespace, or metadata IOPS.
Read Latencies: Sub-ms latencies for High-Performance Cache (SSD). The Capacity Pool (“HDD”) is built on Google Cloud Hyperdisk throughput, which has an average read latency of 10 to 30 ms.

Recommended workloads for Dynamic Tier

Multi-Epoch Training and/or Training with Optimized Fetch Sizes: Hot data is promoted to the High Performance Cache (SSD) after the first run. Larger data prefetch will allow you to take advantage of the Dynamic Tier cost structure and gain from low-latency SSD.
Write-Heavy Checkpointing: Bursty checkpoint writes land directly in the High Performance Cache. Older checkpoints are transparently demoted to the Capacity Pool (HDD).
Rapid Checkpoint Restore: New checkpoints are written to the High Performance Cache, enabling low-latency checkpoint restores.
Interactive Snappiness for Developers: Low-latency tasks like git cloning, compiling libraries, or running notebooks benefit from a local-disk feel (~300µs average read latencies) on the same shared workspace hosting large training sets.

Frictionless development: Lustre as a one-stop shop for developer’s workloads

In addition to Managed Lustre’s scalability for large AI and HPC workloads (checkpoint/restart/data-loading), it also meets the demands for interactive work, meaning developers can start on Managed Lustre and stay on Managed Lustre throughout the entire workload lifecycle:

Unified Foundation & Interactive Performance

Consolidates the AI and HPC lifecycle into a single namespace, providing a "local disk" feel for interactive work (Read more about the latency benefits of Managed Lustre experienced by Salesforce and others).

Latency: ~300µs average read latency—delivering up to 4x better responsiveness than alternative distributed file systems.
Accelerated Setup: Untar the Linux kernel in ~2 minutes (4.7x faster than alternative file solutions), run a 20-worker parallel git clone of Python in ~40 seconds, compile Python in ~200s.

High-Concurrency Broadcast & Cluster Startup

Managed Lustre maximizes GPU ROI by preventing storage bottlenecks during cluster initialization.

When thousands of worker nodes attempt to read the exact same file simultaneously (such as a shared model checkpoint, base weights, or container layer), traditional distributed file systems can choke on localized hotspotting, leaving high-cost GPU clusters idle for minutes.

Improves Aggregate Throughput for a large number of clients reading the same file: Demonstrates a 67% improvement over alternative file solutions.
Parallel Loading: Imports libraries like PyTorch across 4,000+ processes in under 60 seconds.

Run One-Stop Shop Workflows for Yourself

Here is the code for the tests we’ve run, so that you can perform your own testing.

Low latency for interactive access

We used fio to emulate small, low-concurrency reads and writes:

¹Storage system specs: 500 MBps per TiB tier of Managed Lustre, 108,000 GiB capacity. Zonal Filestore at 102,400 GiB capacity. Average throughput of 36.7 GB/s to 2,048 client VMs reading the same 40 GiB file.

code_block: <ListValue: [StructValue([('code', '# Read workload\r\nfio --ioengine=libaio --filesize=100M --ramp_time=2s \\\r\n --runtime=2m --time_based --numjobs=1 --direct=1 --verify=0 --randrepeat=0 \\\r\n --group_reporting --directory=~/LUSTRE_MOUNT \\\r\n --name=randread --blocksize=4k --iodepth=1 --readwrite=randread \\\r\n --buffer_compress_percentage=50\r\n\r\n# Write workload\r\nfio --ioengine=libaio --filesize=100M --ramp_time=2s \\\r\n --runtime=2m --time_based --numjobs=1 --direct=1 --verify=0 --randrepeat=0 \\\r\n --group_reporting --directory=~/LUSTRE_MOUNT \\\r\n --name=randwrite --blocksize=4k --iodepth=1 --readwrite=randwrite \\\r\n --buffer_compress_percentage=50'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f9f33d0>)])]>

Accelerated setup

How to run Linux untar

code_block: <ListValue: [StructValue([('code', '# Download a kernel tarball\r\nwget -P /tmp https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.18.9.tar.xz\r\n\r\n# Extract the archive to the Lustre mount\r\nmkdir ~/LUSTRE_MOUNT/kernel\r\ntar -C ~/LUSTRE_MOUNT/kernel -xf /tmp/linux-5.18.9.tar.xz'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f9f1ed0>)])]>

In the above use case, you will want to take care to avoid the metadata performance tax that can come from running as root (Namely, tar issues chown and chmod calls to make extracted files’ owner+permissions match the ones recorded in the archive.). If you still wish to run as root (and have verified that this approach is compatible with your setup), you may specify `--no-same-owner --no-same-permissions` in order to ensure that extracted files maintain root as owner and have root's default file permissions. In other words, it makes extraction as root behave like extraction as non-root (by ignoring the owner+permissions in the archive).

How to run Python gitclone

code_block: <ListValue: [StructValue([('code', 'git config --global checkout.workers 20\r\nmkdir ~/LUSTRE_MOUNT/python\r\ngit clone https://github.com/python/cpython.git ~/LUSTRE_MOUNT/python'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f9f01d0>)])]>

How to run Python compile

code_block: <ListValue: [StructValue([('code', 'pushd ~/LUSTRE_MOUNT/python\r\n./configure > /dev/null\r\nmake > /dev/null\r\npopd'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f9f0310>)])]>

High scale distribution

Aggregate throughput for distributing one large file to many nodes

Run the below on each client VM:

code_block: <ListValue: [StructValue([('code', '# Start fio in server mode\r\nfio --server'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f9f1890>)])]>

Run the below on a selected client VM:

code_block: <ListValue: [StructValue([('code', "# Create a 40 GiB file\r\nfio --name=job1 \\\r\n --ioengine=libaio \\\r\n --direct=1 \\\r\n --buffer_compress_percentage=50 \\\r\n --blocksize=4m \\\r\n --iodepth=32 \\\r\n --filesize=40g \\\r\n --readwrite=write \\\r\n --filename ~/LUSTRE_MOUNT/40gb_test\r\n\r\n# Create an fio job file for the read workload\r\ncat <<'EOF' > /tmp/read.fio\r\n[job1]\r\nfilename=${HOME}/LUSTRE_MOUNT/40gb_test\r\nrw=read\r\nbs=4m\r\nexitall_on_error=1\r\nEOF\r\n\r\n# Run the read workload using all client VMs in ~/hostfile\r\nfio --client ~/hostfile /tmp/read.fio"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43c3059d0>)])]>

Parallel loading of libraries across many processes

Run the below on a selected client VM:

code_block: <ListValue: [StructValue([('code', '# Install PyTorch in a virtual env\r\npython3 -m venv ~/LUSTRE_MOUNT/env\r\nsource ~/LUSTRE_MOUNT/env/bin/activate\r\npip3 install --upgrade pip\r\npip3 install torch torchvision torchaudio \r\ndeactivate\r\n\r\n# Import PyTorch on all client VMs in ~/hostfile, 4 processes per host\r\nmpirun --allow-run-as-root --oversubscribe --hostfile ~/hostfile -N 4 \\\r\n bash -c \'source ~/LUSTRE_MOUNT/env/bin/activate && python3 -c "import torch"\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42fd3e210>)])]>

Looking ahead and next steps

By eliminating the manual data staging tax and lowering entry costs with the Dynamic Tier, Google Cloud Managed Lustre is evolving from an elite, single-purpose engine into a highly versatile, unified storage fabric for the entire AI lifecycle.

In the second part of this series, we will focus on upcoming object integration features. Stay tuned!

Next steps

Run the benchmarks yourself (if you haven’t already): Deploy a Google Cloud Managed Lustre instance using the Google Cloud console and run tests provided above to benchmark your own workloads.
Explore the Dynamic Tier: Read the Google Cloud Managed Lustre Documentation to learn more.
Stay tuned for Part 2: In the next installment of this series, we will dive deep into upcoming object integration features and how they further simplify AI and HPC storage.
Get started with centralizing your development-to-training lifecycle on Google Cloud Managed Lustre!

The future of browser-based security: Leveraging browser data for proactive defense

Thu, 01 Oct 2026 09:02:00 +0000

The browser has changed significantly. Rather than just a window to the web, it serves as an AI workspace and central operating environment for the modern enterprise. With knowledge workers spending over 56% of their workday in the browser, it is a key gateway for daily work, complex workflows, and direct interaction with autonomous AI agents (Omdia, 2026). To keep pace with threat actors, organizations need a browser strategy that places browser telemetry at the center of their security architecture.

The rise of shadow AI and agentic risk

As enterprises adopt AI, new vulnerabilities have emerged. Shadow AI —the unauthorized use of public generative AI tools—can expose sensitive corporate IP through prompt sharing and autonomous agent actions. Ninety-two percent of organizations express concern around potential data leakage through these channels. Leaving this unmonitored creates significant risk (Omdia, 2026).

Legacy security stacks, including traditional endpoint detection and response (EDR) and perimeter firewalls, are fundamentally blind to in-browser interactions. They completely miss high-risk threat vectors unique to AI-driven workflows, such as:

Malicious extensions that "read" sensitive financial data or "write" keyloggers onto sign-in pages.
"Living off the land" (LOTL) tactics and session hijacking.
State-sponsored threat actors leveraging AI to accelerate the attack lifecycle.

Chrome Enterprise Premium: Your high-fidelity telemetry engine

Chrome Enterprise Premium addresses this visibility gap by capturing browser telemetry. Rather than relying on external observation after the fact, Chrome Enterprise records signals directly at the point of user interaction.

Core Capabilities for Modern Defense

Real-time signals: Continuous telemetry for network events, high-risk user behaviors, and suspicious domain access.
Extension telemetry: Granular visibility into side-loaded extensions and extension-to-domain communications that traditional EDR might miss.
GenAI and SaaS app reporting: A dedicated capability to discover and govern sanctioned versus unsanctioned AI tools across the fleet.
Evidence locker: The ability to capture files and content that violate DLP policies, providing a crucial trail for forensic analysis, root cause determination, and detection rule refinement.

Transforming reactive review into proactive mitigation

Transitioning to proactive defense allows security teams to mitigate threats early. By streaming browser signals into security operations platforms such as Google Security Operations, teams can automate responses and reduce manual investigation time, lowering incident response costs.

Insights from the frontlines: Mandiant case studies

Mandiant observations reveal the practical impact of browser visibility. These cases show how browser telemetry helps detect attacks that bypass standard controls:

RMM Software Download: Chrome Enterprise Premium flagged a legitimate Remote Monitoring and Management (RMM) executable because it originated from a newly registered domain—a key indicator of social engineering that network tools often miss.
Credential Harvesting: Chrome Enterprise Premium evaluated URL risks and navigation parameters at the precise moment of interaction, disrupting a phishing attempt before the user could submit credentials.
Malvertising: Integration with Google Threat Intelligence allowed for immediate identification of a malicious ad click, containing the threat before the actor gained hands-on-keyboard access.

Closing the security gap starts with recognizing that the browser is a key resource for enterprise security. With Google telemetry spanning billions of protected devices, organizations can maintain defensive visibility alongside emerging AI usage to drive a proactive security strategy (Google Safe Browsing).

Ready to transform your security posture?

Avoid leaving a blind spot in your security strategy. Learn more about web defense options by reading our digital paper, "Securing the Browser: How telemetry brings web defense into the next frontier."

This resource outlines a framework for modern defense, detailing adversary tactics, infection vectors, and threat trends. Read the digital paper to evaluate your organization's browser security strategy.

Introducing the Server Side Cloud Swift SDK

Thu, 01 Oct 2026 04:00:00 +0000

For years, Swift was perceived mainly as a UI language tied to Apple client devices. With Swift 6 and strict concurrency checking, it has matured into a viable systems and cloud language, pairing Rust-like data-race safety with predictable, reference-counted performance.

To support this ecosystem, Google engineering has launched the official Google Cloud API Client Libraries for Swift. Built from the ground up for Swift 6.2+, this new SDK uses the latest non-blocking Swift NIO event loops, HTTP/2 multiplexing, gRPC transport, and zero-cost compile-time data race safety.

In this article, we'll walk you through all you need to know to get started, and to understand how the Server Side Cloud Swift SDK, or google-cloud-swift, works.

The rise of server-side Swift and cloud-native concurrency

Traditional backend development often forces a trade-off between developer ergonomics and resource utilization. While managed runtimes offer rapid development, lower-level systems languages provide finer control over memory and CPU footprint, often at the expense of feature velocity.

Server-side Swift aims to strike a practical balance. Swift pairs a lightweight runtime and Automatic Reference Counting (ARC) with expressive syntax. More importantly, Swift 6 introduces compile-time concurrency checking. When you share state between async tasks across a cloud microservice, the compiler enforces that types conform to Sendable. Data races are caught in your editor before a binary ever compiles or reaches production.

At the network layer, every request to Google Cloud APIs runs over event-driven, non-blocking sockets that scale across multicore Linux server environments without spawning system threads per connection.

Where to use the Swift SDK

The Server Side Cloud Swift SDK is engineered for server, container, and automated DevOps environments.

When you build high-throughput microservices with Swift web frameworks like Hummingbird or Vapor, google-cloud-swift provides native access to Cloud Storage, AI, Identity and Access Management (IAM), and over one hundred other Google Cloud services. You can containerize your executable on Linux and deploy directly to Cloud Run, Google Kubernetes Engine (GKE), or Compute Engine VMs.

Because the SDK compiles on macOS, and Linux, you can develop the backend in your preferred development environment, and then seamlessly deploy to production. And using Swift on both the frontend and backend allows you to share application-specific types across both.

The SDK also excels at platform engineering and DevOps automation. You can author cross-platform CLI utilities and data rotation scripts that run on your developer laptop or inside CI/CD pipelines. These tools authenticate automatically against Google Cloud using Application Default Credentials (ADC) or Workload Identity Federation.

If you're building an iOS, iPadOS, or visionOS app for the Apple App Store, you should not embed google-cloud-swift directly into your client bundle. Shipping Google Cloud service account keys or administrative credentials inside a client binary creates security risks. For direct client-side features, use the Firebase SDK for Apple Platforms to handle user authentication, real-time Firestore sync, and client-side security rules, or route requests through your own Cloud Run backend API.

Getting started with your IDE and packages

Because google-cloud-swift treats Linux and macOS as first-class citizens, you can develop on Apple hardware with Xcode or on Linux workstations with Visual Studio Code and swiftly.

To install the official Swift compiler on Linux workstations using the swiftly CLI installer, run:

code_block: <ListValue: [StructValue([('code', 'curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz &&\r\ntar zxf swiftly-$(uname -m).tar.gz &&\r\n./swiftly init --quiet-shell-followup &&\r\n. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" &&\r\nhash -r'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f494bd0>)])]>

Alternatively, you can download prebuilt toolchain tarballs directly from official Swift Downloads for Ubuntu, Debian, Fedora, or Amazon Linux. Note that google-cloud-swift requires Swift 6.2 or later, so verify your compiler version with swift --version after installation.

To resolve Swift Package Manager bare repository trust warnings when cloning across Linux filesystems, configure Git before building with git config --global safe.bareRepository all.

Add the required packages to your Package.swift manifest:

code_block: <ListValue: [StructValue([('code', 'swift package add-dependency https://github.com/googleapis/swift-google-cloud-language-v2.git --from 0.4.0\r\nswift package add-target-dependency GoogleCloudLanguageV2 CloudBackendService --package swift-google-cloud-language-v2'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f497a90>)])]>

On macOS you need to change the platforms directive:

code_block: <ListValue: [StructValue([('code', '// swift-tools-version: 6.2\r\nimport PackageDescription\r\n\r\nlet package = Package(\r\n name: "CloudBackendService",\r\n // Applied when compiling on Darwin/macOS; ignored by SPM on Linux targets\r\n platforms: [.macOS(.v15)],\r\n ... ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f4940d0>)])]>

In most environments a default-initialized client can make requests:

code_block: <ListValue: [StructValue([('code', 'import Foundation\r\nimport GoogleCloudLanguageV2\r\n\r\nfunc analyzeTextSentiment(text: String) async throws {\r\n // Initialize explicit API key credentials\r\n let client = try LanguageServiceClient()\r\n\r\n // Configure request using structured builder closure\r\n let document = Document().with {\r\n $0.type = .plainText\r\n $0.source = .content(text)\r\n }\r\n\r\n let response = try await client.analyzeSentiment(\r\n request: AnalyzeSentimentRequest().with { $0.document = document }\r\n )\r\n\r\n if let sentiment = response.documentSentiment {\r\n print("Document sentiment score: \\(sentiment.score)")\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc42f497e90>)])]>

Notice how Document().with { ... } avoids verbose temporary variables or mutating setters by providing a clean, thread-safe configuration closure.

Networking, transport, and authentication

The repository splits infrastructure primitives into modular packages under packages/:

swift-google-cloud-auth: Implements Application Default Credentials discovery, service account JWT signing, external account exchange for Workload Identity Federation, and API keys.
swift-google-cloud-wkt: Provides idiomatic Swift types for Google Protocol Buffer well-known types, including nanosecond-precision Timestamp representations that bridge cleanly to Swift's Date.
swift-google-cloud-gax: Handles Google API Extensions such as automated retry loops, exponential backoff, and pagination state machines.

When you initialize any client library without arguments, Credentials.default() automatically scans your environment (GOOGLE_APPLICATION_CREDENTIALS, quota project variables, or the local Google Cloud CLI configuration) and authenticates connections over gRPC or HTTP/2.

If you need to programmatically override credentials with an API key or attach custom access headers, you can pass explicit configuration options. For example, you could modify the previous example to use the following:

code_block: <ListValue: [StructValue([('code', 'import Foundation\r\nimport GoogleCloudAuth\r\nimport GoogleCloudGax\r\nimport GoogleCloudLanguageV2\r\n\r\nfunc analyzeTextSentiment(apiKey: String, text: String) async throws {\r\n // Initialize explicit API key credentials\r\n let credentials = try Credentials(configuration: .apiKey(apiKey))\r\n let client = try LanguageServiceClient(\r\n ClientOptions().with { $0.credentials = credentials }\r\n )\r\n\r\n // Configure request using structured builder closure\r\n let document = Document().with {\r\n $0.type = .plainText\r\n $0.source = .content(text)\r\n }\r\n\r\n let response = try await client.analyzeSentiment(\r\n request: AnalyzeSentimentRequest().with { $0.document = document }\r\n )\r\n\r\n if let sentiment = response.documentSentiment {\r\n print("Document sentiment score: \\(sentiment.score)")\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43c24bcd0>)])]>

The autogenerated client ecosystem

Google Cloud operates a vast ecosystem of APIs whose schemas update regularly. The teams supporting google-cloud-swift use code generators to automatically update the client libraries with the latest features and with new APIs. Using code generators produces stable APIs, without disruptive breaking changes. While the releases are on a fixed cadence, please contact Cloud Customer Care if you need a particular feature or API urgently.

Whether you need to rotate keys in Secret Manager or invoke multimodal inference models via the Gemini API on Gemini Enterprise Agent Platform, the generated SDKs follow consistent naming and async/await signatures.

These generated clients offer more than plain unary RPC wrappers. They also offer wrappers that simplify application development. For example, iterating over long results involves fetching pages of results with one RPC, iterating over the page of results, and then preparing a new request to retrieve the following page. Using the generated clients this becomes an asynchronous iterator. This example shows how to query project secrets using GoogleCloudSecretManagerV1:

code_block: <ListValue: [StructValue([('code', 'import Foundation\r\nimport GoogleCloudSecretManagerV1\r\n\r\n@main\r\nstruct SecretManagerQuickstart {\r\n static func main() async throws {\r\n guard let projectId = CommandLine.arguments.dropFirst().first else {\r\n print("Usage: SecretManagerQuickstart <projectId>")\r\n exit(1)\r\n }\r\n\r\n // Connects using Application Default Credentials automatically\r\n let client = try SecretManagerServiceClient()\r\n\r\n let request = ListSecretsRequest().with {\r\n $0.parent = "projects/\\(projectId)"\r\n }\r\n\r\n // Async sequence streams pages of secrets automatically\r\n print("Secrets in project \\(projectId):")\r\n for try await item in try client.listSecretsByItem(request: request) {\r\n print(" - \\(item.name)")\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43c249490>)])]>

The pagination response returns an asynchronous sequence (AsyncSequence). You can iterate over items with for try await while the client library fetches subsequent pages in the background over non-blocking NIO channels.

Where to go next

With google-cloud-swift, server-side Swift developers can write end-to-end cloud infrastructure with compile-time race safety, native async/await ergonomic APIs, and zero OS thread congestion.

To inspect the source code, open issues, or contribute new veneers, visit the official repository at googleapis/google-cloud-swift.

Want to discuss server-side Swift architectures or Cloud Run containerization? Join the Google Developer Program to continue the conversation.

What’s new in AI infrastructure and orchestration in September

Wed, 30 Sep 2026 16:00:00 +0000

We hereby declare September to be scalability month! As the world prepares for a surge of agentic fleets, we are shoring up our AI infrastructure and orchestration offerings to gracefully — and quickly — respond to that demand, all while maintaining workload isolation and security, and keeping costs in check. Read on to learn how these enhancements manifest across Google Cloud’s compute, network, storage, and orchestration offerings, plus new ways customers are using Google Cloud AI infrastructure, and third-party industry validation of our strategy.

Product, technology, and tools updates

Google Kubernetes Engine updates: The GKE team is all about improving the scalability of the platform, and in September, those improvements came in many shapes and sizes:

New feature: Need an execution runtime with higher density for your agentic workloads? We engineered the new open-source GKE Agent Substrate to run millions of sandboxes with 10x higher density than standard container runtimes. Agent Substrate also delivers sub-500ms resume operations at over 500 suspend/resume activations per second with a native zero-trust kernel and network isolation.
Product update: GKE now has scale-to-zero capabilities built-in. No need to configure complex components to scale your workloads down, thanks to the HPA with the Autoscaling Metric and support for KEP-2021, which do the job for you, out of the box. Read the blog to learn more.
Product update: Further, the GKE HPA (with the above-mentioned Autoscaling Metric) now lets you scale up and down based on custom PromQL metrics, in addition to standard metrics, allowing you to trigger workloads according to conditions that are meaningful and unique to your business. Read more here.
New feature: Yet another scalability feature is GKE Pod snapshots, which lets you save the running state of your workload, including CPU and GPU memory, and restore it on demand. According to internal tests, GKE Pod snapshots can reduce AI inference start-up by as much as 89%. Learn more here.
New migration tool: Finally, if you’ve always wanted to migrate your container workloads from AWS EKS to GKE but feared a daunting, high-friction engineering endeavor, we’ve just launched GKE agentic migration, a purpose-built agent plugin that replaces brittle, ad-hoc prompting with an AI-assisted migration pipeline protected by deterministic guardrails. Designed as a compilation of agent skills and a local Model Context Protocol (MCP) server, it uses AI to translate complex AWS EKS IaC and Kubernetes manifests directly into GKE landing zones. Get started with the onboarding guide.
Feature updates: Reinforcement learning (RL) and evaluation workloads are a beast: In a standard agentic RL loop, an LLM policy generates actions like code snippets on GPUs and executes them inside isolated CPU sandboxes to observe a reward signal. However, when scaling up this loop to support tens of thousands of parallel rollouts, infrastructure bottlenecks emerge, for instance idle accelerators, image cardinality, and a saturated control plane. To help, we developed GKE Agent Sandbox optimized for RL, plus an Agent Sandbox RL orchestration SDK and native integrations for popular RL gyms and harnesses. All are now generally available, and you can learn more here.

Storage updates: AI trains and creates lots of data, and that data has to live somewhere — in block storage systems, file systems, object stores and databases. We announced enhancements to our storage portfolio to help this critical layer roll with the agentic punches:

Product update: Filestore agent volumes offer high-performance, elastic, persistent file storage for agentic workloads. Thanks to its tight integration with GKE Agent Substrate and GKE Agent Sandbox, Filestore agent volumes automatically allocates and attaches a dedicated, isolated file workspace to GKE agent sandboxes in milliseconds. Request access to the preview here.
New product: If you run generative AI and RAG data layers — think Milvus, Pinecone, Qdrant, Vespa, Redis, and in-memory context caching — you may want to take a look at the M4N family of VMs, now GA, which offers the highest per-core IOPS and throughput of leading hyperscalers. Paired with Google Cloud's custom Titanium offload architecture and paired with Hyperdisk Extreme, M4N instances deliver up to 25,000 MiB/s (25 GiB/s) of aggregate host storage performance and up to 1 million IOPS.
New product: Another new Compute Engine product, Z4D, is GA, and a strong storage solution for AI/ML training and inference workloads. When configured as a bare metal instance, Z4D provides both the high local SSD (LSSD) capacity and low latency required by agentic microVMs, so you can run thousands of isolated sandboxes per host with native performance and efficiency. Learn about Z4D machines here.
Product update: Today’s AI training and inference pipelines create data faster than most storage management systems can keep up, creating challenges for teams trying to understand their storage estates. A new version of Storage Intelligence advisor makes it easier to answer the question: "What’s in my buckets?" and quickly identify unexpected changes. Then, enhanced batch operations let you automate bulk changes across your buckets — say, move storage classes, mass-delete stale or temporary data, or apply metadata, tagging, retention, or encryption changes. Learn about the latest in Storage Intelligence advisor here.
New product: Last but not least, a new version of AlloyDB for PostgreSQL brings together pioneering Google infrastructure — Colossus distributed file system, and Jupiter network — to power a new, no-compromises database architecture for the agentic era.

Practitioner guides and how-tos

How-to: Wish you could make GPUs and TPUs scattered around the globe behave as a single pool behind a single entry point? In this blog, we show you how to do just that. At the edge, the multi-cluster GKE Inference Gateway focuses on global, multi-region traffic distribution and high availability. Beneath that, the LLM-d router handles complex, memory-aware scheduling algorithms to keep utilization high. This architecture is deliberately runtime-, model-, and accelerator-agnostic, and in tests, routing traffic through the multi-cluster GKE Inference Gateway added less than 1% overhead.
Guide: Using or planning to use GKE on TPUs for AI model training or inference? Training massive Large Language Models (LLMs) or running high-throughput inference serving represents a significant investment in specialized AI hardware, such as Cloud TPUs and GPUs. To get the most out of every dollar spent, you need to understand workload lifecycle metrics in GKE. This detailed guide explains how to turn opaque cluster behaviors into actionable telemetry.

Customer and partner updates

GKE customer: Learn why gaming startup SeaVerse relies on GKE Agent Sandbox for its multi-tenant workloads, and how the platform helped it decrease its infrastructure costs by 60%.

Research, reports and deep-dives

In case you missed it, we’re also thrilled to share that Google has been named a leader, including achieving the highest score on either product or strategy, in three key analyst reports from Gartner and Forrester.

Google is a leader in The Forrester Wave™: Public Cloud Platforms, Q3 2026: Highest overall score of any cloud provider!
Google named a Leader in 2026 Gartner® Magic Quadrant™ for Strategic Cloud Platform Services: Positioned furthest for “Completeness of Vision” of all vendors evaluated.
Google is a Leader in the 2026 Gartner Magic Quadrant for Container Management: Positioned highest in “Ability to Execute” of all vendors evaluated.
Google Cloud achieved a Gold rating in the latest SemiAnalysis ClusterMax 3.0 report, which evaluates the reliability, performance, support, pricing, and security of GPU providers globally. See the full report for more.

August 2026

Product, technology, and tools updates

Product update: Filestore, Google Cloud’s first-party, secure, scalable NFS file service, has emerged as a popular storage platform for AI and agentic workflows, and now, it’s even better suited to the task, with a new backend storage layer built directly on Colossus, Google’s foundational distributed storage system. This new backend lets you provision IOPS independently from storage capacity, and is deeply integrated with GKE. In AI environments, this can help you service so-called agentic swarms — large groups of agents that need to read and write to a common dataset — without a drop off in performance. For more, check out the blog post.
New feature: gVisor sandboxes are now available in distributed Ray clusters on GKE. In partnership with Anyscale, we introduced an experimental library for Ray that brings gVisor, Google’s open-source application kernel, directly into distributed Ray clusters. gVisor provides lightweight environments with stronger isolation than ordinary containers, plus fast startup times and low memory overhead. To try out these sandboxing capabilities on GKE, head over to the Ray sandboxing User Guide.
Product update: Looking for high-performance, easy-to-use infrastructure on which to run a personal AI agent, but don’t want to spend a lot of money? New Cloud Run instances are dedicated, singleton compute runtimes on Cloud Run that won’t shut down when the agent is idle. Better yet, the cost to run a Cloud Run instance with 1 vCPU and 1 GiB of memory continuously for 30 days is just $5.70.

Practitioner guides, documentation and how-tos

How-to guide: Big news in Model Context Protocol (MCP) land: As of the 2026-07-28 specification, the protocol core is “completely stateless. The handshake is gone. The initialize / initialized handshake (SEP-2575) and the logical Mcp-Session-Id header (SEP-2567) have been removed entirely. Instead, every request is now self-describing and independent.” Whoa. Learn more about the changes that the latest MCP specification brings, and more importantly, how to implement them, in this Google Developers blog.
Guide: Real-time AI systems make a mess of traditional network load balancing techniques. “Instead of handling isolated requests, the backend has to manage a continuous, live bidirectional stream. You’re dealing with a constant stream of audio chunks, transcripts, model outputs, and synthesized speech flowing back and forth simultaneously.” Things only get worse when the user gets involved. “The server has to immediately halt its current speech generation, pivot to update the context, maybe trigger a new tool, and start drafting a different response; this must be done without dropping the connection.” For a new approach to managing load in the AI era, read Scaling real-time AI agents with session-aware load balancing.
How-to: Learn how to build an elastic, scalable LLM inference platform on GKE, even with a mix of different GPU accelerators. The proposed architecture combines Capacity Advisor and Compute Advisor, plus high-performance storage like RunAI:model streamer or GCPFuse with parallel downloads. Get all the details here.
Documentation: The thing about hosts with GPUs or TPUs is that you can’t use live migration to update them, setting up a maintenance challenge. In this new docs page, learn how to update accelerator-equipped hosts according to your tolerance for downtime for your training and inference workloads.
Documentation: Advanced Compute Images, or ACIs, are standardized image stacks for AI/ML and HPC infrastructure, so you don’t need to manually build your own custom images. In this new docs page, learn how to create an ACI image using the Google Cloud CLI, console, or SchedMD's Slurm workload manager.
Guide: AI workloads are notoriously difficult to architect, resource-intensive, and bursty, which can also lead to scaling bottlenecks and large pools of underutilized — or misutilized — compute resources. A new blog outlines the three main ways to achieve dynamic capacity management in Google Cloud: 1) scheduling capacity for planned downtime; 2) maintaining automated fallback capacity for unplanned downtime; and 3) relying on GKE’s core orchestration capabilities to automate resource allocation.

Customer and partner updates

Business orchestration software provider UiPath was dealing with spiky workloads, and wanted more predictable costs. To get there, it re-architected its infrastructure, moving from isolated clusters to a shared Google Cloud GPU fleet that included both A3 VM instances (NVIDIA H100 GPUs) for training with G4 VM instances (NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs) for inference. You can read more about their architecture here.
Mirendil, an frontier AI lab focused on accelerating AI development, announced that it is using AI Hypercomputer with both TPUs and NVIDIA GPUs to support its model pre-training and post-training applications.
Replenit, a retail CRM provider, built its AI decision engine in Google Cloud, using BigQuery, Gemini Enterprise Agent Platform, and open-source Gemma models that it runs on Cloud TPUs. This latter combination provided Replenit with 90% lower pipeline costs than their previous cloud provider, the company reports. Read the full case study for more.
Malachyte architected its AI-powered e-commerce recommendation platform on top of Bigtable, Managed Service for Apache Kafka, Pub/Sub, Compute Engine, and last but not least, GKE. See how it all comes together in this blog.

July 2026

Product, technology, and tools updates

Product update: Google Cloud Managed Lustre is now GA, and available in four distinct performance tiers that deliver throughput ranging from 125 MB/s, 250 MB/s, 500 MB/s, to 1000 MB/s per TiB of capacity — with the ability to scale up to 8 PB of storage capacity. The Managed Lustre solution is powered by DDN’s EXAScaler, combining DDN's decades of leadership in high-performance storage with Google Cloud's expertise in cloud infrastructure.
Product update: C4N network and storage optimized VMs are now GA. C4N is our first network- and block-storage-optimized VM series built to eliminate data-transfer bottlenecks. Powered by 5th Gen Intel Xeon Scalable processors and built on Google's Titanium offloading hardware, it achieves 400 Gbps network bandwidth, 95 million packets per second (MPPS), and up to 25 GiB/s of block storage throughput when paired with Hyperdisk Extreme.
New feature: GKE Dataplane V2 up to 15K Nodes with Network Policies (GA). This capability enables standard GKE clusters to scale up to 15,000 nodes while maintaining full active Network Policy enforcement, supporting the massive infrastructure needs of large enterprise and AI/ML customers.
New feature: Co-operative time-slicing in llm-d. If you’re running reinforcement learning (RL) workloads, you can now interleave independent RL jobs onto shared physical hardware, increasing aggregate accelerator duty cycles from a ~40% baseline up to 70% without impacting model convergence or accuracy.
New AI security tool: Looking to secure your AI supply chain on GKE, deploy AI workloads safely, and cut down on shadow AI? We open-sourced k8s-aibom, a lightweight, unprivileged Kubernetes controller that continuously monitors container clusters to automatically detect running AI runtimes (like vLLM and Triton) and generate standard CycloneDX Machine Learning Bill of Materials (ML-BOMs). Check out the k8s-aibom project and get involved.

Practitioner guides and how-tos

How-to guide: On July 27, Google announced Day 0 support for Moonshot AI’s Kimi K3 2.8-trillion-parameter open-weight model, the day weights were released. Whichever your preferred deployment path — via Model Garden, custom orchestration, or GKE with llm-d recipes — this guide offers detailed step-by-step instructions to help you evaluate and pilot Kimi K3 in Google Cloud.
How-to guide: Google Kubernetes Engine (GKE) managed DRANET supports both GPUs and TPUs. There are several configurations to use this implementation, including standard cluster (where you have full control) and autopilot cluster (where Google does the heavy configs for you). Take a deeper dive in the hands-on lab, GKE Autopilot clusters with TPUs, GKE managed DRANET and Gemma 4.
How-to guide: Learn to run Ray on TPUs, not GPUs. In Part 1 of this two-part series, we discuss TPU slices (hint: Ray thinks of them as just another accelerator on which to schedule), then walk through Ray’s various AI libraries (Part 2).
How-to guide: Evaluate TPUs for sample workloads using a new microbenchmark suite that helps you accurately assess whether a device is achieving its theoretical performance specifications, and to identify specific performance gaps or architecture-specific bottlenecks. Dive in here.
How-to guide: Scale your agents without killing your budget. Learn how GKE orchestration can help you safely pack more agents onto a fixed compute footprint with GKE Agent Sandbox and Pod snapshots. Whether your goal is performance or cost optimization, we teach you how to turn the right dials for optimal agent efficiency.
Technical blueprint: Inside the optimization of Mistral 3 large inference on Ironwood. This blog outlines how one Google team optimized Mistral 3 large MoE model inference on Google’s Ironwood (TPU v7x), achieving a 1.5x performance gain. They did so with hybrid sharding, replacing linear VPU summations with tree reductions, optimizing GMM/MLA kernels, and adopting asynchronous scheduling. As a result, they boosted throughput by up to 48% while maintaining benchmark accuracy neutrality. Read the full blog here.

Research, reports and deep-dives

Report: Google was named a Leader in the inaugural GartnerⓇ Magic Quadrant™ for AI Infrastructure, positioned highest for ‘Ability to Execute’ and furthest for ‘Completeness of Vision’. Gartner called out Google’s proprietary scalable compute, integrated AI Hypercomputer architecture, and the scale of our AI compute capacity as key strengths. Download a copy here.
Report: We recently surveyed more than 1,400 senior IT leaders for our State of AI Infrastructure report, and a resounding pattern emerged: The gap between AI ambition and infrastructure reality is widening. In fact, 83% of organizations say they require infrastructure upgrades to support production-grade agentic AI. Read the accompanying blog to understand how adapting your infrastructure to meet the demands that agentic applications place on your systems will help you move from pilot to production.

June 2026

Product, technology and tool updates

Product update: Protecting sensitive data used with AI is a critical part of advanced and secure cloud infrastructure. Confidential Computing cryptographically protects data in use in hardware-based Trusted Execution Environments (TEEs) with verifiable data integrity, and is now available on the accelerator-optimized G4 machine series, featuring NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. Get started with Confidential G4 VMs and Confidential G4 GKE Nodes.
Developer resource: The new TPU Developer Hub is the place to go for model builders, optimizers, and developers to learn to unlock the full performance of Google Cloud TPUs. Read more in this blog.
New product: Scale your AI workloads with the new OpenTelemetry-Based TPU AI Telemetry Collector Agent. For the first time, you can route high-fidelity TPU hardware telemetry to Google Cloud Monitoring, Google Managed Prometheus, or your own self-hosted Grafana stack.

Practitioner guides and how-tos

How-to guide: Learn how to build high availability into an AI inference workload running on GKE Inference Gateway with TPUs, Cloud Storage FUSE and Dynamic Resource Allocation (DRA). This blog provides an overview, or you can get all the technical details in the hands-on codelab.
How-to guide: Did you know you can connect your AI agents to unstructured data in Cloud Storage via Model Context Protocol (MCP)? In this blog, learn about why would want to do that from three customer examples, then how to do it, choosing either a fully managed service, or a self-managed local server for more customization and control.

Research, reports and deep-dives

Report: According to an independent benchmark report, GKE Inference Gateway outperforms the next leading managed Kubernetes service with 15.7% higher throughput, 92.8% shorter wait times, and 62.6% lower inter-token latency. This performance can be attributed to its use of prefix caching, which optimizes LLM performance by storing the KV cache (activation states) of long, repetitive prompt prefixes. Learn more in the blog.
Architecture deep dive: A closer look at the cold start problem, this time for TPUs and GKE, and how the Run:ai Model Streamer can help change the dynamic.

Customer and partner updates

Customer win: Leveraging GKE, BigQuery, Cloud SQL, and Gemini Enterprise Agent Platform, Pager Health is eliminating operational fragmentation to deliver a simplified, personalized U.S. healthcare experience that transforms lives.
Customer win: Trustpilot, the customer review platform, built a high-volume streaming pipeline using fine-tuned Gemma models with Dataflow and Gemini Enterprise Agent Platform running on cost-optimized A2 VMs using A100 GPUs, as well as optimized version of vLLM maintained by Gemini Enterprise Agent Platform.

May 2026

Product, technology and tool updates

Product update: GKE Agent Sandbox is now generally available.
New open-source project: Agent Substrate is a new open-source project aimed at continuing to push the limits of agentic infrastructure density
New feature: Google AI Edge Portal, a solution for testing and benchmarking on-device machine learning (ML) at scale, now supports benchmarking and debugging on-device LLMs. Read more here.
Product deep dive: We went into depth about Cloud Storage Rapid, a new family of high-performance storage offerings for AI workloads. At launch, offerings include Rapid Bucket (formerly Rapid Storage), a high-performance zonal object storage offering, and Rapid Cache (formerly Anywhere Cache), which accelerates reads on-demand and colocates compute and data for workloads in existing buckets.

Research, reports and deep dives

Architecture deep dive: Google Global Infrastructure VP Bikash Koley and Engineering Fellow Arjun Singh provide a high-level overview of the challenges that AI workloads pose to network infrastructure, and discuss the deep enhancements we’ve made to our data center fabrics, WAN, and global networks to better support them.
Architecture deep dive: We unveiled a new cluster-level reliability model for developing frontier AI models on TPUs, ditching instance-level reliability

Customer and partner updates

Customer win: Visual media provider Imgix serves more than 8 billion images and videos from AI Hypercomputer equipped with G4 VMs powered by NVIDIA RTX PRO 6000 Blackwell GPUs.

Cloud CISO Perspectives: How cybersecurity startups can win CISOs

Wed, 30 Sep 2026 16:00:00 +0000

Welcome to the second Cloud CISO Perspectives for September 2026. Today, Alicja Cade and Nick Godfrey, senior directors, Office of the CISO, share their guidance for cybersecurity startups on how to win over the CISOs who will become crucial business partners and customers.

As with all Cloud CISO Perspectives, the contents of this newsletter are posted to the Google Cloud blog. If you’re reading this on the website and you’d like to receive the email version, you can subscribe here.

aside_block: <ListValue: [StructValue([('title', 'Get vital board insights with Google Cloud'), ('body', <wagtail.rich_text.RichText object at 0x7fc42f8cb890>), ('btn_text', 'Visit the hub'), ('href', 'https://cloud.google.com/solutions/security/board-of-directors?utm_source=cgc-site&utm_medium=et&utm_campaign=FY26-Q2-GLOBAL-GCP39634-email-dl-dgcsm-CISOP-NL-177159&utm_content=-&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

How cybersecurity startups can win CISOs

By Alicja Cade, Senior Director, Financial Services, Office of the CISO, and Nick Godfrey, Senior Director, Office of the CISO

Alicja Cade, Senior Director, Financial Services, Office of the CISO

Cybersecurity startups play a crucial role in technology as they build to solve both legacy, existential challenges and the latest problems on the cutting edge. A key part of winning and transforming the cybersecurity field is becoming a strategic partner to CISOs and their security teams.

Google has supported more than 50 cybersecurity founders over the past four years through our Google for Startups program, including Authologic, BforeAI, Build38, Cerby, Crowdsec, Risk Ledger, and Mokn.

Christian Torres, co-founder and CEO, Kriptos, and a Google for Startups participant, said that building connections between startups and CISOs is crucial to solving critical security challenges.

Nick Godfrey, Senior Director, Office of the CISO

"The Google for Startups program has been the most impactful initiative we've joined as a cybersecurity company. Unlike other accelerator programs, this one speaks our language — the challenges, the ecosystem, and the conversations are 100% aligned with what we do every day at Kriptos. The access to CISOs and security leaders has been invaluable, and the connections we've built through the program are ones we now see regularly across industry events. It's put us exactly where we need to be,” he said.

Cybersecurity startup founders face many competing taskmasters as they fight for survival, from demanding capital funders to the relentless pressure of growing their market and networks. CISOs should be key stakeholders for cybersecurity startups so that founders focus on solving thorny challenges in a way that works in the real world.

Listening to CISOs and understanding the businesses that they serve takes time and effort, and if done right can help deliver better value and create a lasting enterprise foundation and network of allies.

Here are three top tips from September’s Gemini Startup Forum for Cybersecurity, part of the Google for Startups program, where we offered vital guidance, addressed critical domains, and helped foster deep dialogue for the next generation of AI-native cybersecurity startups.

Tip 1: Listen then design and deliver for your customers

Avoid becoming a round peg in a square hole by combining your problem-solving startup with listening to CISOs who have to protect real systems, networks, and people. Listening to CISOs and understanding the businesses that they serve takes time and effort, and if done right can help deliver better value and create a lasting enterprise foundation and network of allies.

Here’s how to develop trusted CISO relationships:

Host diagnostics meetings. Your meetings with CISOs should focus on mapping their operational bottlenecks and co-authoring collaborative solutions while studying their pain points.
Create "unselling" spaces to build peer trust. Host intimate, pitch-free roundtable discussions on industry challenges or establish a critique-only advisory board to build genuine relationships with CISOs without the pressure of a sales environment.
Use neutral networks that don’t include venture capitalists. Engage with CISOs in low-friction environments by contributing to open-source security projects and participating in academic and geopolitical risk forums where security leaders gather to solve broad industry problems.
Avoid the bait-and-switch pitch. Never disguise a sales pitch as a research or feedback session, as tricking a CISO into a product demo will permanently destroy their trust.
Center their business context. Don’t limit your listening to the technical security stack, because the CISO’s primary job is to enable and protect the broader business strategy.

Tip 2: Evaluate AI security to filter out noise

Instead of just using AI to assemble the product, startups should critically evaluate what makes your approach unique and how you communicate that to potential customers.

Define your moat by investing in proprietary datasets, specialized fine-tuning, and unique orchestration layers that create a true technical moat. Don’t be a wrapper.
Secure the intelligence by proactively designing your models to resist adversarial attacks, prompt injection, and data poisoning. In cybersecurity, model robustness is your ultimate trust signal.
Deliver high-fidelity outcomes by clearly communicating how your AI product reduces cognitive load for defenders, minimizes false positives, and integrates safely into existing operations.

Avoid using generic marketing buzzwords like "cognitive," "autonomous," or "revolutionary" without the technical documentation, case studies, and whitepapers to back them up. In a skeptical market, transparency is your best sales tool.

Tip 3: Enthusiastically embrace your sector

Keep a sharp eye out for common due diligence pitfalls during investment and merger and acquisition cycles. These include ensuring that internal engineering and cybersecurity practices meet external claims, but also evaluating the regulatory context of your business sector as well as the security and reliability of your product and service.

You have to know whether you’re required to abide by data sovereignty, data residency, and other requirements. To avoid this pitfall, engage with broader stakeholders early who know the sector and its nuances well.

How to keep the conversation going

Even beyond the crowded field of aspiring cybersecurity companies, startups broadly can benefit immensely by making sure that they listen carefully, evaluate objectively, and take to their sector requirements enthusiastically.

"Google's Office of the CISO has been a bridge between LetsData and the security leaders we need to reach. Sometimes that bridge is advice on how our offering maps to a CISO's real priorities. Sometimes it is a direct introduction to a CISO who is looking for exactly what we build. For a startup, a warm introduction at that level is priceless,” said Ksenia Iliuk, founder and COO, LetsData.

To learn more about how Google Cloud’s Office of the CISO can help support your organization, check out our CISO Insights hub.

aside_block: <ListValue: [StructValue([('title', 'Learn something new'), ('body', <wagtail.rich_text.RichText object at 0x7fc43cc9e1d0>), ('btn_text', 'Watch now'), ('href', 'https://www.youtube.com/watch?v=Wpo-5ke9uvQ'), ('image', <GAEImage: Cloud-CISO-Perspectives-logo-A>)])]>

In case you missed it

Here are the latest updates, products, services, and resources from our security teams so far this month:

Agentic hacks, real proofs: Inside Google's PageBreak project: Distinguishing a genuine, exploitable flaw from a convincing hallucination has become a major challenge, often increasing the burden on product teams. PageBreak is an internal AI agent of Google's Product Security team developed to test the security of our first-party web applications and address this challenge. Read more.
Investing together: Wiz Defend and Google Security Operations: Continuing to deepen the integration between Wiz Defend and Google Security Operations, helping teams work faster wherever they choose to investigate. Read more.
A unified view of Android security updates for enterprises and OEMs: We're introducing new libraries that give enterprise partners and OEMs a complete, real-time picture of a device’s security posture. Read more.
Delivering new partner security agents and AI defenses with Gemini Enterprise: We're expanding our catalog of partner-built security offerings in the Gemini Enterprise ecosystem to help you leverage your full security context. Read more.
Google named a Leader in the External Threat Intelligence Service Forrester Wave: We are proud to announce that Forrester has named Google a Leader in The Forrester Wave™: External Threat Intelligence Service Providers, Q3 2026. Read more.
Wiz named a Leader in the Proactive Security Platforms Forrester Wave: Forrester’s Proactive Security Platforms evaluation for Q3 2026 rated Wiz with top scores across eight areas, reflecting our commitment to securing the AI era. Read more.
Strengthen your CI/CD pipeline with new Secure Source Manager capabilities: To help you better address software supply chain threats, our Secure Source Manager lets you manage your source and CI/CD systems with unified authentication and authorization mechanisms. Read more.
Building an AI detection engine that understands agent intent: Analyzing model input and output logs in an AI-native detection pipeline to understand and uncover malicious AI agent behavior. Read more.
Using AI to discover and fix high-priority exposures across public services and critical infrastructure: New initiative partners with under-resourced organizations to uncover, remediate exploitable risk at scale. Read more.

Please visit the Google Cloud blog for more security stories published this month.

aside_block: <ListValue: [StructValue([('title', 'Join the Google Cloud CISO Community'), ('body', <wagtail.rich_text.RichText object at 0x7fc43cc9db90>), ('btn_text', 'Learn more'), ('href', 'https://rsvp.withgoogle.com/events/google-cloud-ciso-community-interest-form-2026?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q1-global-GCP30328-physicalevent-er-dgcsm-parent-CISO-community-2025&utm_content=cisop_&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

Threat Intelligence news

ShinyHunters renewed mass exploitation campaign targeting Oracle PeopleSoft: Mandiant and Google Threat Intelligence Group (GTIG) have identified renewed mass exploitation of CVE-2026-35273 by UNC6240 (ShinyHunters), along with expanded global targeting across multiple sectors. Read more.
Proactively defend by hardening code pipelines and CI/CD infrastructure: Check out our actionable blueprint for software and platform architects designed to safeguard the software supply chain against threat vectors that are actively being exploited, third-party risks, and architectural vulnerabilities throughout the entire software development lifecycle. Read more.
Infostealer incursion: How stolen credentials breach cloud, code, and AI environments: Wiz Research analyzes NordStellar data to map the credentials targeted by infostealer families and assess their potential impact across cloud, code, and AI environments. Read more.

Please visit the Google Cloud blog for more threat intelligence stories published this month.

Now hear this: Podcasts from Google Cloud

Cloud Security Podcast: Patching browsers with AI, agents, Rust, and your tabs: Jasika Bawa and Doug Turner of Chrome Security explore how Google Chrome now uses AI agents to autonomously identify and patch security vulnerabilities at an unprecedented scale, significantly accelerating the browser's update cadence. Listen here.
Cloud Security Podcast: All about Project Atlas, Wiz's AI vulnerability research: Nir Orfeld, head of vulnerability research, Wiz, discusses how his team uses multi-agent AI systems for discovering high-impact zero-day vulnerabilities in cloud infrastructure. Listen here.
Cloud Security Podcast: How Google eliminates classes of vulnerabilities at scale: How do you build the foundations for a secure Google-scale enterprise that stays secure even if an AI is writing the code and nobody has time to review it? Christoph Kern, principal security engineer, Google, explores what secure-by-design really means in the AI era. Listen here.

To have our Cloud CISO Perspectives post delivered twice a month to your inbox, sign up for our newsletter. We’ll be back in a few weeks with more security-related updates from Google Cloud.

Empower your agents with the Google Cloud CLI remote MCP server

Wed, 30 Sep 2026 16:00:00 +0000

Today, we’re expanding our ecosystem of managed remote MCP servers by introducing the Google Cloud CLI remote MCP server in preview.

Powered by the popular gcloud and bq (BigQuery) command-line tools, this new server gives AI agents immediate, broad access to command-line operations for managing Google Cloud infrastructure and working with advanced BigQuery workflows securely and seamlessly.

Why CLI matters for AI agents

Agents are increasingly performing complex cloud operations, but standardizing how they interact with backend systems remains a challenge. The Google Cloud CLI remote MCP server bridges this gap by packaging the versatility of hundreds of gcloud and bq commands into one single MCP server. This results in two strong benefits for the agent:

Higher-level abstractions: CLI commands package complex multi-step workflows, validation checks, and high-level operations into unified commands rather than requiring multi-step API orchestration.
Leverages model training: LLMs are heavily pre-trained on public command-line documentation, syntaxes, and usage examples, making CLI invocation intuitive and highly accurate for models.

The benefits of putting CLI behind remote MCP

Managing cloud infrastructure with AI agents traditionally requires installing and maintaining Google Cloud CLI binaries inside agent execution environments. The Cloud CLI remote MCP server bridges CLI capabilities with MCP benefits by providing an isolated execution sandbox on Google Cloud infrastructure. This solves key infrastructure challenges:

Simplified dependency and runtime management: For teams building custom agents, maintaining local CLI versions and dependencies across dev, test, and production environments creates operational overhead. Remote MCP eliminates local installations and runtime maintenance.
Access for web-based agent endpoints: Web-hosted agent platforms and web interfaces (such as Gemini Enterprise and other hosted enterprise agent platforms) run in environments where users cannot control or install local packages. Remote MCP enables secure, managed access to Google Cloud CLI operations directly from these surfaces.

Enterprise-grade security and governance

Connecting an AI agent to your infrastructure requires strict, enterprise-ready safeguards. This remote server leverages Google Cloud's standard identity and governance frameworks to keep your environments secure:

Zero ambient credentials: The server isolates execution in a network-restricted proxy boundary with no ambient credentials. Authentication and authorization are handled through Agent Identity, OAuth 2.0, and Identity and Access Management (IAM).
Strict policy enforcement: Every command executed through the remote MCP server is run with the permissions of the authenticated caller identity. Both standard IAM permissions and organization policy service constraints are strictly enforced against downstream target resources.
Advanced protection with Model Armor: To minimize the risks associated with AI tool calling, the Cloud CLI remote MCP server integrates with Model Armor. You can proactively screen LLM prompts and responses to protect against risks like prompt injection and malicious inputs.
Cloud audit logging: The Cloud CLI remote MCP server can be configured to log every tool invocation to Audit Logs (Data Access logs under cloudcli.googleapis.com/mcp). Security teams can gain full visibility into caller identities, OAuth clients, and IAM authorization decisions (mcp.googleapis.com/tools.call) without exposing sensitive command payloads or personally identifiable information (PII).

Connecting to the Google Cloud CLI Remote MCP Server

Integrating cloud management into your agents no longer requires packaging Google Cloud CLI binaries, managing local execution runtimes, or maintaining dependencies inside agent container images. Because the Google Cloud CLI remote MCP server implements the standard Model Context Protocol, any MCP-compatible agent platform or orchestration runtime can connect immediately via standard configuration:

code_block: <ListValue: [StructValue([('code', '{\r\n "mcpServers": {\r\n "google-cloud-cli": {\r\n "uri": "https://cloudcli.googleapis.com/mcp",\r\n ...\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fc43cc9fd90>)])]>

Your agent immediately gains access to execute gcloud and bq commands in a secure, network-isolated cloud sandbox.

Authentication is handled via keyless Agent Identity for hosted Google Cloud platforms, or standard OAuth 2.0 for external runtimes. For authentication options, see the MCP Authentication Guide.

Bringing infrastructure management to agents

The Cloud CLI remote MCP server exposes two powerful tools, run_gcloud_command and run_bq_command, giving your AI agents broad, immediate access to Google Cloud operations through natural language.

Managing cloud infrastructure with run_gcloud_command

With run_gcloud_command, agents can execute the full breadth of gcloud operations to manage, diagnose, and secure your Google Cloud environment. An example follows:

Observability and incident diagnostics: An agent streamlines incident diagnostics by automating command execution and reducing context-switching across tools.

Extending BigQuery operations with the run_bq_command tool

While the BigQuery MCP server already helps organizations analyze and explore data using AI agents, with the introduction of run_bq_command, agents can now tackle advanced BigQuery tasks such as resource allocation, job monitoring, and task scheduling by unlocking the full scope of bq CLI functionality. Key capabilities include:

Automating scheduled queries: An agent utilizes BigQuery Data Transfer Service configurations to schedule queries automatically.
Job and resource management: Gain deep insight into query execution details, including processed data volume, slot usage, and execution plans, as well as managing reservations.
Access and permissions control: Data administrators and owners can inspect and update table permissions directly through the agent.

Pricing and availability

The Google Cloud CLI MCP server is available today in public preview. There is no additional charge to use the MCP server itself. You pay only for the GCP resources you create and any applicable data transfer costs.

To get started, enable the Cloud CLI Execution API (`cloudcli.googleapis.com`) in your Google Cloud project, grant the required MCP Tool User (`roles/mcp.toolUser`) IAM role to your agent or user identity, and configure your MCP client to connect to `cloudcli.googleapis.com/mcp`.

Cloud Blog

Introducing Google Cloud’s U4 compute: Enabling ultra-low latency trading

Powered by Google Cloud-native infrastructure

Storage and placement for trading workloads

Getting started with the ULL Solution

Announcing MCP Toolbox Java SDK v1.0: Agentic data access for the enterprise

MCP: The universal interface

What's new in Java SDK v1.0: Built for production workloads

Get started with the Java SDK v1.0

Real-world example: The autonomous transit concierge

The foundation: AlloyDB schema with native embeddings

Mapping intents to SQL: The tools.yaml

Stateful agent architecture in Spring Boot

Connecting the dots: Listing, invoking, and executing tools in Java v1.0

Secure by default: authentication and deployment

Application Default Credentials (ADC) & safety

Deploying the fleet to Cloud Run

Get started today

Step 1: Add the Dependency

Step 2: Explore Resources & Demos

Gradle implementation

Automatic version tracking

Managed Apache Iceberg at scale: How Spanner powers Lakehouse runtime catalog

Challenges a managed catalog needs to solve in the Lakehouse

Lakehouse runtime catalog

What powers the Lakehouse runtime catalog?

Combine analytical and operational workloads

Modernize to the borderless Lakehouse

Networking for AI inference model serving - GKE only and for all other backends

The entry point

Common services in the designs

Design pattern serving on GKE only

The traffic flow GKE example

Design pattern serving on all backends

All-backends traffic flow example

What's next

Where mission meets moonshot: Join us at the Google Public Sector Summit 2026

Opening Keynote: Where Mission Meets Moonshot

General Session: Cloud Talks

Breakouts: Panel Discussions and Birds of a Feather

Demos, Lightning Talks and Labs

Closing Session: What’s Your Moonshot?

Register for the Google Public Sector Summit

AlloyDB: A unified database engine for hybrid search

The problem of the multi-step workflow

Simplifying hybrid search architectures with AlloyDB

1. The single source of truth

2. Database-native orchestration

The result: Performance and operational simplicity

Enhancing FTS performance: The RUM extension

Introducing the RUM extension for low-latency FTS

Measurable gains and integration

Introducing BM25 Index: The modern ranking standard

External search: Extending versatility with foreign data wrappers

A unified architecture for AI-powered search

Watch it in action

Getting started

Introducing Google Cloud Modernize, transforming for (and with) AI

Agentic infrastructure assessment

Platform modernization

Cloud elasticity for VMware environments

Automated container transitions to GKE

Application modernization with Modernization Hub

.NET and Java modernization

Mainframe modernization

A proven track record and partner ecosystem

Accelerate your transformation now

AI21 achieves an 83% reduction in time-to-start for AI workloads with AI Hypercomputer

The gridlock of high-utilization clusters

Choosing the right scheduler

Closing the loop with open source

Same fleet, less friction

Announcing Spanner queues: Transactional messaging for agentic workloads and beyond

Key capabilities for agentic architectures

Why Spanner queues are essential for autonomous agents

Beyond agentic workflows

Under the hood: Transactional mechanics of Spanner queues

1. Defining a queue and enqueuing atomically

2. Temporal scheduling and atomic cancellation

3. Streaming consumption, lease renewal, and atomic acknowledgment

Mapping intents to SQL: The `tools.yaml`

Example 1: Pod-level boost with fixed steady-state (`updateMode: "Off"`)