Every platform team eventually hits the same wall: applications multiply, and one team is left managing separate clusters, maintenance windows, upgrade cycles, and monitoring dashboards. The estate has scaled, but the team has not.
This is the tax of the “one workload per cluster” model: Infrastructure costs rise alongside the operating cost of running a growing fleet.
Cockroach Labs’ Virtual Clusters offer a different model: Platform teams can give each workload an isolated database environment without creating and managing a separate cluster for each one. In this model, isolation is a boundary with separate connection strings, user identities, and resource ceilings; not necessarily dedicated infrastructure.
Some examples of the current toil for the platform team when managing each cluster independently of the others:
A security patch becomes a multi-week coordination exercise across all database clusters
Every cluster provisioning is a multi-day process
Incident responses are cumbersome with multiple dashboards, log streams, and alert channels
AI agents make this problem worse. Unlike human-driven demand, their database needs do not follow predictable business-day rhythms: agentic applications can multiply quickly, and many require isolated environments with their own schema, connection, and data boundary.
Introducing Virtual Clusters on Cockroach Continuum
Cockroach Labs’ Virtual Clusters are a key feature of Cockroach Continuum, the next evolution of CockroachDB built for agentic database creation, management and utilization. Virtual Clusters let a platform team manage one Dedicated Host Cluster while giving each application team its own fully isolated database environment. Each Virtual Cluster looks and feels like a dedicated cluster: It cannot see other Virtual Clusters’ data, and its workload cannot contend for resources beyond its ceiling, while the Virtual Clusters share the host’s compute.
This separates the responsibilities that typically create operational friction: Application teams get self-service access to isolated database environments, while the platform team governs the shared infrastructure, policies, and operating model.
For the database platform team, this means:
One management surface for incident response, upgrades, and monitoring, instead of separate tooling and processes for every cluster. Schema changes once, not across a fleet.
Provisioning in seconds. When a new application team needs a database environment, the platform team creates a Virtual Cluster, in under three seconds, without infrastructure spin-up, ticket queue, or week-long process. This is especially important when AI agent teams need experimental environments or as-needed agentic application back-ends faster than centralized database operations can provision separate clusters.
Policy instead of manual approval. Database platform teams set the guardrails – CPU ceilings, resource limits, version requirements – and application teams self-serve within them. The database platform team stops being the bottleneck on every provisioning request and starts being the architect and governor of the rules.
Virtual Clusters are proven in production on CockroachDB Cloud
Virtual clusters aren’t a new capability; CockroachDB runs this model in its own production serverless infrastructure. Across 15 host clusters, over 85,000 isolated virtual clusters are active today, with one cluster alone serving 11,000 tenants, and nearly 15,000 tenants serving live traffic in the last 30 days. The median provisioning time is two seconds.
On Cockroach Continuum, the equivalent host cluster is private to one organization; hence, a Dedicated Host Cluster rather than the shared host clusters used in the serverless environment. In other words, the underlying compute is shared across that organization’s Virtual Clusters, not across unrelated customers.
Cockroach Labs' internal AI assistant, Mica, demonstrates this model at the application layer: Every app a user creates gets its own isolated Virtual Cluster, with its own connection string, schema, and data boundary. Since launching in March 2026, Mica has provisioned 487 virtual clusters, with 441 isolated workloads active today. They run on a single Dedicated Host Cluster.
Manage capacity across the database estate
A Dedicated Host Cluster gives platform teams an estate-level view of capacity, so they can identify consolidation opportunities, use idle capacity more effectively, and plan for new workloads across the environment. This is a conceptual shift from managing a fleet of independent clusters workload by workload to managing the estate as a whole.
Here, consolidation does not mean merging applications or removing workload boundaries. It means reducing duplicated cluster infrastructure and operational processes while keeping workloads isolated.
When you can see aggregate capacity across all workloads, you can ask different questions:
Which workloads have uncorrelated peaks, and could their idle capacity fund each other's bursts?
Where is there stranded capacity that could absorb the next application team?
Which environments are candidates for consolidation?
These are the questions that give a platform team extreme leverage over both infrastructure and human costs. Not just over today's multiple applications, but across the next wave of applications. Virtual Clusters preserve workload boundaries, isolation, and guarantees without making the team’s management surface multiply with every new workload. The team stays the same. The estate grows.
Related: Modernize Applications and Infrastructure with Distributed SQL — a whitepaper on reducing fragility, cost, and complexity across the modernization journey.
Virtual Clusters are in public preview on Cockroach Continuum. If your team is managing a growing database estate, explore how isolated workloads can share a Dedicated Host Cluster. Talk to an expert.
