In-Memory Data Grids Compared: Hazelcast, GemFire, Ignite, Coherence

An in-memory data grid (IMDG) is a cluster of machines that pool their RAM to hold and process a shared dataset, partitioned across members with backup copies for fault tolerance. Java teams reach for one when a single cache server stops being enough and they need distributed maps, locks, and coordination that survive a node failure.

The category has changed considerably. Some products are shipping actively, one came back from a formal decision to shut it down, one has repositioned itself as a distributed SQL database, and one sits behind an authenticated repository whose access rules tightened this year. This guide covers what an IMDG actually is, how the major options compare in 2026, the honest test for whether you need a grid at all — and where a client to Valkey or Redis covers the same ground with less to operate.

What Is an In-Memory Data Grid?

A data grid coordinates many machines to work on one job. An in-memory data grid narrows that to a specific architecture: a peer-to-peer cluster of JVM members that hold application data in RAM, with a handful of defining traits.

• Partitioning with backups. Data is sharded across members so the dataset can exceed any one machine's memory, and each partition has one or more backup copies on other members so a node loss doesn't lose data.
• Data structures, not tables. You work with distributed maps, queues, sets, and topics that implement familiar java.util interfaces — not rows and SQL.
• Near cache. Hot entries are kept in the accessing process for local-speed reads, with an invalidation mechanism to keep them honest.
• Colocated compute. You can send code to run on the member that owns a key, avoiding get-modify-put round trips.
• Embedded or client/server. A grid can run inside your application JVMs — your app instances are the cluster — or as dedicated members you connect to.
• Cluster membership. Members discover each other, detect failures, rebalance partitions, and guard against split-brain. This is the operational weight of a grid.

That last point is the one teams underestimate. A grid isn't a library you add; it's a distributed system you run, size, tune, and upgrade.

IMDG vs. In-Memory Database vs. Distributed Cache

These terms get used interchangeably and shouldn't be.

The line between a grid and a cache is genuinely blurry, and most teams describing themselves as "on a data grid" are using it as a distributed cache with locks. That observation is the crux of this guide.

Is Redis an In-Memory Data Grid?

Not by the strict definition. Redis and Valkey are in-memory data structure servers: you run them separately and clients connect over the network. They partition data across a cluster and replicate it, but they don't run inside your JVMs, don't execute your Java code on the node owning a key, and don't form a peer-to-peer member cluster with your application.

What closes most of the practical gap is the client. Redisson gives Java applications distributed maps, locks, queues, and near-caches on top of Valkey or Redis, with the same programming model a grid provides. So the accurate framing is not "Redis is a data grid" but "for the data-structure and coordination work most people use a grid for, a Valkey or Redis server plus Redisson covers it — without the grid to operate."

The Landscape in 2026

Hazelcast Platform

The most actively developed grid in the category. Platform 5.7.0 shipped in May 2026 with Java 25 LTS support and Advanced CP Subsystem work including CP leader auto step-down for multi-data-center deployments; the minimum supported Java is 17. It combines a data store with a stream-processing engine (the former Jet).

The licensing detail that matters: Community Edition is covered by the Apache License 2.0 and the Hazelcast Community License, and the Enterprise Edition holds the security suite (TLS, authentication, encryption), WAN replication, persistence, and the persistent Advanced CP subsystem. Community users receive CVE fixes only in major and minor releases, while Enterprise customers get patches as they're ready.

Note that the older Hazelcast IMDG product line is frozen — 4.2.8, from May 2023 — and Jet at 4.5.4 from December 2021. Both were folded into Platform.

VMware Tanzu GemFire

The commercial descendant of technology GemStone Systems introduced in 2002, now a Broadcom product at version 10.2. It's Region-centric — a Region being essentially a distributed map — operated as a cluster of locators and servers, with strong transactional guarantees and a long track record in financial services.

GemFire is closed-source and subscription-only, and its artifacts sit behind an authenticated Broadcom repository. That gate tightened in January 2026, when legacy per-product download tokens were retired in favour of a centralized Registry Token generated from the Broadcom Support Portal — every developer machine and CI runner needs credentialed access to build. GemFire 10 also moved all inter-server traffic to TCP, dropping the UDP/JGroups path used for membership in earlier versions, and is certified for JDK 8, 11 and 17, with JDK 11 preferred from 10.0 — a notably more conservative Java baseline than the rest of the category.

Apache Geode

The Apache-2.0 core donated to the ASF in 2015, and the most interesting story in the category. Geode's contributor base thinned after 2019, development stopped by mid-2023, and the project management committee voted to terminate the project in 2024. Contributors then revived it: 1.15.2 shipped in September 2025, and Geode 2.0 was tagged in December 2025 and announced by the ASF in January 2026.

2.0 is a genuine modernization rather than a maintenance release — Java 17 baseline, Jakarta EE 10 migration, Gradle 7, Jetty 12, updated Spring Framework and Spring Security, Java Module System compliance, and removal of unsafe reflection. The honest caveat is that this was carried by a small volunteer community; the release manager has publicly described it as nights-and-weekends work. It's a real option again, but not a funded one.

Apache Ignite

Ignite maintains two lines: 2.x as long-term support and 3.x as the forward path. Ignite 3 is deliberately repositioned — the project describes it as a distributed database for high-performance computing, built around a schema-driven architecture with distributed SQL over JDBC and ODBC, ACID transactions at serializable isolation, pluggable storage engines, and a unified CLI and REST API.

Worth being clear about: Ignite is drifting out of the IMDG category toward distributed SQL database. If you're comparing grids for distributed maps and locks, Ignite 3 is solving a somewhat different problem than Hazelcast or GemFire. Apache 2.0, ASF top-level project. See our Redis vs. Apache Ignite comparison for the detail.

Infinispan / Red Hat Data Grid

Red Hat's Apache-2.0 grid, usable as an embedded Java library or a standalone server, with Red Hat Data Grid as the supported commercial edition. Release 16.2 is current, following 16.1 in February 2026 under a newly time-boxed release plan.

One requirement to plan for: from 16.1 the server requires Java 25 for bare-metal deployments (the container image already did from 16.0). Clients may still run older Java. That baseline let the server adopt Lucene 10.3 with SIMD acceleration and ship an AOT cache to cut startup time. It's an aggressive Java requirement relative to the rest of the category.

One detail worth knowing if you're weighing Infinispan against Redis specifically: Infinispan ships a RESP endpoint that speaks the Redis wire protocol, so a standard Redis client library can address it. Coverage has expanded steadily across the 16.x line.

Oracle Coherence

The enterprise incumbent, with strong gravity in Oracle and WebLogic shops. Coherence Community Edition is published on GitHub under the Universal Permissive License v1.0, alongside the commercial Enterprise and Grid Editions.

Versioning takes a moment to parse, because two schemes run in parallel: date-based CE releases on a roughly six-monthly cadence (22.06, 23.09, 24.03, 25.03 and so on, with periodic long-term-support releases) and a 14.1.x / 15.1.x numbering aligned with the commercial editions. Recent CE releases have tracked Java aggressively — 25.03 runs on Java 21 and 24 — and one date matters if you're on the first LTS: 22.06 reached the end of its four-year support window on 30 June 2026.

Looking forward, Oracle has said the next major release of WebLogic Server and Coherence will land in calendar 2026, designated version 26, with Jakarta EE 11 and JDK 25 support — a renaming that aligns Coherence with Oracle's wider release numbering.

Others worth naming

GigaSpaces and GridGain (the commercial distribution built on Ignite) remain in the market. IBM WebSphere eXtreme Scale is largely a legacy concern at this point; we cover it separately in Valkey & Redis vs. WebSphere eXtreme Scale. Ehcache is a different category — a JVM-local cache that can be clustered through Terracotta rather than a peer-to-peer grid — and is covered in Ehcache to Redisson.

Head-to-Head Comparison

Common Comparisons

Hazelcast vs. GemFire

The clearest split is openness and momentum. Hazelcast ships a source-available Community Edition from public Maven and releases frequently; GemFire is closed-source, subscription-only, and gated behind an authenticated repository. Hazelcast adds stream processing and distributed SQL that GemFire doesn't have; GemFire brings OQL, continuous queries, and a transactional pedigree in financial services that many teams still rate highly.

The counter-argument for GemFire is support model: one vendor, one support contract, a stable product. The counter-argument for Hazelcast is that its most important capabilities — security, persistence, WAN replication, the persistent CP subsystem — are also behind a commercial license, so "open source" doesn't mean "free for production" in the way it first appears.

Hazelcast vs. Apache Ignite

Increasingly not a like-for-like comparison. Hazelcast remains a data grid with stream processing; Ignite 3 has repositioned around distributed SQL and ACID transactions. If your workload is distributed maps, locks, and caching, Hazelcast is the closer fit. If you want SQL over a distributed dataset with serializable transactions, Ignite is built for it and Hazelcast's SQL is secondary to its data-structure model.

GemFire vs. Redis

Different architectures rather than competing feature sets. GemFire is a grid you stand up and operate; Redis or Valkey is a server you point clients at — frequently one your organisation already runs. GemFire keeps OQL, continuous queries, and function execution; Redis with Redisson gives you a wider object model, async and reactive APIs, and managed-cloud options. Our full feature comparison goes row by row.

Coherence vs. Hazelcast

Mostly decided by what you already run. Coherence has deep integration with WebLogic and the Oracle stack and a support relationship most Oracle shops already have; Hazelcast is the more common choice in teams without that gravity, with a lower barrier to trying it and a more active open-source presence.

Do You Actually Need a Data Grid?

This is the question worth asking before comparing products, and for a large share of teams the honest answer is no.

Keep the grid if you depend on any of these:

• Compute on the data. Entry processors or function execution — sending code to the member that owns a key, executed serially per key. If you're doing read-modify-write on hot keys at volume, this is genuinely hard to replace.
• Distributed SQL or OQL over the grid, especially with joins, aggregations, or continuous queries pushing change events to clients.
• Embedded, in-JVM data. If your latency budget can't absorb a network hop, data living in the same process is a real architectural advantage.

You may not need one if your usage looks like this:

• The grid is a distributed cache, data-structure store, and lock layer — maps, queues, topics, counters, and coordination.
• You already run Valkey or Redis elsewhere and are operating two distributed systems where one would do.
• Cluster sizing, member discovery, split-brain protection, and partition tuning are consuming engineering time out of proportion to what you get.
• You need TLS and authentication and are being asked to buy a commercial license for them.

None of this means a grid is the wrong tool. It means a full data grid is more platform than many teams using it for distributed data structures actually need.

The Valkey and Redis Alternative

If you landed in the second list, the alternative is a Valkey or Redis server with a Java client that provides grid-style objects. Redisson implements 60+ distributed objects that implement familiar java.util and java.util.concurrent interfaces, so the programming model largely carries over from a grid.

A Hazelcast IMap or a GemFire Region becomes an RMap:

// Hazelcast
IMap<Long, String> map = hz.getMap("products");

// GemFire
Region<String, String> region = cache
        .<String, String>createClientRegionFactory(ClientRegionShortcut.PROXY)
        .create("products");

// Redisson — RMap implements java.util.concurrent.ConcurrentMap
RMap<Long, String> map = redisson.getMap("products");
map.put(1L, "Widget");

A near cache becomes RLocalCachedMap, which keeps hot entries in the application process and invalidates them cluster-wide over pub/sub:

LocalCachedMapOptions<Long, String> options = LocalCachedMapOptions.<Long, String>defaults()
    .cacheSize(1000)
    .syncStrategy(LocalCachedMapOptions.SyncStrategy.INVALIDATE);
RLocalCachedMap<Long, String> localMap = redisson.getLocalCachedMap("products", options);

Locks are where grid users ask the sharpest questions, and the answer is better than most expect. Hazelcast's FencedLock hands out a monotonic fencing token so a protected resource can reject a stale writer; Redisson's RFencedLock implements the same mechanism, and a plain RLock adds a watchdog plus an on-by-default replica-synchronization check.

// Hazelcast — CP (Raft) FencedLock
FencedLock lock = hz.getCPSubsystem().getLock("order:1234");
long fence = lock.lockAndGetFence();

// Redisson — same fencing-token mechanism
RFencedLock rlock = redisson.getFencedLock("order:1234");
long token = rlock.lockAndGetToken();

Beyond that: per-entry TTL via RMapCache, an executor service and scheduler, distributed locks in fair, read/write, semaphore and latch variants, and sync, async, Reactive and RxJava3 APIs on every object. TLS and authentication come with the Apache-2.0 community edition, because they're the Valkey or Redis server's job rather than a licensed client feature.

Everything described above is in the Apache-2.0 community edition. Redisson PRO adds data partitioning of a single structure across cluster nodes, an ultra-fast engine, additional local-cache implementations, reliable messaging with a JMS provider, and enterprise support — the capabilities most relevant to teams replacing a grid at scale.

Migration Paths

If you've decided to move, we maintain a guide for each starting point:

• Hazelcast — object mapping, fenced locks, near cache, and the CP subsystem question.
• GemFire and Apache Geode — Regions to RMap, plus the Spring Cache and Spring Session swap.
• Apache Ignite
• Ehcache — moving from a local cache to a distributed one.

For patterns rather than products, see distributed caching in Java with Valkey and Redis.

Frequently Asked Questions

What Replaced Hazelcast IMDG?

Hazelcast Platform. The IMDG and Jet products were merged into a single platform; the standalone IMDG line stopped at 4.2.8 in May 2023 and Jet at 4.5.4 in December 2021.

Is Apache Geode Still Maintained?

Yes, though it came close to ending. The PMC voted to terminate the project in 2024; contributors revived it and Geode 2.0 was tagged in December 2025 with a Java 17 baseline and Jakarta EE 10 migration. It's an active project again, driven by a small volunteer community.

Is GemFire Open Source?

No. Apache Geode is Apache-2.0 and openly available; VMware Tanzu GemFire is Broadcom's closed-source commercial product, distributed through an authenticated repository requiring a Registry Token.

Do I Still Need to Run a Cluster with Redisson?

Not a grid. You run Valkey or Redis — single node, cluster, sentinel, or a managed service such as ElastiCache, MemoryDB, Azure Cache, or Memorystore — and Redisson connects as a client. For most teams that's infrastructure they already operate.