Google Cloud Introduces AlloyDB Architecture for Agent-Scale Workloads

Google Cloud has announced a new agentic database architecture for AlloyDB designed around a specific enterprise challenge: allowing AI agents to work with live operational data without exposing the production database to unpredictable agent-generated workloads.

The architecture is built around three principles that Google Cloud says are necessary for databases serving autonomous AI agents:

1. Isolation

2. Low latency

3. Elastic scale

Google Cloud argues that existing database architectures typically address one or two of these requirements but struggle to provide all three simultaneously.

The new AlloyDB architecture takes a different approach by separating the production database from an independent pool of ephemeral AlloyDB nodes used by agents.

These agent nodes access dedicated storage segments while retaining access to the PostgreSQL database engine and capabilities such as indexes, vector search, full-text search and spatial search.

The result, according to Google Cloud, is an architecture where agents can access live production data while the transactional production cluster remains physically isolated from agent workloads.

Why Agentic Workloads Change the Database Problem

Traditional database scaling strategies were designed around workloads that could be forecast, provisioned and managed within relatively predictable boundaries.

AI agents introduce a different workload pattern.

An agent may generate database queries dynamically as part of a reasoning process. Multiple agents can operate simultaneously, and demand can change rapidly as agents start and finish tasks.

Google Cloud describes a theoretical scenario in which a burst of agents could require 1,000 database compute nodes within seconds, only for the workload to disappear within a minute.

That creates a difficult infrastructure problem.

Pre-provisioning enough capacity for the maximum possible agent workload can leave resources idle. Sharing production infrastructure with unpredictable agent traffic can instead create resource contention.

Google Cloud argues that agentic database infrastructure therefore needs to separate agent workloads from the production system while still allowing those agents to work with current operational data.

This leads to the three architectural tenets behind the new AlloyDB design.

The Three Tenets of an Agentic Database

1. Isolation

The first requirement is physical separation between agent workloads and the production database.

Google Cloud says agents should be able to read live production data with sub-second freshness without sharing database components with the primary cluster.

The architecture therefore separates the production infrastructure from the infrastructure used by agents.

The distinction is important because Google Cloud argues that quotas alone do not provide sufficient isolation. If two workloads ultimately depend on the same physical resources, they can still experience a shared failure mode when those resources become constrained.

Under AlloyDB's new architecture, agent workloads use an independent pool of nodes and separate Colossus storage segments.

2. Latency

The second requirement is database-level performance.

Google Cloud sets a sub-millisecond baseline for storage I/O in the architecture.

The company argues that agents need more than access to a database copy. Their reasoning loops can depend on repeated database operations, including point lookups, index traversals and search operations.

A design that performs well when data is cached but experiences a major latency increase when data must be retrieved from remote storage can therefore create unpredictable performance.

AlloyDB's architecture instead routes storage reads directly through Colossus, Google's distributed storage system.

3. Scale

The third requirement is rapid and highly elastic compute scaling.

Google Cloud describes an agent workload that can move from zero activity to thousands of database nodes and then return to zero after the tasks finish.

This differs from conventional replica scaling, where new database instances generally need to be provisioned and populated with data before they can serve workloads.

The new AlloyDB architecture uses an ephemeral agent pool designed to provision and release compute as agents require it.

How AlloyDB's Agentic Architecture Works

Google Cloud says the new AlloyDB architecture was engineered across the database, storage, networking and compute layers rather than adding an agent-specific feature to an existing database architecture.

The production cluster remains on dedicated, pre-provisioned infrastructure.

Agents instead connect through the Model Context Protocol (MCP) to an independent pool of AlloyDB nodes.

These nodes are:

• Ephemeral

• MicroVM-based

• Read-only with respect to the production state

• Connected to dedicated Colossus storage segments

• Provisioned in response to agent demand

The architecture allows agents to query production data with sub-second freshness while keeping their compute and storage paths separate from the production cluster.

Google Cloud summarizes the design principle as:

Share the data. Share nothing else.

Isolation Through Dedicated Storage Segments

Storage is central to Google's approach.

AlloyDB's agent nodes do not simply read from the same storage infrastructure serving the production cluster. Instead, Google Cloud says agents are served from separate Colossus storage segments.

This creates a physical separation between the production and agent data paths.

The architecture therefore separates agent activity across three layers:

Compute → Network → Storage

Google Cloud says that at no point along this path can an agent share a database component with the production workload.

The production database remains dedicated to transactional workloads, while agents operate against their own pool of database nodes.

Colossus Provides the Storage Foundation

AlloyDB's architecture is built on Colossus, Google's distributed storage system.

Google Cloud says Colossus underpins several Google services and is designed to operate at very large scale.

The company identifies three properties of Colossus that are particularly important for agentic database workloads.

Direct, Sub-Millisecond I/O

According to Google Cloud, a database node opening a Colossus stream receives a handle describing where the relevant data resides.

Authorization and metadata resolution occur when the stream is created. Subsequent reads can then go directly to the disks containing the required data.

Google Cloud says this enables sub-millisecond latency across the database's data without requiring an intermediary cache tier.

Large Aggregate Throughput

Google Cloud states that Colossus can deliver up to 15 TB/s of aggregate throughput and 20 million queries per second to a single AlloyDB database, without requiring bandwidth to be provisioned for a specific number of concurrent hosts.

These figures are claims made by Google Cloud about the underlying architecture and should not be interpreted as a universal performance guarantee for every AlloyDB workload.

Physical Segment Partitioning

The architecture uses separate Colossus segments for agent workloads.

This is intended to prevent agent I/O from competing directly with production I/O.

As a result, Google Cloud says agent scaling does not require the production storage path to absorb the additional workload.

Jupiter Connects Elastic Compute to Storage

The network layer is another part of the architecture.

Google Cloud uses Jupiter, its high-capacity data center network, to connect compute resources with centralized storage.

The company states that a single Jupiter fabric connects more than 100,000 servers and provides 13 petabits per second of bisection bandwidth.

For AlloyDB's agentic architecture, the purpose is to allow agent nodes to be scheduled across the infrastructure while maintaining access to centralized storage.

As the agent pool expands, the network is intended to provide the bandwidth required for those additional nodes.

MicroVM-Based Agent Compute

At the compute layer, agents connect to the AlloyDB agent pool through MCP.

Each agent node runs a full AlloyDB for PostgreSQL database engine inside a lightweight microVM.

Google Cloud says these instances are isolated from each other and from the dedicated production cluster.

This approach allows the architecture to provision database compute specifically for agent workloads rather than requiring agents to use traditional read replicas.

Rapid Provisioning and Release

Google Cloud says agent nodes can be provisioned in response to requests and automatically stopped when agents complete their work.

The company describes the architecture as capable of scaling from zero to thousands of agent nodes during bursts.

The production cluster remains pre-provisioned and dedicated to the system of record.

Google Cloud also says billing for the agent nodes is based on per-second activity.

The source gives an example of a burst using 1,000 nodes for tens of seconds, stating that billing would cover the resources consumed during that activity rather than requiring those nodes to remain provisioned afterward.

Agents Retain the PostgreSQL Engine

A significant part of Google's argument is that agents should not have to use a simplified data-access layer that removes database capabilities.

The AlloyDB agent nodes retain access to the PostgreSQL engine and its associated capabilities.

Google Cloud specifically identifies:

• Point lookups

• Index traversals

• Vector search

• Full-text search

• Spatial search

• Columnar scans

• Federated queries across the lakehouse

• Relational SQL

This is important for agent reasoning because retrieval can involve multiple types of database operations.

Google Cloud argues that simply exposing object storage or a basic analytical interface can force workloads toward large table scans instead of using the indexes and search capabilities available in a database engine.

Why Google Says Existing Architectures Fall Short

Google Cloud compares the new AlloyDB approach with three broad database architecture patterns.

The company's argument is that each approach makes a structural trade-off involving isolation, latency or scale.

Independent Replicas

Traditional relational databases can scale reads by creating separate replicas that receive replicated data from the primary system.

Google Cloud says this model provides:

• Physical isolation from the primary

• Near-real-time data replication

• Predictable local storage latency

However, it argues that replicas struggle with agent-scale bursts.

A new replica must be provisioned and populated with the required data before it can serve traffic.

Google Cloud says this process can take hours for large datasets, which does not align with workloads that may need thousands of nodes within seconds.

The company also points out that permanently provisioned replicas can remain idle after agent workloads finish.

Disaggregated Shared-Storage Servers

Another architecture separates compute from shared storage servers.

This can allow compute replicas to be added quickly because data does not need to be copied to each new instance.

However, Google Cloud argues that the shared storage layer becomes a potential contention point.

Agent and production workloads can access the same storage infrastructure, creating shared resource consumption.

Adding compute nodes without adding equivalent storage I/O capacity can therefore increase pressure on the storage tier.

Object Storage With Shared Block Servers

A third architecture uses object storage for durable data while placing a block-server layer in front of it.

Google Cloud argues that this can provide low latency for frequently accessed data, but cache misses may fall through to object storage.

The company says those misses can introduce significantly higher latency.

It also argues that shared block servers create an isolation problem because production and agent workloads can compete for the same resources.

Finally, the block-server tier itself can become a scaling constraint if compute expands faster than the available I/O capacity.

Why Direct Object Storage Access Is Not Enough for Agents

Google Cloud also distinguishes between analytical workloads and agent reasoning workloads.

Analytical engines such as Apache Spark can read object storage directly, which can be useful for large-scale analytical processing.

However, Google argues that agent reasoning loops have different requirements.

Agents may need low-latency access to:

• Indexes

• Point lookups

• Vector search

• Full-text search

• Spatial search

If those database capabilities are removed and the agent must instead scan tables directly from object storage, Google says retrieval latency can increase significantly.

The company's position is that agentic workloads therefore need the full database engine rather than only access to the underlying data.

Google's Comparison Test of a Commercial Database Service

Google Cloud says it evaluated a commercially available service based on an object-storage architecture with shared block servers.

The test used concurrent index lookups against a dataset larger than available DRAM.

Researchers started with one reader instance and progressively added up to eight read replicas.

According to Google Cloud, adding replicas produced less than a 2x throughput increase, with performance peaking at four replicas before declining as shared block-server bandwidth became saturated.

The company also reports that primary database throughput fell by more than 75% as replicas were added.

These results are from Google's own benchmark and should be understood in the context of the tested service, workload and configuration. They are not a universal performance measurement for every database using a similar architecture.

AlloyDB's Agentic Benchmark

Google Cloud also describes testing its new AlloyDB architecture with concurrent index lookups against a dataset larger than available DRAM.

The benchmark began with a single agent node and scaled dynamically to 1,000 agent nodes.

Google Cloud reports that throughput increased from 3.9K QPS to 41K QPS when scaling from one to ten nodes.

The company then reports near-linear performance as the system scaled through two additional orders of magnitude to 1,000 nodes.

At 1,000 agent nodes, Google Cloud reports:

• 3 million QPS aggregate throughput

• 8 million+ IOPS in Colossus

• No measurable impact on primary cluster performance

• 773x throughput scaling

Google Cloud also reports a separate benchmark using concurrent full-table scans across 2,100 agent nodes, where aggregate scan throughput exceeded 1 terabit per second.

These are vendor-reported benchmark results. They describe Google's test environment and workload rather than a guaranteed performance level for all AlloyDB deployments.

The Core Architectural Principle: Share Data, Not Infrastructure

The central idea behind the architecture is that agents should be able to access the same live enterprise data without sharing the infrastructure that runs the production system.

That creates a separation between:

Data availability

and

Resource ownership

Agents can see current operational information while their compute, storage segments and database instances remain separate from the production environment.

This is the architectural foundation for Google's claim that organizations can scale agent workloads without exposing the production database to the same resource contention.

Beyond AI Agents: Other Production Data Consumers

Google Cloud says the same architecture can also benefit other workloads that need to read production data.

The company specifically mentions:

• Reporting

• Analytics

• Applications

• BigQuery

• Apache Spark

BigQuery and Spark can read AlloyDB data from Colossus while remaining isolated from the production cluster.

Google Cloud says this enables lakehouse federation, allowing agents to combine live operational data with larger analytical datasets.

The source therefore presents the architecture as broader than an agent-only database feature. It is positioned as a way to separate read-heavy workloads from the system of record while preserving access to current data.

What the New Architecture Changes

The significance of AlloyDB's new architecture is less about adding another interface for AI agents and more about changing where those agents execute their database workloads.

Traditional approaches generally force organizations to choose between:

• Giving agents direct access to production and accepting potential contention

• Creating replicas and accepting provisioning and synchronization overhead

• Moving data into analytical systems and accepting latency or reduced database capabilities

Google Cloud's architecture attempts to remove that choice by separating the compute and storage path used by agents from the production database while retaining the database engine.

The company describes the resulting model as an architecture where production remains dedicated to transactional workloads while agent capacity can expand and contract independently.

What This Means for Enterprise AI Infrastructure

The announcement highlights a broader industry shift toward designing databases around autonomous workloads rather than treating AI agents as another conventional read client.

Agentic applications can generate unpredictable query patterns and bursts of activity. That makes infrastructure isolation increasingly important when those applications interact with systems of record.

For enterprises, the architecture could provide a model for allowing AI systems to reason over current operational data without requiring every agent workload to compete directly with transactional applications.

The three-tenet framework also provides a useful way to evaluate agent-oriented database designs:

Can the workload be isolated?

Can data be retrieved with predictable latency?

Can compute and I/O scale as quickly as agent demand changes?

Google Cloud's answer with AlloyDB is to address all three through coordinated changes to storage, networking and compute rather than relying on a single scaling mechanism.

Preview Availability

Google Cloud says organizations can run agents against production data at scale by joining the preview of AlloyDB PostgreSQL for agents.

The announcement directs users to the AlloyDB documentation and a sign-up process for getting started.

Additional availability details, regional coverage and preview limitations were not provided in the supplied announcement text.

Conclusion

Google Cloud's new AlloyDB agentic database architecture is designed around a simple but demanding requirement: give AI agents access to live enterprise data without allowing unpredictable agent workloads to interfere with production systems.

The architecture combines three principles: physical isolation, sub-millisecond storage I/O and rapid elastic scaling.

Its implementation spans the entire infrastructure stack, from AlloyDB and PostgreSQL to Colossus storage, Jupiter networking and microVM-based compute.

Google Cloud's benchmarks report scaling from one to 1,000 agent nodes with no measurable primary degradation, along with aggregate throughput reaching 3 million QPS and more than 8 million IOPS in Colossus under the tested workload.

The broader architectural proposition is that enterprises should not have to choose between fresh operational data and production safety when deploying AI agents.

Instead, agents can operate against the same enterprise truth while their compute and storage infrastructure remains physically separate.