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, 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 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 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:
Pooling variable workloads improves hardware utilization and makes fleet demand more predictable and manageable.
Operations teams manage less physical infrastructure.
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. 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 (LSM). Think of an LSM as a hierarchy of immutable data. Finally, Pebble 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 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:
Because Plenum durably persists the data, KV nodes become nearly stateless and can scale with transaction volume.
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 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:
"/<tenant-id>/<table-id>/<index-id>/<key>"
and the KV node enforces the tenant, or Virtual Cluster, isolation.
Tenant-awareness doesn't stop at key encoding. Deciding which KV node holds the lease for a given range is called leaseholder placement. Historically leaseholder placement was optimized for physical locality: The system put the leaseholder near the workload and balanced leases evenly across nodes. In a multi-tenant KV layer a single node holding leases for too many ranges from a single noisy tenant will degrade the other tenants on that node. The placement algorithm now factors tenant identity into the decision, spreading a tenant's leaseholders across the physical fleet the same way it spreads data.
Note that multi-tenant KV nodes were introduced a few years ago for CockroachDB Cloud Basic and Standard tiers. Continuum is built on years of design work in addition to the new modules and code added specifically for Continuum.
SQL Elasticity with SQL Pods
SQL elasticity comes from SQL Pods: Each Virtual Cluster can run from zero to N full CockroachDB SQL server processes that scale with demand and can scale to zero when idle.
This model reuses what was built and delivered for CockroachDB Cloud's Basic and Standard tiers. A SQL Pod is bound at startup to a tenant key encoder, SQLCodec, that stamps the tenant ID on every key the SQL layer reads or writes. Each SQL pod is single-tenant for security reasons. Isolation in separate-process mode is enforced at the KV boundary. Each SQL pod uses mutual TLS (mTLS) when communicating with a KV pod, and its client certificate carries its tenant ID. The KV request handler rejects any operation touching keys outside that tenant's prefix.
Because each SQL pod runs the full SQL server process, users get the full power of CockroachDB and Postgres compatible SQL. A SQL pod can run as a separate process talking to the KV layer through RPC, or in shared-process mode inside the KV node's process through direct in-memory calls. In separate-process mode, which is the topology used by CockroachDB Cloud Basic and Standard tiers, SQL Pods are packed on shared host clusters that also host KV Pods.
SQL pods are the unit of elasticity in the SQL layer. They are fractional consumers of compute, scale with demand, and can scale to zero while exposing the full breadth of CockroachDB functionality.
No Noisy Neighbors: Admission Control and Resource Manager
Continuum prevents noisy neighbors with Admission Control and its Resource Manager: Together, they protect shared infrastructure from runaway work, prioritize foreground queries, and ensure that one Virtual Cluster can’t starve another. This provides resource isolation at the database layer, even when multiple Virtual Clusters share the same physical hosts.
Admission control manages different shapes of demand through Slots and Tokens. First, to manage concurrency, Admission Control provides Slots.
The database maintains an elastic pool of Slots that represent a healthy amount of concurrency.
When work arrives it requests a Slot.
If it receives one it immediately proceeds.
If there are no free Slots, it waits for the next one.
When work is finished, the freed slot is handed directly to the next waiter.
This simple mechanism avoids a centralized scheduler and delivers a performance boost by handing slots directly to the next job. Slots limit how many KV operations run simultaneously, protecting the Go scheduler, and ultimately, the CPU from overload.
The other Admission Control system is Tokens. Tokens model burst capacity. A token is consumed when granted and not returned: They are similar to a prepaid spending budget for work that arrives in unpredictable sizes or bursts. Tokens work nicely for work that arrives irregularly and is irregularly sized. For example, an analytics workload will get more Tokens than a point query. Tokens are used for IO, disk bandwidth, tenant compute budget, and other areas.
Together Slots and Tokens protect vulnerable, finite resources and ensure that even when overloaded the system can make progress and not collapse. End-to-end ownership of the database means that backpressure from a saturated KV node flows cleanly through the SQL response layer, slowing new query issuance before overload cascades.
The Resource Manager, a component of Admission Control, governs fairness between Virtual Clusters so no tenant starves its neighbors. Resource Groups, also part of Admission Control, shape how workloads compete within a single Virtual Cluster; for example, giving analytics a smaller compute share than a customer-facing OLTP workload.
The Resource Manager sets budgets for Virtual Clusters. An operator of a private host cluster can configure a specific Virtual Cluster to only consume a maximum of 10 vCPUs. Each Virtual Cluster gets a compute budget (burst + refill rate) held authoritatively on the host. Enforcement lives in the Virtual Cluster's SQL process. A local rate limiter estimates the token cost of each unit of work and blocks it if the reserve is insufficient.
Fairness across Virtual Clusters is the Resource Manager’s responsibility. Fairness within a Virtual Cluster is Admission Control's job today. Resource Groups will extend that by assigning explicit CPU-share weights to workload classes inside a single tenant.
Together, these systems enable Continuum to run thousands of Virtual Clusters on one physical host with clear isolation boundaries. A Virtual Cluster can consume a fraction of a CPU when active and scale to zero when idle; storage scales with bytes written, KV compute with active transactions, and SQL capacity with active connections.
This model lets agentic workloads create and discard clusters quickly, while private host clusters isolate your workloads from other customers and consolidation reduces unit cost. Because Continuum is built on CockroachDB, it retains the reliability, scalability, and correctness that enterprises expect.
Elasticity and reduced TCO enable new architectures. SaaS applications can give each customer a dedicated database, cheaply, quickly, and securely, instead of using a shared schema with a tenant_id column. CI/CD pipelines can spin up a fresh database per pull request, run a fully isolated test suite, and tear it down when the branch merges. And because Continuum is CockroachDB, these patterns extend across regions: You can provision a new regional Virtual Cluster the day you sign a customer in that jurisdiction.
Continuum also includes RoachMgr, Aegis, and the AI-powered Migration Assistant to help teams deploy, operate, and migrate workloads.
Related
Designing your own AI-ready estate? The Architect's Playbook for Building AI-Ready Systems lays out the distributed-SQL patterns for agent memory, real-time consistency, and global scale.
RoachMgr: The Control Plane for Database Estates
RoachMgr is Continuum’s distributed control plane, built to manage deployments, upgrades, multi-tenant and multi-region operations, and eventually physical-node autoscaling across a database estate.
CockroachDB runs in many different environments, from private data centers to public cloud providers, from Kubernetes to bare metal. Environments change, but the complexity of operating a distributed SQL system does not.
To manage that complexity we built RoachMgr: a distributed control plane for Continuum that runs on the machines it orchestrates. The team was inspired by Kubernetes but made a deliberate design decision to not build a general tool, but rather to adopt principles from Kubernetes and specialize them to Continuum and Plenum.
Vertical integration lets RoachMgr manage deployments, upgrades, multi-tenant, multi-region, and elastic operations (with auto-scaling of physical nodes to follow). RoachMgr is not yet available for public use, but it is powering the Continuum cloud deployments; we will release it for self-hosted deployments this year. Initially, RoachMgr will orchestrate bare-metal deployments. Later, it will integrate with Kubernetes.
A RoachMgr deployment has two parts:
a roachmgr cluster running across the nodes that host CockroachDB
a separate fleet manager
Within a cluster, one agent process runs on every node. The agents use Paxos both to replicate the cluster's config and to elect one of themselves as the coordinator. Because roachmgr's Paxos is independent of CockroachDB's Raft, the two form separate failure domains that only share the machine. The coordinator sequences cluster-wide actions such as reconciliation, version upgrades, and autoscaling. As in Kubernetes, a human operator declaratively describes the target state and the coordinator's reconciliation loop drives the cluster to it.
For fleet management we built FleetManager, which ships as part of the roachmgr binary and runs as a standalone service. One FleetManager can create and administer many clusters, but each cluster operates independently once bootstrapped. FleetManager provisions infrastructure, installs and upgrades agents, and manages TLS certificates.
Cockroach Aegis: An AI DBA for Database Estates
AI agents and database estate consolidation are increasing the number of databases that teams must operate, while human operators remain stretched thin.
Aegis is a read-only, hosted AI DBA and SRE for Continuum. It analyzes cluster metrics and query plans to surface recommendations, reports, potential incidents, and performance improvements for human operators managing large database estates. Aegis uses Claude Managed Agents to orchestrate the reasoning process through agent definitions and structured memories. Aegis will reason about cluster state, identify the root cause of an issue or escalation, warn about impending incidents, and recommend workload improvements. Human operators evaluate and act on those recommendations; Aegis is read-only at launch.
Aegis runs a loop on each individual cluster. The loop triggers an agent session using either time-based or rule-based triggers. This ensures Aegis is observing the cluster on a regular basis while also being woken for significant problems. This works as follows.
The Aegis Connector is installed on the cluster to be monitored and opens a WebSocket to the hosted Aegis service. The hosted Aegis service uses the connector to run queries against the monitored cluster and return the results to the hosted Aegis service. The connector is the only component installed on the observed cluster.
The Director is an agent in the hosted Aegis service that interacts with the cluster through the connector. The Director agent is the SRE or DBA. The Monitor is the pager, it is deterministic and wakes every 10 seconds and checks whether any preconfigured triggers or learned triggers should fire. Built-in triggers include: node down, decommissioning stuck, unavailable ranges, and liveness heartbeat failures. It will also run the custom alerts created by the Director.
Triggers are PromQL or SQL queries that fire when they return non-empty results. A firing trigger wakes the Director agent. The Director then observes and decides what to do. The Director does not assume the page is accurate. It re-evaluates the situation using tools and reasons using what it learned and what is in its memory.
Aegis maintains knowledge of the configuration and dynamic behavior of a cluster in memories in order to provide continuity across Aegis sessions. This is critical for Aegis's effectiveness. During an agent session Aegis collects information on the cluster, compares it against past knowledge, and if anomalies are detected triggers structured investigations. Aegis then generates recommendations to assist human operators. Recommendations contain a clear line of reasoning for independent verification and for understanding.
Over time Aegis develops an understanding of the cluster. It creates custom alerting rules when specific conditions are met and reports are continually updated to reflect the latest information. This enables Aegis to identify slowly evolving performance degradations, gradual drift, capacity trends, index bloat, and un-used indexes. Aegis then decides whether to edit a report, create a new baseline, or create new triggers. Finally, Aegis checks whether human operators applied previous recommendations and adjusts accordingly.
Human operators interact with the Operator Workspace. The Operator Workspace surfaces full session transcripts, and an interactive chat channel for humans to interface with Aegis. The Operator Workspace exposes a hosted MCP endpoint so you can connect your own AI agent to work with Aegis directly.
We have been running Aegis inside CockroachDB Cloud and with design partners. In one instance Aegis recommended a composite index and reduced query latency from 850ms to 12ms. In another Aegis correctly categorized 76 tables into GLOBAL, REGIONAL BY ROW, and REGIONAL BY TABLE in five minutes. This often takes a few days with experienced DBAs. Aegis identified a queueing hotspot and suggested schema changes to resolve it. Aegis identified stale stats that were five days old and correlated them to the optimizer generating slow plans.
AI-Powered Migration Assistant
Migration Assistant is a hosted service that combines MOLT’s deterministic migration tooling with an LLM-driven orchestration layer to help teams move existing workloads to Continuum.
Many new applications will start fresh with Continuum, while others will migrate existing workloads into it. Migrations between databases are hard. To make them easier, the Migration Assistant uses MOLT to analyze your database, convert routines (UDFs, procedures), generate a migration plan, execute the migration (including migrating data), and analyze the post migration result. The deterministic MOLT layer handles tasks such as schema conversion, while the LLM layer generates migration plans and converts routines.
MOLT is a proven tool, and the responsibility of the Migration Assistant is to make it easy to use. The Migration Assistant will support PostgreSQL, with MySQL and other databases to follow.
How Continuum Changes Database Estate Economics
Every layer of Continuum is elastic, changing the economics of running a database estate: Plenum reduces storage costs by more than 70%; compute is billed in vCPU-hours, so idle Virtual Clusters cost nothing; and shared host capacity spreads infrastructure cost across workloads. Aegis reduces operator effort, while the Migration Assistant reduces the cost of bringing additional workloads onto Continuum.
Built on CockroachDB, Continuum combines that economic model with the reliability, scale, locality, and correctness required to run agentic workloads.
We are proud of what we've built.
If you’re planning for an agent-driven database estate, try Cockroach Continuum on September 15.
Isaac Wong is EVP of Research & Development at Cockroach Labs, where he leads the engineering organization behind CockroachDB to shape the company's long-term technical vision. He oversees the teams driving the database's core architecture, reliability, and continued innovation.
