CockroachDB Continuum – Engineering Detail Cockroach Labs announced Cockroach Continuum, a database built to run agentic AI workloads by virtualizing thousands of CockroachDB clusters on a shared pool of private physical host clusters backed by disaggregated storage. The company said its internal Mica system, which runs Claude and CockroachDB, produced more than 3,000 employee-built applications within its first few months, most backed by CockroachDB. Continuum's elasticity provisions quickly, scales up and down in seconds, incurs no compute charge when idle, and consolidates many isolated database workloads onto shared infrastructure to lower per-workload cost. In the past year, generative AI and agentic workflows have dramatically reshaped technology-dependent industries. At Cockroach Labs, we built Mica, an internal system running Claude and CockroachDB https://www.cockroachlabs.com/product/overview/ , that lets anyone in the company build and share applications using corporate data. Within its first few months, employees built more than 3,000 applications, most backed by CockroachDB. That’s a remarkable number of apps for a company of our size. That experience showed what Cockroach Continuum is built to solve: Agentic workloads https://www.cockroachlabs.com/blog/agentic-ai-database-architecture/ are numerous, exploratory, and bursty. Like traditional enterprise workloads, they still require scale, consistency, and reliability; agents operating on incorrect or unavailable data make bad decisions at scale. CockroachDB already provides the scale, consistency, and reliability those workloads require. But agentic workloads turn a database-scaling problem into an estate-management problem: Teams need to provision, operate, and retire large numbers of isolated database workloads without multiplying physical infrastructure or operator burden. That requires a transactional substrate that is simpler and more affordable to run, and able to provision quickly, start instantly, and scale with demand. What is Cockroach Continuum? The result is Continuum, a database that runs your agents and is run by our agents. It is called Continuum because it is fluid, adjusting its shape as the workload changes: scaling compute up and down, adding or removing nodes, and moving data to where it’s needed. Elasticity is Continuum’s key design principle: Infrastructure provisions quickly, scales up and down in seconds, incurs no compute charge when idle, and packs workloads densely enough to change the economics. Because CockroachDB owns the full stack, that elasticity extends from our SQL layer to our Storage layer and everything in between. The result is the same CockroachDB clusters you already run, but now virtualized by the thousands on a shared pool of private physical host clusters and backed by disaggregated storage. Architecturally, this makes it possible to give a workload its own full CockroachDB cluster while consolidating many clusters on shared infrastructure: a database-per-tenant https://www.cockroachlabs.com/blog/how-we-built-cockroachdb-serverless/ model without a dedicated physical fleet for every tenant. The following sections explain how Storage, KV, and SQL became elastic, then introduce the operating agents that help manage Continuum efficiently. The Case for Consolidation In 1900 every factory ran its own dynamo. A dynamo is a steam-driven electrical generator that lived in the basement, was sized for the factory's peak demand, and kept running by a crew shoveling coal. A generation later no factory ran a dynamo. Central power plants won because pooling variable demand meant one shared plant absorbed the peaks. Compute went through the same shift via virtualization. Databases are next. Consolidating on Continuum creates three critical benefits: 1. Pooling variable workloads improves hardware utilization and makes fleet demand more predictable and manageable. 2. Operations teams manage less physical infrastructure. 3. As more workloads share the estate, the per-workload cost falls. Taken together, these capabilities make database estate consolidation practical: Many isolated workloads can share physical infrastructure without requiring teams to manage a separate physical cluster for each workload. Let’s explore how Continuum delivers that model across storage, KV, and SQL. CockroachDB Architecture Overview Continuum makes CockroachDB’s existing SQL, KV, and storage layers elastic while preserving the distributed architecture that provides scale, resilience, correctness, and locality. The SQL layer parses, optimizes, and executes SQL and provides SQL constructs like indexes, foreign keys, and multi-region primitives https://docs.cockroachlabs.com/docs/stable/multiregion-overview . When SQL needs data, it calls the KV layer Key-Value . The KV layer simulates a large key-value map stored on a single node. In reality, the data, including the key space, is physically spread across multiple nodes and regions for resiliency and scale. The KV routing and range metadata knits it back together to complete the illusion. When KV needs to store data durably, it writes to Pebble, the storage tier, which implements a Log Structured Merge Tree https://docs.cockroachlabs.com/docs/stable/architecture/storage-layer LSM . Think of an LSM as a hierarchy of immutable data. Finally, Pebble https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/ writes data to storage devices like EBS. Data is divided into ranges. A range is a continuous "range" of data, ordered by key. Ranges are replicated to multiple nodes for scale, resilience, and parallelism. Each range is a Raft consensus https://www.cockroachlabs.com/glossary/distributed-db/raft-consensus-protocol/ group, and one node is the leader, elected through Raft, able to write and read the latest data. Ranges are the primitive out of which scale, resilience, correctness, and locality are built. Cockroach Plenum: Disaggregated Storage for Elastic Infrastructure Plenum is CockroachDB’s disaggregated storage layer. It decouples durable storage from KV compute nodes so both layers can scale independently, rather than requiring storage capacity and KV nodes to grow or shrink together. Prior to Continuum, storage and compute were bound together in the KV layer. Each KV node had a network block device eg EBS and replicated data to other KV nodes, which wrote it to their own block storage. Every time a new KV node was added, ranges were shipped to it. Every time a KV node was removed, ranges were shipped away from it. This limited elasticity, because Storage and KV evolved together, slowly. You also had to provision storage for what you might need; the surplus sits idle. We built Plenum to separate Storage and Compute. Plenum is a multi-tenant disaggregated storage layer that replaces our usage of block storage. Think of it as a large apartment building: shared physical infrastructure, such as a single elevator, that hosts many tenants. Now, when CockroachDB writes durably to disk, Pebble our purpose built storage engine writes to a file interface that Plenum implements, transparently directing writes to a disaggregated object store shared across CockroachDB instances. Because LSM-tree data is nearly always immutable, it is safe to share, so Plenum can store one canonical set of files rather than a separate physical copy per KV node. When a new KV node is created, it receives metadata links to the data it needs and can begin serving SQL requests immediately, without copying files locally. KV sees these links as hardlinks: pointers in Plenum that resolve to a shared object ID, while the bytes are fetched from Plenum blob servers on demand. The result is rapid cluster and node creation. This design relies on a new concept that we call the Range Shared LSM. Sharing data between KV nodes works provided the data behind the hard links is bit-identical data. Raft provides that guarantee, and the range is the natural unit at which to share identical data. Plenum consists of blob servers that store the actual objects/data. These are backed by fast, instance local NVMe SSDs spread across many AZs in a region and soon, across regions . Each object is replicated across AZs so that no data is lost when a single-zone fails, with S3 used as a durability backstop and for fast inter-AZ transit. The blob servers are managed by a stateless controller. Object metadata lives in a small CockroachDB cluster, turtles all the way down. A stateless controller service manages namespace, object placement, locking, and authorization. The controller decides where data lives, it does not touch the data itself. By severing Storage from KV compute the latter becomes nearly stateless and fully elastic. KV nodes spin up and down quickly and can focus on providing a unified and correct KV abstraction to the SQL tier at a dramatically reduced cost. Storage is elastic too: Customers pay for data under management rather than reserved capacity, because Plenum can host data for thousands of CockroachDB clusters in one shared pool. That aggregates costs across the fleet and packages data efficiently on a smaller set of better-utilized servers. Disaggregation and elasticity unlock a roadmap that will include fast database branching and data snapshots, BACKUP offload, compaction offload, SQL stats offload, and more. Offloads are exciting because they remove work from the foreground traffic hotpath. This leaves critical CPU for the work that requires the lowest latency. KV Elasticity for Multi-Tenant Virtual Clusters The KV tier gains two forms of elasticity: 1. Because Plenum durably persists the data, KV nodes become nearly stateless and can scale with transaction volume. 2. Tenant identity is decoupled from the physical node, allowing one KV node to host many Virtual Clusters without dedicating hardware to any one of them. KV nodes still present a unified abstraction of a single key space living on a single node through the use of serializable transactions https://docs.cockroachlabs.com/docs/stable/architecture/transaction-layer and Raft. KV nodes can be used in a traditional manner where one workload runs on a physical Continuum deployment. In this case there is one tenant for the customer, and one tenant called the “system tenant” for cluster metadata and operations. Depending on your needs, this may be the correct choice. KV nodes will still scale up and down as that single workload demands. By packing multiple Virtual Clusters each a fully functional CockroachDB cluster on the same physical infrastructure, hardware utilization improves. KV multi-tenancy is enabled by partitioning the key space by tenant, or Virtual Cluster, and then making each KV node multi-tenant aware. Each KV node serves multiple Virtual Clusters since tenants are decoupled from hardware. Every key is now of the "pretty printed" form: "/