Cockroach Labs Bets the Database Fleet Is the Unit That Matters Now

One group inside Cockroach Labs ran 13 databases in March. By July, the same group ran 392. Nobody filed a ticket for any of them. Nobody sized them in advance either. Cockroach had rolled out an internal platform for building apps with agents, people started shipping, and every app brought a database with it.

Cockroach Continuum goes after exactly that kind of sprawl. Continuum treats the entire database fleet as a single system. You manage the fleet. You pay for the fleet. No single cluster stands on its own anymore.

Continuum is the right idea, and on one point, I’d go further than Cockroach does. Database sprawl didn’t start with agents. Sprawl started a decade ago, when teams began giving every service its own database. Agents are speeding up something that was already well underway. So the money argument works on its own. Cockroach doesn’t need the agent forecasts to be right.

Where pooled capacity pays off

Thousands of databases share one pool of hardware. Cockroach bills for the processing time each database consumes and the data it stores.

What Continuum saves you depends entirely on the shape of your fleet. Run hundreds of small databases, each one sized for a peak that shows up a few hours a week. You’ve been paying for idle hardware for years. Pooling pays off there. Run a dozen large clusters at steady load, and you’re already efficient. Pooling won’t do much for you.

So the early adopters are companies whose traffic swings by the hour. Areas like gaming, betting, and fintech are sitting at the front of that line.

Why Cockroach wrote its own storage layer

Plenum is the storage layer under Continuum. Storage and compute now scale separately, and you pay for what you store.

Analytics vendors have been separating storage from compute for years. Doing it under a transactional database is much harder. CockroachDB sells correctness. Every transaction comes out right, even when a machine or a whole region fails. Keeping that promise means knowing for certain that a write reached disk before the application is told the transaction committed. A rented storage service makes that call for you. It determines when your data is safe, how long a read takes, and what happens when the underlying hardware fails. Cockroach would be promising correctness on top of somebody else’s rules.

So Cockroach wrote its own storage layer. Something like Plenum is years of work, not a quarter. Every other piece of Continuum sits on top of it.

Agentic operations with a human still in charge

Cockroach also built an agentic operations layer and named it Aegis. Aegis watches every cluster in the fleet, spots problems, and tells a database administrator what to do about them. At launch, it changes nothing on its own. A person approves every action.

Keeping a person in the loop is a requirement at this stage. Nobody should hand a production database fleet to software that acts on its own yet. Maybe never. But every call a DBA makes on a recommendation also tells Cockroach whether Aegis was right.

I want a little more detail on that review step itself. There’s a difference between just a recommendation and a completely confident one. On a dashboard, the two look identical, so tiering by confidence is essential once AI is doing the recommending.

Managing one fleet takes a smaller team

Most developers aren’t provisioning databases today. They wait on somebody else’s capacity plan. That plan comes from the platform team, where a small group of specialists owns every system in the building. Continuum takes the wait away.

Running one fleet also changes who a company needs to hire. One operating model across the whole fleet means nobody staffs a specialist per system. The same people can run a much bigger fleet. The staffing savings will beat the hardware savings at plenty of companies.

Continuum changes who Cockroach gets to sell to

For a decade, Cockroach sold one thing, and sold it extremely well. CockroachDB stays up when the infrastructure underneath it falls over. And while that’s a great engineering feat, it’s also a ceiling. The buyer is the team picking a database for one application. Continuum adds one management layer over every database a company runs and charges based on consumption. One application team can’t sign off on a purchase that size. Cockroach is talking to whoever owns the database budget now.

Near-term, I’m viewing Continuum as a retention-and-expansion play more than a net-new share grab. Net new share means convincing somebody to migrate off what they already run. Price alone can’t do it. But Continuum gives Cockroach a reason to walk back into an account it already has and ask about the other databases.

Sharing hardware can be tricky, and noisy neighbors aren’t uncommon in the database world, even with improved isolation techniques. One workload spikes, and the database next to it slows down. Companies running payments or trading buy predictability before they buy savings. Cockroach has run shared infrastructure under its serverless product for five years, so isolation isn’t new ground for the team. I’d still like to hear how it holds up across potentially thousands of databases.

Pooled capacity also runs into compliance. A bank or a hospital system has rules about whose hardware its data sits on. Cockroach needs an answer there before Continuum gets into regulated accounts at all.

Cockroach spent a decade learning how these systems behave under stress. The company spent five more years running many customers’ databases safely on shared hardware. Then the sprawl problem showed up on its own infrastructure. Continuum came out of fixing it. A buyer looking at Continuum is buying engineering that’s already been running for years.

Mike Leone
VP & Principal Analyst |  + posts

Mike Leone is a principal analyst at Moor Insights & Strategy covering data platforms and analytics, data infrastructure and storage, and data governance and enterprise data strategy. He brings 15 years of analyst experience from his work at Enterprise Strategy Group, where he rose to practice director for data management, analytics, and AI. Mike's work is grounded in a strong technical and strategic foundation, including early roles in software and hardware engineering.

Recent Posts