“We’re not Google.” For years, that was the reflexive objection Spencer Kimball heard from nearly every prospect he pitched a distributed database to. I already covered the cost-tax framing and the agent-layer architecture from Kimball’s RoachFest London 2026 keynote in my main recap — a few days after the keynote I caught up with him again on the conference floor at 22 Bishopsgate, and what came out of that conversation is a bigger, longer story than one slide can carry: how an argument he spent over a decade making alone became the default assumption in the room.
Eleven Years of “We’re Not Google”
Cockroach Labs was founded in 2015, and Kimball told me that for years afterward he felt like he was “crying out in the wilderness” trying to convince companies that distributed databases mattered. His pedigree, engineering roots at Google, should have made the pitch easier. It did the opposite. Prospects heard “Google-scale infrastructure” and concluded the problem did not apply to them — the objection was never really about whether distributed databases worked, it was a belief that Google-sized problems belonged to Google-sized companies. “We’re not Google” was a polite way of saying: come back when we’re bigger.
That objection, Kimball told me, has almost completely disappeared.
From Mission-Critical Exception to Strict Requirement
What replaced it is not just acceptance — it is a change in scope. Kimball’s framing was specific: distributed databases are moving from something reserved for mission-critical systems that had already scaled to a strict requirement across a much wider fraction of every company’s data estate. The old pattern was picking the one database that absolutely could not go down — the payments ledger, the core banking system — and building elaborate, custom resilience around just that one system while everything else ran on conventional infrastructure. The new pattern treats that same bar as the baseline for a much larger slice of what a company runs, rather than the exception carved out for the crown jewel.
That is also why Kimball was adamant this is no longer a hyperscaler-only conversation. Distributed SQL used to be something you adopted once you already operated at Google or Amazon scale. What he described at RoachFest is demand pulling forward from companies nowhere near that scale, because the requirement is not really about size anymore — it is about how much of the business now depends on data staying correct and available everywhere, all the time.
The Complexity-vs-Cost Calculation Is Changing
Some of the on-floor signage at 22 Bishopsgate put the shift in one sentence: every company shopping for distributed SQL has been weighing two things, complexity and cost, and that calculation is changing. It connects directly to the cost tax framing from Kimball’s keynote — license fees are the visible tip of the iceberg, with compute, networking, storage, migration cost, and human capital sitting underneath, invisible to any vendor’s pricing page.
The practical effect for anyone evaluating a database in 2026 is a different kind of procurement conversation. Comparing license line items across vendors was always incomplete, but it used to be defensible, because the operational tax of running a distributed system yourself — sharding logic, multi-region replication, disaster-recovery rehearsals — was assumed to be a fixed cost regardless of which database you picked. Kimball’s point is that it is not fixed: a database engineered for distribution from the start collapses a meaningful share of that hidden cost, which means the complexity side of the old complexity-versus-cost tradeoff is shrinking at the same time the cost side is being priced more honestly. That is a genuinely different negotiation than the one procurement teams were having five years ago.
What “Agent-Native” Actually Means
The architecture I covered in the recap — an agent layer sitting on virtual databases, sitting on physical clusters, sitting on a shared storage foundation — is easy to nod along to as a diagram. What it means in practice is more specific: each AI agent gets what functions as its own elastic database, not a namespace carved out of a shared table, isolated enough that a runaway agent cannot contend for the same rows or exhaust the same connection pool as its neighbors, but backed by the same distributed, consistent, horizontally-scalable foundation as every other tenant on the cluster.
That is a meaningfully different bet than the default most AI stacks are making today, which is to bolt a vector store or a memory layer onto an existing application database and hope the consistency boundary holds. A bolted-on memory store has no natural isolation: one agent’s misbehaving query can starve every other workload sharing that table, with no clean blast-radius boundary when something goes wrong. A virtual-database-per-agent model gives you that boundary by design, at the cost of needing a control plane that can provision and reclaim virtual databases as fast as agents themselves spin up and disappear. The same customer roster I listed in the recap — enterprises already running mission-critical workloads on CockroachDB — is the reason the agent bet reads as credible rather than speculative: it is infrastructure already proven at a scale most agent platforms have not had to operate at yet.
Why This Matters Beyond CockroachDB
The useful takeaway for anyone evaluating a database platform this year is not “buy CockroachDB” — it is that the evaluation question itself has changed. The old question was “can this handle our current mission-critical workload.” The new one, whether or not a team has consciously asked it yet, is “can this hold the same consistency guarantees for every AI agent we deploy over the next two years, without a rearchitecture every time an agent needs a new store.” Kimball’s eleven years of “we’re not Google” ended not because companies got bigger, but because the definition of what needs database-grade reliability got wider. Betting on a database that treats that as the default rather than the exception is the actual decision hiding underneath the license-fee line item.
Related Reading
- RoachFest London 2026: Distributed SQL Meets AI Resilience
- Form3 and Kevin Holditch: Surviving Cloud Outages with CockroachDB
- Major Tim Peake at RoachFest London: What Space Missions Teach Engineers
- Inside Cockroach Labs’ AI Playbook: The Database Reckoning
- Human-in-the-Loop AI Database Migrations
About the Author
I am Luca Berton, AI and Cloud Advisor. I work at the intersection of distributed systems, platform engineering, and enterprise AI deployments. Book a consultation.
