Databases for agentic workloads
Agents create applications. Because each application needs persistent state, this quickly multiplies the number of databases an organization will run. Agents work continuously and issue many requests in parallel, so traffic patterns include frequent spikes. Provisioning a dedicated cluster for each database does not scale to agentic workloads. Because each cluster is typically overprovisioned for its peak workload, most capacity sits idle, and each new cluster adds operational burden. Continuum addresses this problem in five ways:- Virtualization runs many isolated databases as virtual clusters on a host cluster, on capacity provisioned once, without a dedicated cluster for each database.
- Cockroach Plenum separates storage from compute, so that each scales independently with demand.
- Cockroach Aegis monitors your clusters continuously and generates recommendations based on what it observes.
- Migration Assistant uses AI to analyze, convert, and load data from your source database into a Continuum cluster, as you review each step in the migration.
- Editions and add-ons bill for usage: usage-based storage is billed on data stored, and add-ons are billed only while active.
Terminology
- Organization: The boundary of Continuum. New CockroachDB Cloud organizations use Continuum, and all clusters, workspaces, and billing in an organization belong to it. For how access is managed within an organization, refer to Authorization.
- Cluster: The unit you create and manage on Continuum. Every cluster is a CockroachDB cluster, in one of three roles: standalone, host, or virtual. For the underlying architecture, refer to the CockroachDB architecture overview.
- Host cluster: A Mission Critical cluster created with virtualization enabled. It runs its own CockroachDB nodes and provides the capacity that virtual clusters share. Refer to Host Clusters and Workspaces.
- Virtual cluster: An isolated database created on a host cluster and served by the host’s nodes, with no separate charge. Continuum virtual clusters are distinct from self-hosted cluster virtualization, which shares the underlying architecture but has a different management surface. Refer to Continuum Virtualization and Virtual Clusters for more information.
- Workspace: A logical grouping that associates virtual clusters with a host cluster. Each host cluster has a single default workspace. All virtual clusters are created in this default workspace and inherits the default burst limit. Refer to Workspaces and Host Clusters.
- Edition: A cluster plan that sets infrastructure, availability, and feature boundaries. Continuum offers Standard and Mission Critical. Refer to Editions and Add-Ons.
- Shared and dedicated infrastructure: The two kinds of infrastructure clusters run on. Shared infrastructure serves clusters from multiple organizations; dedicated infrastructure is provisioned for a single cluster. Standard runs on shared infrastructure, and Mission Critical runs on dedicated infrastructure.
- Add-on: A capability that a cluster uses and is billed for only while it is active, such as hosting virtual clusters or running changefeeds to a sink. Refer to Add-ons.
- Storage model: The choice, made at cluster creation, between usage-based storage, backed by Plenum and billed on data stored, and provisioned storage, billed on provisioned capacity.