CockroachDB ends public development of its database and Pebble

Cockroach Labs will stop publishing new CockroachDB source and move future development of both the database and Pebble into private repositories. Peter Mattis announced the decision on September 15. Existing public repositories will remain available as historical snapshots, but will no longer reflect ongoing development. The company will also stop accepting external code contributions to the core database.

The announcement distinguishes source visibility from licensing. CockroachDB continues under the CockroachDB Software License, with no announced change to pricing or existing customer rights. Customers are promised continuing releases and security updates through the same channels. What changes for an engineer is the evidence available to understand the implementation of those future releases.

I have three years with CockroachDB and value its serializable default, range-based replication and PostgreSQL protocol compatibility. Those reasons for considering the database remain technically relevant. The ability to inspect an implementation is another part of evaluating a system, though. Removing that ability changes how much of an operational explanation must come from the vendor, even when the deployed interface looks the same.

The stated rationale combines security and reproduction risk

Mattis argues that AI has changed the speed at which public code can be analyzed and reproduced. The announcement says implementation details and vulnerabilities can be identified at a scale that changes the company's security assessment. It cites the company's experience with Mythos as a reason for treating public source as a disadvantage in defending the product.

The post also raises uncertainty about copyright protections when AI systems can produce functional reproductions. That is the company's stated business rationale. The announcement does not provide enough evidence to quantify either the security improvement from private development or the expected reduction in reproduction risk. Those outcomes should remain claims to evaluate, rather than measurements inferred from the decision itself.

There is a tension in the security argument. Reducing public implementation access also reduces what an independent defender can inspect. An operator evaluating a future fix will have a different set of evidence from someone evaluating a release whose implementation is published. That does not establish that the private release is insecure, but it changes how an external party can assess the vendor's explanation.

My concern is practical rather than a prediction about an inevitable outcome. A system can be useful under a commercial support model. The important change is that implementation-level questions increasingly depend on the supplier being willing and able to answer them. That dependency needs to be recognized as part of choosing the database, alongside the latency and availability properties that usually dominate an architecture discussion.

A historical repository has a different diagnostic role

The public repository remains useful for the versions and implementation history it contains. It can explain how an older release handled an operation or why an earlier change was made. Under the announced policy, it will no longer provide a current description of future development. A source reference must therefore be tied to the release it actually represents.

That affects a familiar form of technical reasoning. Reading a function in the public tree and observing a related behavior in a new binary will no longer establish that the function is the implementation responsible. The new release may contain private changes. The historical source can suggest a hypothesis, but confirming it needs evidence about the actual deployed version.

The same limitation applies to reviewing a patch. A release note can describe a correction, while a code change can show the exact conditions and affected paths. Future public release notes will remain a source of information according to the company's commitments, but the associated private patch will not be publicly inspectable under the new model. The explanation must carry more of the detail an operator previously might have obtained from the change itself.

Bug reporting continues. The FAQ says customers and developers will retain channels for reporting bugs and security vulnerabilities, while external contributions to core source will end. That separates reporting a reproduction from submitting an implementation change. A useful public issue may still exist, but an outside contributor cannot assume the same route from diagnosis to an accepted patch against the current core tree.

Pebble makes this broader than a SQL product decision

The announcement includes Pebble, not just CockroachDB's SQL and distribution code. Pebble's public README describes a LevelDB- and RocksDB-inspired key-value store focused on CockroachDB's needs. It became CockroachDB's default storage engine in version 20.2, after being introduced as an alternative in 20.1. This is implementation code beneath the database's relational interface.

The README also exposes a standalone Go package interface. That makes the public project relevant to users interested in the storage engine independently of the complete database. The September announcement says future Pebble development will also become private. Someone evaluating the public package must distinguish the retained historical code from whatever storage implementation Cockroach Labs develops next.

Pebble's documentation provides an example of why implementation continuity matters. It describes permanent format-major-version upgrades and warns that newer releases can refuse older unsupported formats. Those are substantive storage compatibility rules. A public implementation and its format history can help explain them, while a future private implementation requires a separate account of its supported transitions.

This is not a claim that the announcement changes an existing file format or breaks a current database. It announces a development and publication policy. The consequence is that the public code will stop being a continuously updated source for understanding future storage behavior. Any assurance about a particular future migration must come from the material supplied for that version.

The existing Pebble license file remains part of the public snapshot. The announcement's statement that license terms are unchanged should be kept separate from its decision not to publish new code. A file remaining visible and new implementation work remaining visible are different facts, and the policy changes the latter.

Vendor evidence now has more work to do

The FAQ points customers toward security materials through the Cockroach Labs Trust Portal. It lists SOC 2 reports, software bills of materials, third-party penetration testing and vulnerability disclosures. Customers with specific requirements are directed to their account team. These are the evidence channels the company offers in place of public inspection of new implementation code.

Those materials answer different questions. A software bill of materials identifies components, while a vulnerability disclosure describes a defect and its affected versions. Neither is the same artifact as the implementation itself. They can support a security assessment without recreating every kind of investigation that public source previously allowed.

For an operator, the quality of future advisories will consequently matter more. A notice that identifies the affected condition and explains the correction is more useful than an unexplained severity label. The same applies to compatibility documentation. When the source cannot resolve an ambiguity, the published contract and the vendor's response become the available ways to establish the intended behavior.

This also changes what a support relationship needs to provide. An implementation question may be necessary to understand a failure, even when the application uses only supported interfaces. The ability to obtain a version-specific explanation becomes part of the practical value of support. The September post promises continuity of support, but does not define a universal source-access entitlement for customers with those questions.

The retained open projects have a narrower scope

Cockroach Labs says it will continue maintaining open-source Go libraries including errors, apd, redact and datadriven. It also identifies upstream contributions to Go, gRPC and Bazel. The company describes its decision as specific to CockroachDB and Pebble's core intellectual property, rather than an end to all public software work.

That distinction is relevant, but it does not preserve public development of the database. A library used by the ecosystem can remain open while the main product's implementation becomes private. The engineering evaluation should reflect the particular dependency being chosen. Evidence about an open helper library does not establish visibility into the core storage or transaction implementation of a future release.

The announced deployment options remain available, and the FAQ says customers can continue running and upgrading CockroachDB as before. Existing users therefore have no announced requirement to move merely because publication stops. The longer-term decision is about which dependencies they accept for diagnosis and assurance as they adopt new releases.

For my own assessment, the database's consistency model remains an attraction, but the supplier now has a larger explanatory responsibility. Future adoption depends more on precise release documentation and useful responses to implementation-level questions. The public repository remains valuable evidence about its historical versions, and any reference to it needs to make that version boundary explicit.