Data Grid, read at the node.

Red Hat Data Grid is the commercial distribution of the Infinispan in memory data grid, productised by Red Hat with certification, hot patches, and a support entitlement. The product entered the Red Hat middleware portfolio as JBoss Data Grid in 2010, with the brand consolidation to Red Hat Data Grid in subsequent releases. The Infinispan core has been a stable upstream project; the commercial wrapper is the Red Hat product.1

Data Grid runs in two architectural modes. In embedded mode, the grid runs inside the address space of the application that uses it, with the cache instance created and held by the application. In server mode, the grid runs as a standalone process that the application connects to over a network protocol, typically Hot Rod or REST. The two modes have the same underlying engine; they have different operational shapes and they have different licensing readings.

In commercial circulation in 2026, Data Grid is metered on a node based subscription. A node is a running member of the grid, regardless of mode. In server mode, the node count is the count of standalone server processes that form the cluster. In embedded mode, the node count is the count of application instances that contain a grid member. The buyer side reading at signature turns on this distinction. For the wider JBoss middleware practice, see the JBoss and Middleware practice hub.

In server mode the meter is clean. The Data Grid cluster is a discrete fleet of server processes, the count is the cluster size, and the entitlement covers the count. A buyer that operates a five node Data Grid cluster has five node entitlements. The host topology that the five nodes run on is operationally relevant for performance and failover but is not the meter. Whether the five nodes run on five physical hosts, on five virtual machines, on five containers, or on five pods is incidental to the count itself.2

In embedded mode the meter is the trap. Each application instance that loads an embedded grid is a grid member. A buyer that runs an application across fifty Java virtual machines, with the embedded grid loaded in each, is running a fifty node grid for licensing purposes, even though the application team may think of the grid as a single logical cache. This is the most expensive reading on Data Grid in 2026 renewals where the embedded mode footprint has grown without the entitlement being resized to match.

The defensible response on an embedded deployment that exceeds the entitlement is twofold. First, audit the application instance count that loads the grid; the count is often smaller than the seller side initial reading where some instances are warm spares, build pipeline workers, or short lived test runners. Second, evaluate the migration to server mode, which separates the grid lifecycle from the application lifecycle and produces a cleaner meter where the deployment topology has grown beyond what embedded mode comfortably licenses.

Three traps recur on the Data Grid line in 2026 renewal proposals. The first is the embedded mode growth trap, where application teams have scaled the application without an explicit conversation about the grid footprint, and the entitlement has not kept pace. The buyer side response is to audit the actual loaded instance count and to evaluate either a defensible right sizing or a mode migration to server mode.3

The second trap is the client only count, where the proposal reads applications that connect to a server mode grid as a client as if they were grid members themselves. A client only application is not a grid member; it does not hold cache data, it does not participate in the cluster topology, and it does not count under the node meter. The defensible response is to refuse the client only line and to count only the server processes.

The third trap is the version drift line, where the proposal reads multiple versions of Data Grid running in parallel as if each version required separate entitlement. Where the same subscription period covers the deployment, the version mix is operationally relevant but is not a meter on its own. The defensible response is to read the total node count across versions and to refuse a per version line that double counts.

Container topology adds a specific reading for Data Grid in 2026. The standard server mode deployment on OpenShift in 2026 is operator managed, with the Data Grid operator handling the cluster lifecycle on the platform. Each Data Grid pod is a node; the cluster size in pods is the node count under the meter. The OpenShift entitlement on the cluster nodes is a separate meter; the two do not stack.4 For the OpenShift side, see the OpenShift practice hub and the OpenShift core counting article.

Embedded mode in a containerized application requires additional care. Each container running the application instance with the embedded grid is a node. A horizontally scaled application that runs ten pods is a ten node grid. The same trap that recurs in virtual machine estates recurs here: the application team thinks of the grid as one logical cache and the meter reads each instance as a node. The reconciliation is the same: audit the actual pod count that loads the embedded grid, and evaluate the mode migration where the count has grown beyond the entitlement.

The cloud reading follows the same principle. Data Grid nodes in a cloud topology are the running grid members across whatever cloud compute the deployment uses, regardless of cloud provider. The cloud provider's compute billing is independent of Red Hat's node entitlement; the buyer pays both, but for different things.

The buyer side reading at Data Grid renewal proceeds in five steps. First, inventory the actual Data Grid deployments, distinguishing server mode from embedded mode and noting the version. Second, count the nodes that load Data Grid in each deployment, by mode. Third, sum the node counts across the estate to produce the total entitled nodes required. Fourth, where the embedded count is larger than expected, evaluate the migration to server mode as both a meter optimisation and an operational improvement. Fifth, sign the Data Grid line at the documented node count, with the documentation retained for any subsequent audit inquiry.5

Across recent practice engagements, the discipline has produced a recoverable correction on Data Grid renewals where the embedded mode footprint had grown invisibly to the application teams or where the proposal had read client only applications as grid members. Where the prior reading already correctly tracked the node count by mode, the correction was smaller and the conversation moved to multi year structuring.

The corollary on the audit side is that a Red Hat Data Grid finding that reads embedded instances at a count higher than the actual loaded instances, or that reads client only applications as members, is a finding that does not survive a clean mode by mode reconciliation. For the audit defense engagement, see audit defense; for the renewal engagement, see renewal negotiation; for direct contact, see the contact page.

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.