Database relicensing and high availability clusters.

Database relicensing and high availability clusters are easy to think about separately and costly to keep apart. The relicensing wave of recent years moved Redis, Elastic, and others from open source to source available terms, and the analysis usually stops at the database. But production databases rarely run as a single node. They run as clusters of primaries, replicas, and standbys spread across zones and regions, and a license change reaches all of them. The node that serves writes and the passive standby waiting for failover carry the same license, and under many commercial models they carry the same cost. This guide looks at where the exposure hides in a clustered topology and how to size and contain it.

Why a cluster multiplies relicensing exposure

A high availability cluster exists to remove single points of failure, so it runs several copies of the same software. When that software relicenses, the new terms apply to each running copy. Source available terms such as the Server Side Public License restrict competitive and managed service use regardless of which node in the cluster is active. Commercial licensing, where it applies, is often metered by node, core, or instance, which means a three node Redis cluster or a multi node Elasticsearch deployment can carry three or more times the license footprint of a single server. The resilience you built for uptime becomes a multiplier on the exposure a single relicense creates. The wider pattern is set out in our pillar on Redis, Elastic, and database relicensing.

Do replicas and standby nodes count?

This is the question that decides the size of a commercial quote, and the answer lives in the vendor metric. Some models count every node that has the software installed and running, including passive standbys that serve no traffic. Others count only active nodes, or meter by memory or core rather than by node. A cluster engineered for failover can hold many idle replicas, and whether those nodes fall inside the count can change the cost by a wide margin. Read the metric in the actual agreement rather than assuming the friendliest reading, and treat the interpretation of how it applies to your topology as a question for your own counsel. The same care applies to managed offerings, which we cover in managed Redis and Elastic services under the new licenses.

Mixed versions during a cluster migration

Clusters are usually upgraded node by node to preserve availability, which means that during a migration the same cluster can run nodes on different versions and therefore different license terms at the same time. A rolling upgrade that crosses the relicense boundary can put some nodes under an open source version and others under source available terms within a single deployment. This complicates both compliance and support, because the version on each node sets the terms that govern it. The practical consequence is that an inventory must track license state per node, not per cluster, or it will report a single status for a topology that actually holds several.

Multi region and disaster recovery topologies

Disaster recovery and multi region designs push the question further. A warm standby in a second region, a cross region replica kept for read locality, and a cold backup cluster restored only during a drill are all instances of the relicensed software. Whether a dormant disaster recovery cluster counts under a commercial metric is exactly the kind of edge that vendors and buyers read differently. Map these nodes explicitly, because they are the ones most likely to be missed in an inventory built around production traffic, and they are the ones a vendor audit is most likely to surface. Cloud hosted replicas raise a related question, covered in database relicensing and your cloud provider.

Containing the exposure across the cluster

Containment begins with a node level inventory that records version and license state across the full topology, including replicas, standbys, and recovery nodes. With that map, the same paths apply as for any relicensed database, sized now to the real node count: migrate the whole cluster to an open license fork such as Valkey or OpenSearch, hold on an open source version where no live trigger applies, or negotiate a commercial license priced to the actual nodes rather than a list metric. The decision between leaving and paying is weighed in forking versus paying as a database decision.

Whichever path you choose, sequence any cutover node by node behind replication so availability is preserved throughout. Promote a migrated replica, validate it, then move the next, keeping the cluster serving the whole time. This is the same discipline that keeps a database online during a version upgrade, applied to a license change, and it turns a clustered migration from a risky single switch into a controlled sequence.

Scoping and sequencing a clustered migration is the work of our open source remediation advisory service. Interpretation of how a license metric applies to your specific topology is a question for your own counsel.