CockroachDB 24.3 makes licensing part of cluster operation

A database license can affect whether an upgrade proceeds and whether a configuration change is accepted. CockroachDB 24.3, released on November 18, makes those dependencies explicit as it implements the licensing transition announced in August. New releases use the CockroachDB Software License, including new patches for versions 23.1 through 24.2. Core no longer provides the free feature-subset path for those releases.

The release offers paid Enterprise, Enterprise Free for qualifying businesses below $10 million in annual revenue and an Enterprise Trial. The release notes say Cloud deployments automatically have a valid Enterprise license. Self-hosted deployment is where license selection and configuration become explicit operating concerns, alongside the server binary and cluster settings.

I value CockroachDB's consistency guarantees, and I accept its coordination costs when the workload needs them. Licensing now adds another condition to operating the maintained software. That condition deserves a concrete account of what the released artifact requires, rather than relying only on the August announcement's product description.

The released license defines the key requirement

The license included in the 24.3.0 source says operating the software requires a license key except for its defined limited non-production use. It also describes telemetry requirements, with exceptions for that limited use or a key permitting telemetry to be disabled. These are conditions in the released artifact, not merely labels attached to a pricing page.

The defined non-production use concerns design, prototyping, testing or development in internal non-production environments. It applies during an introductory period, if any, or to a database running solely on one node. That is narrower than assuming any small production deployment is exempt because it has little traffic. Workload purpose and the specified conditions matter independently of resource consumption.

The license also describes technical measures that limit unauthorized use and prohibits circumventing them. The operational implication is that satisfying the license conditions belongs in the supported deployment configuration. Editing around a key or telemetry requirement would not be equivalent to choosing a supported configuration for an otherwise valid deployment.

This changes how source availability should be interpreted. The source remains available in this release, but inspecting it does not remove the license's conditions on operation or modification. The terms included with the artifact determine that relationship. A broad statement that the code is available is therefore insufficient as a deployment-rights description.

Upgrade checks require the condition before the transition

The 24.3 release notes state that an upgrade is blocked if no license is installed. They also block upgrading with a trial or free license when telemetry is disabled. This puts the requirement before completion of the version transition. An operator cannot assume that license setup is a separate task to complete after an otherwise ordinary upgrade.

That is a useful distinction from a passive notice. A passive notice could leave a cluster running while reminding an administrator to update paperwork. A blocking upgrade condition changes the executable sequence of the maintenance operation. The license state and telemetry state must be acceptable before that transition can proceed through the supported path.

An existing cluster's technical readiness therefore does not alone establish upgrade readiness. Application compatibility and sufficient capacity remain relevant, but the new gate asks another question. A deployment can pass its SQL compatibility checks while still lacking the required installed license or permitted reporting configuration.

The scope also includes new patches for older major lines. That prevents interpreting the change solely as a condition attached to optional 24.3 functionality. A self-hosted operator taking a newly released patch in an affected line needs to consider the license associated with that artifact. The major-version name alone no longer identifies the earlier Core arrangement.

I find the artifact boundary important here. A deployment should be assessed against the version and terms it will actually run. Treating a maintained major branch as having one unchanged license for every future patch would contradict the scope stated in the release notes.

Telemetry and license assignment validate each other

The release adds validation to enterprise.license and diagnostics.reporting.enabled. A trial or free license requires diagnostic reporting to be enabled before that license can be set. Disabling reporting requires a license that is neither a trial nor free license. These checks connect two settings that an operator might otherwise treat as independent.

The order of configuration changes now matters. A script that installs a free key while reporting is disabled does not satisfy the documented prerequisite. A later attempt to disable reporting under that key also encounters the corresponding restriction. The relationship persists after initial setup rather than applying only when the key is first acquired.

This is an operational dependency between license type and network reporting. A self-hosted environment may control its own database processes while still needing to satisfy an outbound telemetry condition for the selected license. Physical control over the machine and the ability to choose every reporting setting are different properties of this software arrangement.

The release notes describe throttling for Enterprise Free and Trial clusters after seven days without telemetry. That duration gives a specific enforcement condition, but it should not be treated as a recommendation to operate near the limit. The relevant design fact is that interrupted reporting can eventually affect operation under those license types, even if application SQL has not changed.

Paid Enterprise can disable telemetry according to the described license options. That makes license selection relevant to environments with different reporting requirements. A deployment that cannot meet the free or trial condition needs a permitted arrangement, rather than assuming that disabling one setting leaves every other part of the chosen license valid.

The October disclosure remains a separate redaction issue

The October 25 diagnostic advisory described OIDC settings entering diagnostic payloads through an incorrect redaction path. It named 24.3.0 among the planned repaired releases. That defect and November's reporting requirement concern different questions. One asks whether a payload improperly includes credentials; the other asks whether a selected license requires diagnostic reporting at all.

Those questions need to remain separate when describing the new release. Requiring telemetry does not justify sending sensitive authentication values. Correcting a payload's redaction does not establish that a deployment may disable reporting under any license type. The supported configuration needs to satisfy the applicable reporting condition while using the repaired diagnostic behavior.

This is also why the release's validation matters more than a casual reading of a configuration guide. A setting can exist in the database while a particular license disallows one of its values. Its technical availability and its permitted assignment are different facts. The new checks make part of that relationship visible at configuration time.

Free functionality and support remain different

The August announcement described the free option as giving qualifying users Enterprise capabilities with community support and annual renewal. November implements the unified software arrangement. Access to the full capability set does not automatically supply the support relationship associated with a paid agreement.

Annual renewal also means a currently valid free license has a lifecycle. A cluster can remain technically healthy while its license approaches renewal. Eligibility and renewal belong to the operating information for the deployment, alongside the configuration that selects its reporting behavior. They are not properties a successful query can establish.

The trial has a different purpose and duration from renewable free use. A successful evaluation under a 30-day trial establishes that the software can serve the evaluated workload during that period. It does not select the ongoing license for production operation. The release distinguishes those options, so an adoption decision should preserve the same distinction.

The release also tells users upgrading directly from 24.1 to review 24.2 compatibility changes. Skipping an intermediate installed version does not remove its behavioral changes from the destination. That version-path requirement remains alongside the licensing gate, since a valid key does not prove that the application is compatible with the intervening SQL and operational changes. Both requirements apply to the intended transition.

The new arrangement therefore affects more than which features appear unlocked. Upgrade gates make acceptable license state a prerequisite for changing versions. Configuration validation connects free and trial keys to diagnostic reporting. For a self-hosted deployment taking these releases, the selected license and its reporting conditions are now explicit inputs to the cluster's supported operating procedure.