Here is the most important thing to understand about CockroachDB in 2026: it is the project that took the license wave to its logical extreme. Redis got a fork. Terraform got a fork. Elasticsearch got a fork. MongoDB got a compatible reimplementation. CockroachDB got neither. It moved from open source to the Business Source License in 2019, and then in 2024 it did something none of the others did — it stopped publishing new source code entirely, moving core development behind closed doors. There is no OpenCockroach. There is no FerretDB equivalent. If you want the latest CockroachDB, you take it on the vendor's terms. This is the story of that path, and why it matters more than the happier fork stories.
For years CockroachDB was the poster child of "cloud-native distributed SQL" — a database that looked like PostgreSQL, scaled like NoSQL, and survived datacenter failures without manual intervention. Startups and enterprises adopted it for exactly those properties. Then the license tightened, and tightened again, until the source simply stopped flowing. The community that built around an open promise was left with a binary and a support contract. Understanding how that happened is the most important cautionary tale in the entire license-wave saga, because it shows the outcome the fork stories quietly assume cannot happen.
This review covers what CockroachDB is, the early open years, the 2019 BSL move, the Cockroach Community License, the three-year conversion clause, the 2024 shift to the CockroachDB Software License, the move to private source, why no fork emerged, real self-hosting and enterprise costs, where your data actually lives, and an honest verdict for an operator who cares about data sovereignty.
1. What CockroachDB Actually Is
CockroachDB is a distributed SQL database. It presents a PostgreSQL-compatible SQL interface — you connect with the Postgres wire protocol and most psql clients and ORMs work — but underneath it is a horizontally scalable, strongly consistent, survivable key-value and relational store. Its design goal, encoded in the name, is to tolerate disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention. Nodes are symmetric: one binary, minimal configuration, no required auxiliary services.
The core job CockroachDB takes is "give me SQL ergonomics with the scale and resilience of a globally distributed system." It supports ACID transactions with strong consistency, automated repair and recovery, geo-partitioning of data to keep it near users, and a "multi-active availability" model that lets you read and write from any node without conflicts. For high-volume OLTP across multiple regions, it is one of the most capable systems available, and that capability is precisely why its license trajectory matters: it is hard to replace.
2. The Open Years (2015–2019)
CockroachDB launched as an open-source project. Its earliest versions were Apache 2.0, and the company's founding story — engineers who had worked on Google's Spanner and Colossus building an open, survivable SQL database — resonated with the community. For those first four years, CockroachDB was something you could read, modify, and redistribute freely. That openness is what let it build an early adopter base and a reputation as the open answer to Google Spanner.
This is the quiet setup, and it mirrors the others: openness built the adoption, adoption built the value, and the value attracted a desire to capture it more directly. The difference is that CockroachDB's path did not stop at a restrictive-but-still-visible license. It kept going, and the community's ability to fall back to an open version shrank with every release.
3. 2019: The Move to the Business Source License
In 2019, with version 19.2, CockroachDB transitioned its core features from Apache 2.0 to the Business Source License. The BSL here works as it does elsewhere: you may use, modify, and distribute the software, but you may not offer it to third parties as a hosted or embedded competing database service without a license from Cockroach Labs. Non-CCL core features from version 19.1 and earlier remained Apache 2.0, and the BSL carries a conversion clause — each BSL release converts to Apache 2.0 three years after its publication date. So the 19.2 core became Apache 2.0 in late 2022, the 23.1 core converted in May 2026, and so on. The tightening was a delay on openness, not a permanent revocation of the older code.
4. The Cockroach Community License
Complicating the picture is a second license, the Cockroach Community License, or CCL. The CCL covers source that is free to view and modify but cannot be reused in another product without an agreement with Cockroach Labs. Some CCL features are free; some require an Enterprise license key. This two-track model — BSL for some core features, CCL for others, Apache 2.0 for the oldest — means that determining the license of any given CockroachDB capability requires reading the file header, not assuming one blanket license. It is legally careful and practically confusing, and it is part of why the project's licensing is hard for casual users to reason about.
5. The Three-Year Conversion Clause
The BSL's conversion clause is the one piece of genuine openness preserved in the 2019 move. Because each BSL release becomes Apache 2.0 three years after publication, the codebase ages into open source on a rolling basis. As of 2026, the 23.1 release's non-CCL features converted to Apache 2.0 in May 2026, meaning a three-year-old CockroachDB core is, in principle, open. The catch is that three-year-old core is three years behind on features, performance, and security fixes, and the newest capabilities — the ones you actually want — remain under BSL or CCL or, increasingly, unpublished. The conversion clause is real but increasingly irrelevant to anyone who wants a current database.
6. 2024: The CockroachDB Software License
In 2024, Cockroach Labs consolidated its licensing model further around what it calls the CockroachDB Software License. The company was careful to state that this was an evolution of terms rather than a new restriction on existing rights, but the practical effect was to simplify the message: CockroachDB's valuable features are not open source, and they will not become open source on any near-term timeline the way the BSL conversion once implied. The arc from Apache 2.0 to BSL to a bespoke software license is a one-way ratchet, and 2024 was the year it became explicit that openness was no longer the company's default posture.
7. The Move to Private Source
Then came the step no other major project in this wave took. In 2024 and 2025, Cockroach Labs announced that new versions of CockroachDB — and Pebble, its high-performance storage engine — would no longer have their source code published to the public repository. The existing public repository remains available as a historical snapshot, but it is no longer maintained or updated. New development happens in private. The official framing was about protecting intellectual property in the age of AI: publicly available source, the company argued, can now be analyzed, understood, and functionally reproduced by large language models at scale, changing the security and IP calculus. Whatever the motivation, the outcome is unambiguous — for the latest CockroachDB, there is no public source at all.
8. Source Available Is Not Source Published
It is worth being precise about the vocabulary, because vendors use it carefully. "Source available" means you can sometimes see the source under restricted terms. "Source published" means the current source is actually in a public repository anyone can read. CockroachDB moved from source published, to source available under BSL, to source unpublished for new versions. That last step is the one that removes the community's ability to fork the current code even under the BSL's eventual conversion, because there is no current code to fork — only whatever the last published snapshot contained, which is now stale by definition. This is the structural reason no OpenCockroach exists.
9. Why No Fork Emerged
The central question of this article: why did CockroachDB not get the fork that Terraform, Redis, and Elasticsearch got? Several factors converge. First, by the time the project moved to private source, the last meaningfully current open snapshot was already old, and forking stale code means forking a database three years behind — not a compelling foundation. Second, building a distributed SQL database from a fork is a massive engineering undertaking; the fork stories that succeeded had corporate sponsors (Linux Foundation, AWS, IBM) willing to fund it. Third, CockroachDB's value is concentrated in its newest features and its storage engine, both of which are now private, so a fork would lack the very things that make the product desirable. The fork model works when the open version is current and the valuable code is visible; CockroachDB removed both preconditions.
10. The Spanner Problem
There is a deeper reason distributed SQL is hard to fork: it is genuinely difficult to build. Google spent years and enormous resources on Spanner. CockroachDB's engineering is comparably deep. A community fork of a stale snapshot would need to re-implement years of subsequent development to be competitive, and there is no equivalent of "the last MPL Vault" that is both current and open. Contrast this with Valkey, which forked a one-week-old BSD Redis and immediately had a current, competitive codebase. The lesson is that the fork outcome depends as much on the project's complexity and the freshness of its last open version as on the community's indignation. CockroachDB's complexity and its stale-open-status together foreclosed the fork.
11. The AI IP Argument
Cockroach Labs' stated rationale for going private is worth engaging with seriously, because it will recur. The argument is that AI has changed how quickly software can be analyzed, understood, and reproduced; that publicly visible source can be mined for implementation details and architectural patterns at scale; and that this expands both the attack surface and the risk of functional reproduction by competitors. There is a legitimate security argument buried here — public source does make vulnerability discovery faster for both defenders and attackers. But the leap from "public source carries risk" to "stop publishing source" is a choice, not a necessity, and it is a choice that sacrifices the community's ability to audit, learn from, and fork the code. For a database that stores an organization's most sensitive data, the inability to audit the current source is its own security concern, and reasonable operators weigh the two risks differently than the vendor does.
12. What This Means for Existing Customers
Cockroach Labs has been explicit that for existing customers, little changes in how they license, deploy, run, upgrade, or receive support. Supported releases, updates, security fixes, and support continue through the same channels. Customers still get SOC 2 reports, SBOMs, third-party penetration testing, and vulnerability disclosures through the Trust Portal. So the private-source move is not a breach of existing agreements; it is a change to the social contract about openness going forward. The risk it introduces is forward-looking: the community can no longer contribute code, report issues against current source, or reference current implementation details, and the project's trajectory is now entirely at the vendor's discretion.
13. Where Your Data Actually Lives
Data sovereignty for CockroachDB is sharply different from the fork projects. With self-hosted CockroachDB, your data lives in your own storage, replicated across your nodes, under your control — the software license does not move your bytes. But the software that manages that data is now closed for current versions, which means you cannot audit how it handles your data, cannot patch it yourself, and cannot fork it if Cockroach Labs changes terms unfavorably. For a sovereignty-minded operator, the question is not "where are my rows?" but "who controls the engine that promises to keep them safe?" With CockroachDB, the answer is increasingly a single vendor with no open-source obligation on current code. That is a different risk profile than Postgres or even the BSL forks.
14. Real Self-Hosting Costs
Self-hosting CockroachDB Community or a trial of the full product is free to start, but production scale carries costs. A small three-node cluster for development runs on modest VMs — perhaps $30–$60 per month for the nodes — but a serious multi-region deployment with the Enterprise features (advanced backup, changefeeds, multi-region capabilities, follower reads) requires a paid license from Cockroach Labs, and enterprise pricing is negotiated rather than published, typically running into the thousands of dollars per node per year for serious workloads. The honest cost story is that CockroachDB is free to evaluate and expensive to run at scale with its advanced features, and the license situation means you cannot escape the vendor relationship by self-hosting the current version the way you could with Postgres.
15. Managed CockroachDB and the Lock-In
Cockroach Labs offers a managed DBaaS, and the managed path is where the private-source decision bites least operationally — you offload operations — but most on lock-in. Because the current engine is closed and feature-concentrated, migrating off CockroachDB to another distributed SQL system (such as YugabyteDB, which remains open source under Apache 2.0, or TiDB) requires re-validating your SQL and workload against a different engine, even though both are Postgres-compatible at the wire level. Postgres wire compatibility lowers but does not eliminate migration cost, because each system has dialect and feature differences. The private-source move raises the stakes of that lock-in: you are betting that Cockroach Labs' terms and pricing remain acceptable, with no open fallback for the current version.
16. The YugabyteDB and TiDB Contrast
It is impossible to discuss CockroachDB's closure without naming the open alternatives that did not close. YugabyteDB, a distributed SQL database with a similar Postgres-compatible surface, remains under the Apache 2.0 license for its core. TiDB, another distributed SQL system, is open under Apache 2.0. Both are viable for teams that want CockroachDB-like properties without the license risk. The existence of these alternatives is the practical escape hatch that CockroachDB's own closure creates: if you are evaluating distributed SQL in 2026 and sovereignty matters, you can choose an open core and avoid the private-source problem entirely. The tragedy is not that CockroachDB closed; it is that teams already committed to it have a harder exit than teams choosing fresh.
17. The BSL Conversion: A Closing Window
For teams determined to use CockroachDB on open terms, the only sanctioned path is the three-year-old converted core. The 23.1 non-CCL features became Apache 2.0 in May 2026, which means a 2023-vintage open CockroachDB exists — but it lacks three years of performance, security, and feature work, and the surrounding tooling has moved on. Running a three-year-old database in production is its own risk, and most teams will not. So the conversion clause, which sounds like a safeguard, functions in practice as a museum: the open version is historical, not current. This is the quiet mechanism by which BSL-then-private projects hollow out the "it becomes open later" promise.
18. Community Contributions and Bug Reporting
The private-source move ended external code contributions to the core. Cockroach Labs continues to provide channels for bug and vulnerability reporting, and it maintains open-source non-core Go libraries — errors, apd, redact, datadriven — and contributes upstream to Go, gRPC, and Bazel. So the company's claim that it still believes in open source is partially borne out by its library work. But the core intellectual property, the distributed database itself, is no longer open to contribution or audit. For a community that valued CockroachDB precisely because it was open, this is the loss that stings most: you can no longer help build the thing you depend on.
19. Security Transparency Trade-Off
There are two competing security arguments and a sovereign operator should hold both. The vendor's argument: private source reduces the attack surface that AI can mine. The operator's argument: private source removes the ability to independently audit the code that holds your data and to verify security claims. Public source enables both attackers and a global community of defenders; private source empowers neither. For regulated industries, the inability to review current source can be a compliance problem in itself, akin to the SSPL friction MongoDB faces, though more extreme because there is no source at all. The right posture is to demand the SOC 2, SBOM, and pen-test artifacts the vendor does provide, and to recognize they are a substitute for, not equivalent to, source audit.
20. The Precedent This Sets
CockroachDB's private-source move is a precedent other infrastructure vendors are watching. If it is commercially successful — if customers accept it without mass exodus — it signals that "open, then BSL, then private" is a viable extraction path for valuable software, and more vendors may follow. If it backfires — if customers flee to YugabyteDB and TiDB — it becomes a cautionary tale that deters the move. The outcome matters beyond CockroachDB, because it tests whether the community's fork-and-reimplement responses are sufficient against a vendor that simply stops publishing. So far the answer is mixed: no fork emerged, but open alternatives captured the sovereign-minded demand.
21. Honest Limitations of CockroachDB Today
Let me state the weaknesses plainly. The current version is closed source; you cannot audit or fork it. The open converted core is three years stale. There is no community fork and no FerretDB-style reimplementation, so your only open exit is a different product (YugabyteDB, TiDB) with migration cost. Enterprise features require negotiated pricing. And the private-source decision means the project's future is entirely at the vendor's discretion, with no open governance to check it. For a sovereignty-minded operator, these are serious, and they are the reason this article's verdict leans away from CockroachDB for new critical deployments despite its technical excellence.
22. When CockroachDB Is Still the Right Call
There are legitimate reasons to use CockroachDB. If you already depend on it and migrating is costly, staying may be rational, especially if your deployment is stable and supported. If you need its specific multi-region, survivability, and Postgres-compatibility combination and prefer a single-vendor relationship with strong support, the managed offering is excellent. If your compliance regime accepts the vendor's Trust Portal artifacts in lieu of source audit, the closure may be acceptable. And if you are not sovereignty-sensitive — you just want a great distributed database and trust the vendor — CockroachDB remains one of the best. The closure is a factor, not a verdict, and for some teams it is irrelevant.
23. When to Choose an Open Alternative
Choose YugabyteDB or TiDB when sovereignty, source auditability, and fork-ability matter, when you want to avoid a single-vendor private-source dependency, or when you are starting fresh and can pick an open core. Both are Postgres-compatible distributed SQL systems under Apache 2.0, both are actively developed, and both give you the escape hatch CockroachDB removed. The migration cost from CockroachDB is real but manageable for most workloads because of wire compatibility, and it is far cheaper to choose open at the start than to extract yourself after commitment. For a sovereignty-minded operator building new infrastructure, the open alternative is the principled and increasingly the pragmatic pick.
24. Getting Started — and the Audit You Cannot Do
Standing up CockroachDB is well-documented: download the binary or run the container, start a multi-node cluster with
cockroach start, initialize with cockroach init, and connect with any Postgres client. The operational model — symmetric nodes, automated repair, geo-partitioning — is genuinely pleasant. The one thing you cannot do that you could with Postgres or a fork project is read the current source to understand a behavior, audit a security claim, or patch a bug yourself. You file an issue and wait for the vendor. For teams accustomed to open databases, this quiet loss of agency is the real cost of the private-source decision, and it is worth naming explicitly before you commit.
25. Reading the License, Not the Headline
The discipline this entire saga teaches applies sharply here. Verify the license against the repo: CockroachDB core is BSL converting to Apache 2.0 on a three-year delay, some features are CCL, and the newest versions are simply not published. YugabyteDB and TiDB are Apache 2.0. PostgreSQL is permissive. These facts change your risk and continuity calculus, and they are checkable. The headline "CockroachDB moved to private source" is accurate but incomplete; the precise, version-by-version license status is what you must know before deploying a system that will hold your most important data.
26. The Broader Pattern — Three Endings
CockroachDB is the third and darkest ending in the license-wave story this blog has traced. Redis, Terraform, and Elasticsearch tightened licenses and got foundation-backed forks (Valkey, OpenTofu, OpenSearch). MongoDB tightened and got a protocol-compatible reimplementation (FerretDB). CockroachDB tightened and then closed the source, getting neither — leaving users with an open historical core, an open alternative ecosystem, but no open current CockroachDB. Together these outcomes map the full range of what a license change can produce, and they should disabuse anyone of the comforting assumption that "the community will just fork it." Sometimes it cannot, and the closure is the ending.
27. The Comforting Myth of the Fork
There is a myth in open-source circles that any license tightening triggers an automatic fork that saves users. Valkey and OpenTofu fed that myth. CockroachDB is the corrective. A fork requires a current open version, a fundable engineering effort, and a community with the will and the means. Remove any one — as CockroachDB did by going private on stale-open code — and the fork does not happen. Operators who bet their infrastructure on the myth are exposed. The mature lesson is to evaluate each project's actual license posture and fork-ability, not to assume salvation is one relicensing away. Sovereignty is built by choosing open systems, not by hoping closed ones reopen.
28. What Cockroach Labs Got Right
In fairness, Cockroach Labs built a genuinely excellent distributed database and was transparent about its decisions, publishing detailed FAQs and blog posts explaining the private-source move rather than burying it. Its continued open-source library work and upstream contributions are real. Its security argument about AI-assisted source analysis is not frivolous. And it has honored existing customer agreements. None of this reverses the closure, but it means the company is not acting in bad faith — it is making a defensible business and security calculation that happens to conflict with the open-source values many of its early adopters held. Holding both truths is the honest read.
29. The Strategic Recommendation
For a sovereignty-minded operator in 2026, the recommendation this article lands on is: do not start new critical infrastructure on current-version CockroachDB. If you need distributed SQL with Postgres compatibility and open governance, choose YugabyteDB or TiDB, both of which remain Apache 2.0 and auditable. If you are already on CockroachDB and stable, weigh the migration cost honestly rather than assuming a fork will rescue you. And if you must use CockroachDB, prefer the managed offering with explicit support terms and treat the private source as a known, accepted risk. The throughline is to build on systems you can audit, modify, and fork — because the license wave has shown that the vendor's terms can change faster than your architecture can.
30. The Pebble Storage Engine and Why It Matters
One detail often overlooked in the private-source discussion is that CockroachDB did not close only the database — it also closed Pebble, its high-performance storage engine, moving Pebble's development private as well. Pebble is a key-value store inspired by Google's RocksDB and LevelDB, and it is where much of CockroachDB's write-performance and resilience engineering lives. Closing it means the heart of the system is now invisible, not just the SQL layer on top. For an operator, this deepens the audit problem: you cannot even review the component most responsible for durability and crash recovery. It also forecloses a storage-engine-level fork — there is no open Pebble to build on. The closure of Pebble is the clearest signal that Cockroach Labs' private-source decision was about protecting core IP at every layer, and it is why the "just fork the storage engine" escape route, which worked for some projects, is closed here too.
31. Migration in Practice: CockroachDB to YugabyteDB
For teams that decide the closure is unacceptable, the practical exit is YugabyteDB, the most CockroachDB-like open alternative. Because both are Postgres-wire-compatible, much of the application code — schema definitions, most SQL, and driver connections — carries over with minimal change. The migration work concentrates in three areas: dialect differences, where CockroachDB-specific syntax or functions need rewriting; feature parity, where an Enterprise CockroachDB feature maps to a YugabyteDB equivalent that may behave differently; and operational re-learning, where YugabyteDB's tablet and placement model replaces CockroachDB's range and locality model. The realistic effort is a focused, weeks-not-months project for most workloads, far cheaper than a ground-up re-platform, and the payoff is an Apache-2.0 system you can audit, modify, and fork. The lesson is that the exit exists — but choosing open at the start avoids the project entirely.
32. What Sovereign Operators Should Put in Contracts
For organizations that must use CockroachDB despite the closure — perhaps because of an existing commitment or a specific feature fit — the mitigation is contractual rather than technical. Negotiate explicit terms around source escrow, so that if Cockroach Labs ceases operations or changes terms adversely, a current source copy is released to you under agreed conditions. Require documented SLAs for security fixes with defined response times, since you cannot patch the closed engine yourself. Insist on the Trust Portal artifacts — SOC 2, SBOM, pen-test reports — as contractual deliverables, not courtesies. And build a funded exit plan: a budgeted, rehearsed migration path to YugabyteDB or TiDB, kept current so that if terms sour, the move is weeks, not a crisis. None of this restores openness, but it converts an unbounded vendor risk into a managed, priced one — which is the best a sovereign operator can do when the source has already closed.
33. The Broader Lesson for Infrastructure Buyers
Step back from CockroachDB specifically and the durable lesson for anyone buying infrastructure is to evaluate not just a project's current license but its trajectory and the preconditions for a fork. Ask four questions before committing: Is the current version actually published and auditable? Is there a recent open version a foundation could fork? Is the project simple enough that a community reimplementation is feasible? And does an open alternative already exist that meets your needs? CockroachDB fails the first two and strains the third, which is why it closed without rescue; Redis passed all three, which is why Valkey thrives; MongoDB failed the fork precondition but passed the reimplementation one, which is why FerretDB exists. A sovereignty-minded buyer uses this checklist at procurement time, because by the time a vendor goes private, the cheap options have already narrowed. The license wave has supplied the data points; the mature operator turns them into a buying discipline.
34. The Spanner Heritage and What It Costs to Rebuild
CockroachDB's technical excellence traces to a clear lineage: its founders worked on Google's Spanner and Colossus, and CockroachDB is, in spirit, an open attempt to bring globally consistent, survivable SQL to everyone. That heritage is also why it was hard to fork — replicating Spanner-class engineering is a multi-year, multi-million-dollar undertaking, not a weekend project. The open community's answer was not to fork CockroachDB but to build a parallel lineage: YugabyteDB, founded by ex-Facebook engineers with similar inspiration, rebuilt distributed SQL on an open Apache-2.0 core from the start. The cost to rebuild was paid once, in the open, and now benefits every sovereign operator who chooses it. CockroachDB's closure did not remove the capability from the world; it removed it from the open world, and the open world had already hedged by building its own. The lesson is that durable value in infrastructure eventually gets rebuilt in the open if the demand is real — but the rebuild takes years, so choose open early.
35. Three Endings, One Lesson
This article is the third ending in a trilogy of outcomes the license wave produces, and the throughline is simple. Some vendors tighten and get forked — Redis into Valkey, Terraform into OpenTofu, Vault into OpenBao, Elasticsearch into OpenSearch — because a current open version existed for a foundation to claim. Some tighten and get reimplemented — MongoDB into FerretDB — because the wire protocol was separable from the licensed code. And some tighten and then close — CockroachDB — because the code was complex, the last open version stale, and no sponsor stepped up to rebuild it in the open. The lesson for the sovereign operator is not "forks always save you" but "choose systems whose license posture and fork-ability you have verified before you depend on them." CockroachDB is the case that proves the fork is not guaranteed, and it is the reason this blog keeps telling you to read the LICENSE file before you deploy.
36. Bottom Line
CockroachDB did not die; it closed. It moved from Apache 2.0 to BSL in 2019, consolidated into a bespoke software license in 2024, and then stopped publishing new source code, leaving no community fork and no FerretDB-style reimplementation behind. For existing customers with support contracts, little changes today; for new adopters and sovereignty-minded operators, the inability to audit or fork the current engine is a serious, structural risk that the three-year conversion clause does not cure because the open version is perpetually three years stale. The open alternatives — YugabyteDB and TiDB — give you the same distributed SQL properties without the closure. The takeaway is that the fork is not guaranteed; sometimes the license wave ends in silence, and the only defense is to choose open systems from the start. Verify the license of whatever you deploy against the LICENSE file, prefer an open distributed SQL core if sovereignty matters to you, and you have made the architectural choice this entire article argues for.
Related:
Comments (0)
No comments yet. Be the first to comment!