Inside Google’s Database Infrastructure for the AI Era

What It Covers

Sailesh Krishnamurti, VP of Engineering at Google Cloud, traces 50 years of database evolution from exact-result relational systems to AI-era infrastructure. He covers Spanner's global scale architecture, Spanner Omni's on-premises deployment, native graph algorithms for fraud detection, AlloyDB's SCAN vector search, and securing agent access to production databases via Parameterized Secure Views.

Key Questions Answered

• •Spanner's multi-model architecture: Spanner now supports relational, graph, full-text, and vector search within a single system, eliminating ETL pipelines between specialized databases. Teams running fraud detection can overlay a property graph on existing relational tables using a single DDL command — no data migration required — then run PageRank-style algorithms natively to identify central nodes in suspicious transaction clusters in real time.
• •Spanner Omni's single-binary deployment: Google collapsed Spanner's many internal microservices into one downloadable binary that runs on a laptop, on-premises hardware, or rival clouds. The core engineering challenge was replicating TrueTime semantics outside Google's atomic-clock infrastructure. Software TrueTime approximates 2012-era Google data center time accuracy, which Krishnamurti considers sufficient for most regulated-industry workloads requiring hybrid or multi-cloud continuity.
• •Filtered vector search over pure vector indexes: AlloyDB's SCAN algorithm delivers 6x faster vector queries and 4x lower memory usage than HNSW-based pgvector. More critically, its adaptive filtered vector search probes both vector and relational indexes simultaneously, dynamically selecting probe order based on selectivity. Teams building catalog search with price filters should avoid standalone vector databases, which force application-layer stitching with no optimizer awareness across index types.
• •Parameterized Secure Views for agent database access: Connecting LLMs to production databases requires moving row-level authorization out of scattered application WHERE clauses and into DDL-defined Parameterized Secure Views. The agent service principal receives access only to these views, never underlying tables. The authenticated user's credential binds as a side-channel parameter at query time, meaning even a prompt-injected or malicious SQL query cannot escape the per-user data boundary.
• •Schema context matters more than schema structure for agentic systems: LLMs generating SQL against operational databases need metadata beyond column names and types. Implicit business rules — such as a null shipping address meaning it matches the billing address, or whether a city column stores full names versus three-letter airport codes — must be explicitly captured. Teams should prioritize building structured context layers around existing schemas before redesigning schemas for AI compatibility.
• •Evals are the core discipline for nondeterministic systems: As databases shift from returning exact results to ranking relevant results, and as agents generate unpredictable queries, teams need objective measurement frameworks to assess output quality continuously. Krishnamurti recommends designating specific engineering efforts where hitting AI-related bottlenecks triggers fixing the bottleneck rather than reverting to deterministic approaches, accepting longer delivery timelines in exchange for genuine capability advancement.