CockroachCloud brings self-service provisioning to distributed SQL

A self-service database interface is useful when the operations behind it are as deliberate as the cluster-creation form. Cockroach Labs opens its broader managed-service beta today, bringing provisioning and ongoing operation into the same offering. The service lets a user select a cloud provider, region and node configuration while Cockroach Labs takes responsibility for the installation.

The October 16 announcement, preserved in the company's announcement archive, describes the next step after limited-availability Managed CockroachDB. The new self-service beta addresses the work required to launch and maintain a distributed SQL database.

I am interested in the service because CockroachDB's consistency model has operational consequences worth understanding. A managed offering can take responsibility for much of that work. The application still needs to choose a topology and a transaction model that match its requirements.

Creating a cluster selects an operating arrangement

The announcement describes choosing the provider and region, along with the number and size of nodes. These are more consequential choices than naming a database. They determine what resources exist and where the service can place its work.

AWS and GCP are the announced provider options. The post describes additional providers as future work. The beta should therefore be understood through those available choices, without assuming that a general cloud-service description means every provider is supported.

The service offers a single-node option, which the announcement recommends for testing. Its preferred minimum production configuration is three nodes placed across three availability zones. That placement is intended to tolerate a datacenter outage.

The difference between those configurations matters. A one-node installation can be useful for learning or a small experiment, but it does not acquire three-node redundancy merely because the same managed interface creates both. The interface makes deployment convenient while retaining a real availability choice.

For multi-region requirements, the announcement describes spreading nodes across regions and availability zones to survive a whole region's outage. That is a stronger placement requirement than spreading nodes within one region. A user needs to identify which failure scope the application requires the database to tolerate.

My preference is for that choice to remain visible. A service can automate placement, but an availability requirement should still identify the kind of failure being considered. Otherwise, two clusters with different protection can appear equivalent because both are called managed.

Operational ownership moves to the service

Cockroach Labs says it handles provisioning, monitoring and alerting, along with major and minor upgrades. It also describes daily full backups and hourly incremental backups. These are concrete responsibilities included in the offering, rather than an unspecified promise to reduce administrative effort.

Each responsibility concerns a different stage of the installation's life. Provisioning establishes resources. Upgrading changes the software running on them. Backups preserve a recovery path outside the current live state.

This changes the work an application team must perform directly, but it does not erase the distinctions among those operations. A healthy current cluster and a usable recovery path are different properties. Likewise, a successfully created cluster can later need maintenance as the database software changes.

The announcement also includes enterprise capabilities such as change data capture and geo-partitioning. That makes the managed offering broader than hosting an otherwise isolated SQL process. Applications can use data-placement and integration features without assembling a separate service around each one.

The important engineering question is how the service knows that these running components provide the behavior users need. Internal process metrics can show that a node is alive while a particular SQL operation is failing. Earlier work by the service's SRE team gives a useful account of that distinction.

Monitoring must exercise the storage path

Jay Lim's August account of SQL Prober describes building black-box monitoring for the managed service. An internal beta-cluster incident had broken database and table creation without giving the team the detection and impact measurements it needed.

A trivial constant query was insufficient for the intended probe because it did not exercise key-value storage. The team wanted an operation that touched the storage path without reading or modifying customer data.

Their solution used a dedicated monitoring table whose data placement was controlled through replication zones and lease preferences. By arranging probe data across the cluster, they could make a query exercise the relevant nodes while preserving a separate monitoring dataset.

This is a more specific health model than checking whether one SQL connection succeeds. A distributed gateway can answer some requests while another part of the cluster has trouble serving data. The probe needs to exercise enough of the actual path to reveal that difference.

The account also describes verifying leaseholders before reading the probe rows. Placement preferences can fall back to another replica, so a successful read alone could otherwise miss the node the probe intended to test. The monitoring result is meaningful only when the request actually uses the intended path.

This is a useful example of operational work that a managed-service user does not see in the creation form. The service has to decide what successful behavior means and arrange a probe that tests it. Simply increasing the number of internal metrics would not necessarily answer the same question.

A probe also has a stated coverage limit

The SQL Prober account says the implementation at that point tested reads, with writes and DDL identified as future work. That is a valuable limit to retain. A successful read probe does not demonstrate every operation a customer application can perform.

The same principle applies when interpreting a managed service more generally. A health indicator is evidence about the behavior it exercises. Its usefulness improves when the tested operation and its limits are clear.

This does not reduce the value of the probe. Testing a defined path through distributed storage is useful evidence. The engineering task is to connect that evidence with other observations that cover different operations, without treating one result as proof of every possible behavior.

I prefer a service account that explains its measurements this way. A database's consistency guarantees are properties of its protocol and implementation. Operational monitoring supplies evidence that a running installation is available to execute the operations an application currently needs.

Network access and SQL authority remain separate

The launch announcement describes dedicated VPCs with firewalls and IP-based access controls. It uses certificates for node authentication and usernames and passwords for client authentication. Network traffic uses TLS, and encryption at rest is enabled for data and backups.

Those mechanisms answer different questions. Network controls govern which sources can attempt a connection. Authentication identifies a participant, while SQL authorization determines what that participant may do after connecting.

A single connection string pointing to a load balancer simplifies the client's address configuration. It does not replace the requirement to create an appropriate SQL user or permit the client network location. The service documentation describes those steps separately because they establish different parts of access.

The announcement also distinguishes role-based access to the service console from roles for SQL users. Managing a cluster through its administrative interface and querying its application tables are separate activities that can require different authority.

The 19.1 release announcement provides context for the underlying enterprise capabilities, including encryption at rest and locality-aware query work. Hosting these capabilities behind a service does not make their semantics disappear. It changes who configures and operates much of the supporting infrastructure.

Locality still interacts with query meaning

Version 19.1's follower reads show a condition that an application owner must retain even with managed infrastructure. Eligible historical queries can use nearby replicas, but they require a sufficiently old timestamp. That is a query-level freshness choice.

A service can make it easier to create replicas in several places. The application still has to distinguish a request for historical data from one that depends on current state. The location of a connection endpoint is not enough to settle that distinction.

Similarly, selecting multiple regions is an availability and placement decision with consequences for communication. Managed provisioning can establish the chosen arrangement, while the database still performs the distributed work that arrangement requires.

The self-service beta is therefore a concrete reduction in installation and maintenance work, backed by responsibilities named in the announcement. Its engineering value includes the operations behind the interface, such as storage-aware probing and controlled replica placement. Applications retain the decisions that define their own correctness and freshness requirements, even when Cockroach Labs operates the cluster that carries them out.