Cockroach Labs plans to replace Core with eligibility-based Enterprise

CockroachDB's free self-hosted path is moving from a feature boundary to an eligibility boundary. In the August 15 announcement, Spencer Kimball says Cockroach Labs will retire Core with version 24.3 in November. Enterprise Free will cover individual developers, students, academic researchers and businesses below $10 million in annual revenue. The announced availability date is November 18.

The change also applies to new patch releases of versions 23.1 and later. Cloud customers are outside this announced change. A renewable annual free license and a 30-day trial will offer the Enterprise capabilities previously separated from Core, with community support. As of August 15, this is a planned licensing transition, not a release that has already happened.

I value CockroachDB's serializable default and its explicit distributed-systems costs. That makes the licensing change relevant to adoption without changing the technical reasons to consider the database. A deployment needs both a suitable transaction model and a durable basis for running the versions it will require.

A feature subset and a qualifying user are different models

Under the announced model, deciding whether a feature belongs to Core no longer answers whether a self-hosted deployment can continue without payment. Eligibility attaches to the user or business. That distinction changes what information matters to an engineering decision. A database team can avoid a particular feature, but it cannot infer the organization's revenue eligibility from a schema or query plan.

The immediate benefit for a qualifying user is access to capabilities that previously required Enterprise. The accompanying cost is that the basis for free use has become conditional on that user's status. These can both be true for the same product change. Describing it only as making Enterprise free would omit the new eligibility boundary, while describing it only as removing free use would omit the qualifying path.

For a larger organization previously using Core, declining additional capabilities does not preserve the announced Core route once that route ends for the relevant new releases. That is an implication of replacing the product split, rather than a judgement about which features that organization needs. Feature selection and license eligibility now answer different questions.

This matters to architecture because operating a database includes later maintenance. An evaluation that considers only the features needed on its first day leaves out the versions required during its service life. The announcement's inclusion of patch releases makes the license boundary relevant to ordinary maintenance, not just to a discretionary move to a new major version.

The company's stated problem is competition with its own Core edition

Kimball describes two trends behind the decision. Smaller users want Enterprise capabilities, while some larger businesses keep using Core instead of purchasing Enterprise. The company's explanation is that improving product reliability has reduced some users' need for support, weakening a reason to buy the paid offering. That is the vendor's stated commercial argument, not independent evidence about every Core deployment.

The reasoning has a practical consequence for users. A paid support need and a willingness to pay for database use are separate economic questions. An organization that rarely needs help can still derive substantial value from the software. The new model tries to connect payment to organizational scale rather than leaving it dependent on selecting the Enterprise feature subset or support package.

That is a more direct commercial boundary. It also creates a different planning dependency for engineers. Technical success can increase organizational reliance on the database while the organization's eligibility changes for reasons outside the database workload. The relationship between a database's resource consumption and the user's revenue is not something the transaction engine can resolve.

I accept that database engineering needs funding, and this announcement gives a clear account of the company's objective. The separate question is whether the proposed license fits the intended deployment over time. Agreement with the commercial problem does not by itself establish that every existing Core user has an acceptable transition.

The earlier licensing change addressed a different competitor

The founders' June 2019 explanation of the Business Source License focused on commercial database-as-a-service competition. Its additional grant allowed broad use while restricting an unlicensed commercial DBaaS. It described conversion of the covered Core code to Apache 2.0 after a rolling three-year period, with Enterprise code separately licensed.

That history gives the August announcement a useful distinction. The earlier restriction addressed another business selling a competing hosted service. The new argument addresses businesses using the free self-hosted product for their own needs. Those are different relationships to the software, so the change should not be reduced to another instance of the same cloud-provider dispute.

The 2019 text also explicitly distinguished source availability from the Open Source Initiative's definition. August's statement that source will remain available should therefore be read as a statement about code access. It is not a substitute for the permissions and obligations attached to the relevant release. A person may be able to inspect implementation code while still needing to establish the right to operate it under the applicable terms.

That distinction matters for technical diagnosis. Source access can help explain behavior and identify a defect, but it does not settle the deployment's commercial conditions. Conversely, a valid deployment license does not itself establish that a particular defect has been diagnosed. Engineering evidence and usage permission remain separate inputs even when both influence adoption.

Patch scope brings maintenance into the decision

The announcement's inclusion of new patches for existing major lines prevents a simple interpretation in which only a future major-version feature set is affected. An organization can need a maintenance release to correct behavior in a version it already operates. The decision about taking that update can then intersect with the new licensing structure.

For example, the June changefeed advisory describes initial-scan omissions fixed in named maintenance releases. It illustrates why patch adoption can concern data correctness rather than access to optional new functionality. This example predates the announcement and does not imply that its particular repair requires the planned November terms.

The architectural implication is that a deployment's future maintenance path matters alongside its current release. Remaining on one artifact and continuing to receive maintained artifacts are different strategies. The announcement does not justify pretending that those strategies have equivalent correctness or support properties over time. Their costs depend on which later fixes the deployment needs.

A transition plan can consequently require commercial information before a technically routine upgrade is ready. That is a dependency created by the announced scope. It does not mean engineering should invent legal interpretations or assume unspecified exceptions. The dated announcement establishes the broad product change, while the relevant agreement must determine a particular organization's rights.

Broader capabilities do not remove operational choices

Access to Enterprise functionality can broaden the options available to a qualifying user. It does not mean every newly available capability belongs in every deployment. A feature may alter resource requirements or introduce another recovery procedure. Licensing availability removes one access boundary while the technical design still needs to justify the operation.

The 24.1 release notes, for instance, distinguish Read Committed isolation from the serializable default and identify an Enterprise requirement. That shows how a capability boundary can intersect with transaction behavior. Wider access is useful, but selecting weaker isolation remains a decision about application invariants rather than an automatic benefit of a larger feature set.

Community support and a paid support arrangement also remain different considerations in the announced free path. A user can gain the software capability without gaining the same support relationship as a paid customer. An operational design that depends on a particular response commitment needs to establish it separately instead of inferring it from the Enterprise product name.

The annual renewal described for Enterprise Free also makes eligibility a recurring consideration. A successful initial evaluation establishes a starting condition, while renewal concerns the deployment at a later point. The database can remain technically suitable throughout that interval even when the basis for its free license changes.

As of this announcement, November's release and license transition remain future events. The concrete planning change is already clear. A self-hosted application's continued use of new CockroachDB releases will depend on the announced eligibility or commercial arrangement, even when its SQL and resource requirements remain unchanged and it does not seek additional Enterprise functionality.