Managed Redis and Elastic Services Under New Licenses

Managed Redis and Elastic services under new licenses sit in a blind spot that many buyers never check. When a database relicenses, the attention goes to teams that run the software themselves. Yet most enterprises consume these engines through a managed or cloud service, where a provider operates the software on their behalf. The license still changed. The exposure simply moved one layer up, into the provider relationship and the build the provider chose to run. This article explains how the new Redis and Elastic terms reach managed services, what your provider may have done about it, and the questions a buyer should ask before assuming the dependency is stable.

We write from the buyer side as an independent advisory paid only by the buyer. This is not legal advice. For interpretation of any source available license or managed service agreement, we point you to your own counsel.

Why managed services are the real target

The license changes at Redis and Elastic were not aimed at the internal user. They were aimed at providers who take the open source engine and offer it as a competing managed service. Redis moved to a model combining the Server Side Public License and the Redis Source Available License as of March 2024. Elasticsearch and Kibana moved to the Server Side Public License and the Elastic License as of 2021. The defining restriction in the Server Side Public License is the condition placed on offering the software as a service to third parties. That is precisely what a managed database provider does, which is why the providers, not their customers, felt the change first.

For a buyer, that reframes the question. You are usually not the party restricted by the Server Side Public License when you consume a managed service. The provider is. But you inherit the consequences of how the provider responded. If your provider kept running the original engine under terms it could not satisfy, your service rests on shaky ground. If it moved to a fork or its own build, your dependency is now a different piece of software with a different roadmap. Either way, the license change reached you through the provider, and you need to know which path your provider took.

What providers did in response

Providers responded in a few recognizable ways. Some moved to community forks. The Valkey fork of Redis and the OpenSearch fork of Elasticsearch were created in large part so that cloud and managed providers could continue offering a compatible engine under a permissive open source license. A managed service that quietly migrated to Valkey or OpenSearch gives you a stable open posture, but it is no longer the original project, and small behavioral differences can surface over time. Other providers negotiated commercial arrangements with the vendor, which keeps the original engine but ties your service to that commercial relationship and its pricing.

A third group built or maintained their own distribution of the engine. This can preserve compatibility while sidestepping the source available terms, but it concentrates maintenance risk in the provider. None of these responses is wrong. The point for a buyer is that the response is invisible from the outside. The service name on your invoice may be unchanged while the engine underneath it has been swapped, recompiled, or re licensed. You cannot assess the dependency without knowing which of these happened.

The questions to ask your provider

Three questions surface the exposure. First, which engine and version actually backs the service today, and is it the original project, a fork such as Valkey or OpenSearch, or a provider build. Second, under which license does the provider operate that engine, and does that license cover the way it offers the service to you. Third, how does the provider intend to handle the next relicensing event, since the pattern is continuing. The answers tell you whether your managed dependency is durable or whether it carries inherited risk that could surface as a forced migration or a price change at renewal.

If you build your own product on top of a managed Redis or Elastic service, the questions sharpen. Your product inherits whatever the provider runs, and a provider build or a fork can carry compatibility or support implications you will own. This connects directly to the broader concern we cover in database relicensing and your cloud provider, and to the provider side restrictions described in MongoDB, the Server Side Public License, and service providers.

When you are the provider

Some enterprises are providers without using the word. If you operate Redis or Elasticsearch as a shared internal platform that other business units consume as a service, or if you embed the engine in a product you offer to customers, your deployment can look more like the provider case than the consumer case. That is the pattern the Server Side Public License is written to reach, and it is the pattern most worth checking against the actual terms with your counsel. The exposure is not theoretical here. It depends on whether your service offering meets the restriction, which is a question of fact about how you deploy and to whom.

Where that pattern exists, a buyer has the same options a commercial provider has: move to a fork such as Valkey or OpenSearch, negotiate a commercial license, or restructure the deployment so it no longer meets the restriction. Each carries a different engineering and commercial cost, which is the work of our open source remediation advisory. Confirming whether your Redis use even falls inside the change is the first step, covered in is your Redis use affected by the license change.

What a buyer should do first

List every managed or cloud Redis and Elastic service in your estate, then for each one record the answers to the three provider questions. Separate the services where you are simply a consumer, where the provider carries the license burden, from the deployments where you operate the engine as a service yourself. For the first group, the work is mostly assurance, confirming the provider's posture and noting it. For the second, the work is real remediation planning. The map turns a vague worry about managed databases into a defined list of stable dependencies and a short list of items that need a decision.

Managed services do not exempt you from the relicensing wave. They relocate the exposure into the provider relationship, where it is easy to miss. For the full landscape, see the Redis, Elastic, and database licensing pillar.