The End of Deterministic Data: Why Your Database Strategy Needs an Upgrade

The core idea here is that the database industry is moving from a focus on deterministic exactness to probabilistic relevance. For fifty years, database design centered on one goal: return the exact result every time without losing data. AI is changing this by forcing the integration of structured and unstructured data, where correctness is now secondary to relevance. This transition has a hidden consequence: engineers who rely on deterministic systems will be replaced by those who can manage uncertainty. The advantage now belongs to those who build evaluations to measure the quality of non-deterministic outcomes rather than just debugging binary failures. This is a guide for architects and engineering leaders who need to move from building rigid pipes to managing fluid, agentic workflows.

Key Insights & Analysis

The Shift from Exact to Relevant

For five decades, the database contract was simple: specify what you want, and the system provides an exact result. Sailesh Krishnamurthy, VP of Engineering at Google, notes that AI is changing this contract. We are moving toward information retrieval, where relevance and ranking take precedence over exact matches.

It is no longer just enough to not lose your data and produce exact results. But when you are asking to combine structured and unstructured data, you need to provide the best results. And so now you have a mindset shift producing exact results to starting to produce inexact results.

-- Sailesh Krishnamurthy

This shift reveals a non-obvious dynamic: the database is becoming a search engine. Most teams solve this by stitching together separate vector and relational systems at the application level. This creates a hidden cost: the application layer must now handle the logic of deciding whether to probe a vector index or a relational index first. Krishnamurthy argues that the real competitive advantage lies in in-situ processing, using systems like AlloyDB that can adaptively probe multiple indexes on the fly, eliminating the need for manual, error-prone stitching.

The End-to-End Security Paradox

As agents begin writing their own queries, the conventional wisdom of service principles fails. In a three-tier web architecture, the application acts as the gatekeeper, hiding the end-user identity from the database. If you grant an AI agent broad service-level access to your database, you have essentially handed the keys to the kingdom to a non-deterministic actor.

Krishnamurthy points to the end-to-end argument from 1975 to explain why security must move closer to the data. He advocates for Parameterized Secure Views (PSVs). By moving the authorization logic, which was previously scattered across application code, into the database DDL (Data Definition Language), you ensure that no matter how malicious an LLM-generated query becomes, it is physically constrained by the user access rights. This creates a lasting moat: while others scramble to patch agent-induced data leaks, teams that bake security into the data layer itself can safely enable agentic workflows.

Why Hard Infrastructure Creates Lasting Moats

The podcast reveals a systems-level pattern: Google internal operational challenges, like the work of sharding MySQL for ads, forced the creation of revolutionary systems like Spanner. The implication here is that the most durable infrastructure is born from the most painful operational constraints.

I think one year, I think it was sometimes circa 2008-2009 they came to the conclusion that in the time they would take to shard at the world of changed again. And this is a hamster wheel that they had to get off.

-- Sailesh Krishnamurthy

The hard work of building global consistency and atomic time primitives (TrueTime) is exactly what makes Spanner uncopyable. Krishnamurthy notes that while many teams want to modernize everything, the reality of 2025 is a messy, hybrid world. The winning strategy is not to force everything into one cloud, but to use systems that offer the same operational primitives, like a single binary for Spanner Omni, across different environments. This requires the patience to tackle hard infrastructure problems, like software-based time primitives, that most teams prefer to ignore in favor of easier but less durable abstractions.

Key Action Items

• Audit your Agent-to-Data path: Assess where your agents currently connect to production. If they use a broad service account, begin architecting Parameterized Secure Views to bind queries to specific user credentials. (Immediate priority)
• Stop stitching at the application layer: If you are managing vector search and relational queries in separate systems, move toward integrated engines that allow for native, adaptive filtered vector search. (Over the next quarter)
• Implement Evals as a first-class citizen: Stop trying to make AI-generated data models deterministic. Instead, build automated evaluation harnesses to measure the quality of the outcomes. (Immediate investment)
• Embrace the Hard path: When your AI-assisted coding hits a bottleneck, resist the urge to drop down to manual workarounds. Fix the bottleneck in the harness itself. This pays off in 12-18 months by creating a resilient, automated development pipeline.
• Map your Context Store: Identify the implicit knowledge in your database, such as that shipping address and billing address are the same. Document this as metadata or comments now, so it is ready for LLMs to consume later. (Next 6 months)