Forking Versus Paying: The Database Decision

When a vendor relicenses a database and a fork appears, the choice can feel binary and urgent. It is neither. It is a structured trade between two real costs, and the buyers who fare best are the ones who treat it as such. The vendor would prefer you decide quickly and pay. The fork community would prefer you migrate. Your interest is in the option that holds up over years, and that requires counting what each path actually costs before committing to either.

Why the decision exists at all

The relicensing wave created forks by design. When a project moves to a source available license, a community that wants an open licensed path forks the last open version and continues it. As of March 2024, Redis moved to a dual model under the Redis Source Available License version 2 and the Server Side Public License, and the Valkey fork followed under a foundation. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021, and the AWS led OpenSearch fork followed. MongoDB moved to the Server Side Public License in 2018. Source available is not open source, and these licenses are not approved by the Open Source Initiative. The fork exists precisely so that buyers have an alternative to the commercial path, which is what makes forking versus paying a genuine decision rather than a foregone one. The wider context sits on the Redis, Elastic and databases pillar.

What forking actually costs

A fork carries an open license and no recurring fee, which is the headline saving. It is not free of cost. Moving to Valkey or OpenSearch means migration work, compatibility testing, updates to tooling and client libraries, and retraining for the teams that operate the database. It also means accepting a different project roadmap, governed by a different community, which may diverge from the vendor product over time. For a drop in compatible fork the effort can be modest, especially where the fork tracks the prior version closely. For a deployment that leans on vendor specific features the effort can be substantial. The license saving is real, and so is the engineering bill, and a sound decision counts both.

The cost of a fork also depends heavily on how deeply the database is woven into your systems. A cache behind a single service is a contained migration. The same database under forty services is a program of work. Knowing which case you are in is the difference between a confident move and a stalled one, and it is the same blast radius question that runs through all relicensing exposure. The general method for sizing it is set out in commercial licensing for Redis Enterprise.

When paying is the better answer

Paying for a commercial license wins in a recognizable set of cases. The first is feature dependence: if you rely on capabilities that exist only in the vendor product and not in the fork, forking means rebuilding them, which can cost more than the license. The second is support and indemnity: regulated and high availability environments often need vendor backing and contractual assurances that a community fork does not provide. The third is timeline: when a migration would touch critical systems on a short deadline, the commercial license buys time and continuity. The fourth is a genuine license trigger: where your use actually falls under the restricted conditions of the source available license, a commercial agreement resolves it directly.

In these cases paying is not capitulation. It is the cheaper and safer path on a full accounting. The error is not paying. The error is paying without having weighed the fork, because that is how a list price becomes the default rather than the considered choice. Structuring a commercial agreement from the buyer side, once it is the right answer, is the work of an open source commercial license negotiation engagement.

How to keep leverage whichever way you lean

The most valuable position is to hold both options open for as long as possible. A buyer who can credibly move to a fork negotiates a commercial license on far better terms than one who has visibly committed to paying. Credibility is the key word. The fork option only creates leverage if it is real, backed by a dependency map that shows the migration is feasible and scoped. Without that evidence the threat to fork is empty and the vendor knows it. With it, the same evidence that would guide a migration also disciplines the price of staying.

This is why the analysis comes before the decision. Mapping where the database runs, which version and license each instance carries, and what a fork would actually require gives you both the basis to choose and the leverage to negotiate. Sequencing that work so it contains the exposure without disrupting delivery is the job of an open source remediation advisory engagement. We are independent and buyer side. We take no vendor fees and resell no software, and we do not profit from either a fork or a license, so the recommendation reflects your risk and nothing else. This is commercial and licensing risk advisory, not legal advice. For interpretation of the relevant licenses against your use, engage your own counsel.