Red Hat Data Grid and Redis, two caches, two contracts.

Red Hat Data Grid is the Red Hat supported distribution of Infinispan, an open source distributed data grid and cache project under Red Hat stewardship. Red Hat Data Grid sits inside the JBoss Middleware portfolio and is sold under a node level subscription that mirrors the JBoss EAP and AMQ purchasing motion. A buyer who runs JBoss EAP on a per core or per socket pair model already has the procurement relationship and the support escalation chain that Data Grid would slot into1.

Redis is the open source in memory key value store originally written by Salvatore Sanfilippo. The commercial distribution is Redis Enterprise, sold by Redis Ltd under its own subscription model that scales by node count, by shard, and by data set size depending on the deployment topology. Redis Ltd also operates Redis Cloud under a usage based model on the major hyperscalers. The buyer who chooses Redis Enterprise is opening a new vendor relationship and a new support contract that runs in parallel to the existing Red Hat estate2.

The license posture for an open source Redis deployment that the buyer self supports differs again, and changed substantively in 2024 when the Redis project changed its license from the BSD three clause licence to a dual SSPL and RSAL licensing model. The 2024 licence change does not affect a buyer running an in cluster cache for internal traffic. It does affect a buyer who would have offered Redis as a managed service to external customers. The buyer side decision should treat the license posture as part of the procurement narrative, not as an afterthought3.

The Data Grid contract differs from the Redis Enterprise contract in three structural ways. The first difference is the entitlement unit. Data Grid is metered at the node level, with a node defined as a JVM that holds a Data Grid cache. The unit aligns naturally with a Kubernetes pod when Data Grid is deployed as an operator on OpenShift. Redis Enterprise meters at shard count, where each primary shard plus its replicas is counted against the contract; the same usable cache footprint reads at very different shard counts depending on the replication and sharding profile.

The second difference is the support model. Data Grid support flows through Red Hat's existing support tiers, which the buyer already touches for OpenShift, RHEL, and JBoss. A single ticket against the Data Grid layer is one phone call into a support relationship the operations function has on speed dial. Redis Enterprise support flows through Redis Ltd's own support tiers; the buyer's operations function manages two relationships in parallel and is the integrator between them when an incident crosses the boundary4.

The third difference is the audit posture. Red Hat's audit team can read Data Grid usage through the same channels it reads JBoss EAP and OpenShift usage, with the standard subscription manager attach and the OpenShift operator inventory as evidence. Redis Ltd has its own audit posture and its own evidence channels. A buyer that runs both products carries both audit calendars; a buyer that runs only one carries the corresponding one and reads cleanly against it.

The first economic pattern is the JBoss heavy estate that adds a cache. A buyer who already runs JBoss EAP and AMQ adds Data Grid under the existing master agreement, often at a concession band the buyer has already negotiated. The incremental procurement work is small, the support model is familiar, and the audit calendar does not lengthen. Redis Enterprise in this case adds a new vendor relationship that the buyer has to procure, contract, and operate separately.

The second pattern is the OpenShift heavy estate with no JBoss footprint. The buyer's Red Hat relationship covers OpenShift but not the broader middleware portfolio. Data Grid is available on the operator catalogue and rides the OpenShift relationship cleanly. Redis Enterprise is also available on the OpenShift operator catalogue but the contract sits with Redis Ltd, not Red Hat. The cost question depends on which vendor the buyer is willing to lengthen its calendar with5.

The third pattern is the cache that already runs on open source Redis at scale and the engineering team is happy. The procurement question is whether to add a paid support layer for the operational comfort and whether to choose Redis Enterprise or Red Hat Data Grid as the migration target. A migration from open source Redis to Red Hat Data Grid is non trivial and is rarely worth the engineering cost on its own; the migration is worth doing only if the broader Red Hat relationship is being expanded for other reasons. The procurement function should not chase a contractual symmetry that the engineering team will resent.

The buyer side discipline at the procurement table is a workload narrative that names the cache requirement, the access pattern, the durability target, the team that will operate the cache, and the vendor relationships the buyer already maintains. The procurement function reads the narrative against quotes from both vendors and chooses the contract that lengthens the calendar in the direction the buyer was already willing to lengthen. The technology choice follows the contract choice once the buyer is honest about which vendor relationship is easier to scale.

For the broader cross product reading, see the JBoss practice hub, the JBoss Data Grid licensing read for the older entitlement model that some buyers still carry, the Red Hat Build of Quarkus licensing read for the broader Red Hat middleware portfolio, the Application Foundations bundle economics read for the bundle that often includes Data Grid, and the AMQ Streams licensing read for the comparable Kafka offering. For the engagement protocol, see renewal negotiation and contact.

Red Hat Data Grid and Redis Enterprise sit at the same workload boundary with very different procurement consequences. The cheaper contract is the one that the buyer's existing vendor portfolio absorbs without adding a new audit calendar; the more expensive contract is the one that opens a parallel vendor relationship for a single workload. The buyer who treats the cache decision as a procurement decision rather than a benchmark decision tends to ship the right contract.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.