Hazelcast vs Redis: Migrating from a Data Grid to Redisson

If you use Hazelcast for distributed maps, caching, locks, and other shared data structures, and you've wondered whether you could get the same thing on Redis or Valkey, this guide is for you. The short answer is yes — Redisson is a Java client for Redis and Valkey that offers the same kind of distributed objects Hazelcast does (RMap, RLock, RQueue, and 60+ more), so your programming model largely carries over.

The important thing to be clear about first is what kind of move this is. Unlike swapping one Redis client for another, Hazelcast and Redisson sit on different architectures. Hazelcast Platform (formerly Hazelcast IMDG) is a distributed in-memory data grid and compute platform: a peer-to-peer cluster of members that hold your data and its backups, running either embedded in your JVMs (your application instances are the cluster) or in client/server mode with dedicated members. Redisson is a client to a Redis or Valkey server you run separately. So this migration isn't about feature gaps — both have distributed data structures — it's about architecture and operations: moving from operating a data-grid cluster to using the Redis or Valkey you very likely already run. That's the reason most teams make the switch, and it's the lens for everything below.

Signs You're Ready to Move Off Hazelcast

• You use Hazelcast mainly as a distributed cache, data-structure, and lock layer — not as a compute grid — so you're operating a whole clustered platform for a subset of what it does.
• You already run Redis or Valkey elsewhere in your stack and would rather consolidate on it than maintain a second distributed system.
• You want to shed the operational weight of a data grid: cluster sizing, member discovery and coordination, split-brain protection, and partition/backup tuning.
• You need security — TLS, authentication, encryption — without an Enterprise license (more on that below).

None of these mean Hazelcast is doing anything wrong. They're the point at which a full data grid is more platform than a team using it for distributed data structures actually needs.

Hazelcast vs. Redisson at a Glance

What Hazelcast Does That Redisson Doesn't

This is the honest boundary, and it's worth stating plainly before the migration steps: Hazelcast is a compute platform, not only a data store, and a few of its capabilities have no direct Redisson equivalent.

• Entry processors — you send Java code to run on the data, on the member that owns each key, executed serially per key. That avoids the get-modify-put network round trips you'd otherwise make and is genuinely powerful for bulk updates and read-modify-write on hot keys.
• Distributed SQL — Hazelcast can run SQL (including INSERT/UPDATE/DELETE, aggregations, and joins) over its maps and over streams, and can query external sources like Kafka or object storage.
• Embedded, in-JVM data — because Hazelcast can run inside your application process, compute runs where the data lives with no network hop, which is a real latency advantage for some workloads.

If those are central to your system, Hazelcast is the right tool and you should keep it — at least for those parts. Redisson is a client to a data server: it gives you distributed data structures, caching, locks, and coordination, not an in-process compute grid or a stream processor. The rest of this guide is for the very common case where you're using Hazelcast for the data structures, cache, and locks — where Redisson on Redis or Valkey is the simpler operational fit.

What Carries Over to Redisson

The distributed-objects programming model is the part that transfers cleanly. Hazelcast's IMap becomes Redisson's RMap (both implement java.util.concurrent.ConcurrentMap), and the same holds across the board: sets, lists, queues, topics, atomics, and executor services all have R-prefixed counterparts that implement the familiar java.util and java.util.concurrent interfaces. Near caching, per-entry TTL, distributed locks, and pub/sub all have direct equivalents. The mapping section below walks through them.

Compatibility

Redisson connects to Redis 3.0+ and Valkey 7.2.5+, via the redis://, rediss://, valkey://, and valkeys:// schemes, including managed services such as AWS ElastiCache and MemoryDB, Azure Cache, and Google Cloud Memorystore. Where a Hazelcast cluster is infrastructure you stand up and run, Redisson points at a Redis or Valkey endpoint — often one you already operate.

Migrating the Data Structures

Connection

The starting point is the biggest conceptual change: a Hazelcast member (or client) becomes a Redisson client.

// Hazelcast — an embedded member; this JVM joins or forms the cluster
HazelcastInstance hz = Hazelcast.newHazelcastInstance();
// (client/server mode: HazelcastClient.newHazelcastClient())

// Redisson — a client to the Redis/Valkey you already run
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
RedissonClient redisson = Redisson.create(config);

For a cluster, Redisson uses config.useClusterServers().addNodeAddress(...); it also supports replicated, sentinel, and master/slave modes.

Maps

// Hazelcast
IMap<Long, String> map = hz.getMap("products");
map.put(1L, "Widget");
String value = map.get(1L);

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

Near Cache

Hazelcast's near cache keeps hot entries in the accessing process; Redisson's RLocalCachedMap does the same and invalidates local copies across the cluster over pub/sub.

// Hazelcast — near cache configured on the client/member map config
NearCacheConfig nearCacheConfig = new NearCacheConfig("products");
// e.g. clientConfig.addNearCacheConfig(nearCacheConfig);

// Redisson — RLocalCachedMap: local-speed reads, cluster-wide invalidation
LocalCachedMapOptions<Long, String> options = LocalCachedMapOptions.<Long, String>defaults()
    .cacheSize(1000)
    .syncStrategy(LocalCachedMapOptions.SyncStrategy.INVALIDATE);
RLocalCachedMap<Long, String> localMap = redisson.getLocalCachedMap("products", options);

Per-Entry TTL

// Hazelcast — IMap supports a per-entry TTL
IMap<Long, String> map = hz.getMap("products");
map.put(1L, "Widget", 10, TimeUnit.MINUTES);

// Redisson — RMapCache
RMapCache<Long, String> cache = redisson.getMapCache("products");
cache.put(1L, "Widget", 10, TimeUnit.MINUTES);

RMapCache enforces TTL with a client-side task; for native server-side hash-field expiry use RMapCacheNative (Valkey 9.0+ / Redis 7.4+).

Queues

// Hazelcast
IQueue<String> queue = hz.getQueue("tasks");
queue.offer("first");
String task = queue.poll();

// Redisson — RBlockingQueue implements java.util.concurrent.BlockingQueue
RBlockingQueue<String> rqueue = redisson.getBlockingQueue("tasks");
rqueue.offer("first");
String task = rqueue.poll();

Redisson also offers reliable and delayed queue variants; see the queues documentation.

Topics (Pub/Sub)

// Hazelcast
ITopic<String> topic = hz.getTopic("news");
topic.addMessageListener(message -> handle(message.getMessageObject()));
topic.publish("hello");

// Redisson
RTopic rtopic = redisson.getTopic("news");
rtopic.addListener(String.class, (channel, msg) -> handle(msg));
rtopic.publish("hello");

Atomics

// Hazelcast — atomics live in the CP subsystem
IAtomicLong counter = hz.getCPSubsystem().getAtomicLong("visits");
counter.incrementAndGet();

// Redisson
RAtomicLong rcounter = redisson.getAtomicLong("visits");
rcounter.incrementAndGet();

Executor Service

// Hazelcast — run a task on cluster members
IExecutorService executor = hz.getExecutorService("jobs");
executor.submit(new MyCallable());

// Redisson
RExecutorService rexecutor = redisson.getExecutorService("jobs");
rexecutor.submit(new MyCallable());

Redisson's executor runs serializable tasks on nodes running Redisson workers. Note this is task execution, not Hazelcast's compute-on-the-data entry-processor model.

Locks and Consistency

Locks deserve their own section, because it's where Hazelcast users ask the sharpest questions. Both systems give you a distributed, reentrant java.util.concurrent.locks.Lock, and — importantly — both implement the fencing token, the mechanism that actually makes a distributed lock safe against a paused or delayed holder (a monotonically increasing number the lock hands out, which the protected resource uses to reject stale writers).

In Hazelcast, the lock is FencedLock, obtained from the CP subsystem and backed by the Raft consensus algorithm; you get its fencing token from lockAndGetFence(). In Redisson you get the same tool with RFencedLock — Redisson explicitly models it on Hazelcast's FencedLock — via lockAndGetToken():

// Hazelcast — CP (Raft) FencedLock
FencedLock lock = hz.getCPSubsystem().getLock("order:1234");
long fence = lock.lockAndGetFence();
try {
    resource.write(data, fence);   // resource rejects any lower token
} finally {
    lock.unlock();
}

// Redisson — RFencedLock, same fencing-token mechanism
RFencedLock rlock = redisson.getFencedLock("order:1234");
long token = rlock.lockAndGetToken();
try {
    resource.write(data, token);   // resource rejects any lower token
} finally {
    rlock.unlock();
}

For everyday coordination that doesn't guard an external resource, a plain RLock is enough. It carries a watchdog that keeps a live holder's lock from expiring mid-task, and a replica-synchronization check that's on by default — so a lock isn't treated as held until the write has reached a replica, which closes the classic "lock returned before it replicated" failover gap. (Redisson has also deprecated its older RedLock implementation in favor of this approach plus RFencedLock.)

The honest comparison: Hazelcast's FencedLock derives its ordering from Raft consensus, which is a strong, well-regarded consistency design. But in Hazelcast's free Community edition the CP subsystem keeps that state in memory only — persistence for it is an Enterprise feature, and Hazelcast's own docs advise against the non-persistent CP subsystem for mission-critical production. Redisson gives you the same fencing-token safety and a replica-aware RLock, backed by the Redis or Valkey server you already persist and operate — without standing up, tuning, or licensing a separate consensus subsystem to get it. For the great majority of locking needs, that's the same correctness guarantee with materially less to run.

Technical Considerations and Implementation Pitfalls

• Serialization / codec. Hazelcast uses its own serialization (IdentifiedDataSerializable, Portable, Compact); Redisson uses a configurable codec (Kryo/JSON/etc.). Your cached types need to serialize under whichever codec you choose.
• Embedded → client mindset. With embedded Hazelcast, data can live in the same JVM as your code; with Redisson, every operation is a call to the Redis/Valkey server. RLocalCachedMap restores local-read speed for hot keys, but assume a network hop by default.
• Data migration isn't automatic. There's no in-place grid-to-Redis transfer; plan a dual-write or replay to move live data, or treat the cache as cold-fillable on cutover.
• Single object placement in a cluster. By default a Redisson object lives on one master node; spreading one large structure across cluster nodes (data partitioning) is a Redisson PRO feature.

Community vs. PRO, and a Note on Licensing

Redisson's community edition is Apache 2.0 and covers everything in this guide: all the distributed objects, near cache (RLocalCachedMap), RMapCache, the full lock family including RFencedLock, pub/sub, and the executor service — and, because encryption and authentication are the Redis/Valkey server's job, TLS (rediss:///valkeys://) and password/ACL auth come at no extra cost. Redisson PRO adds data partitioning across cluster nodes, an ultra-fast engine, extra local-cache implementations, reliable messaging (Reliable Queue and Reliable PubSub) with a JMS provider, advanced Spring integration, advanced data structures, and enterprise support.

For a light but fair comparison: Hazelcast's Community edition is also Apache 2.0 and includes the core data store and stream-processing engine, but its security suite (TLS, authentication, encryption), WAN replication, persistence, and the persistent Advanced CP subsystem are Enterprise-only, and patch releases between minor versions are Enterprise builds — so Community users receive CVE fixes only at the next minor release. Which edition you need on each side depends on your requirements; the point relevant to migration is simply that basic transport security is included on the Redisson side without a commercial license.

Frequently Asked Questions

Do I Still Need to Run a Cluster?

Not a Hazelcast one. You run Redis or Valkey (single node, cluster, sentinel, or a managed service) and Redisson connects to it as a client. That's the operational simplification.

Does Redisson Support Fenced Locks Like Hazelcast?

Yes. RFencedLock provides the same monotonic fencing-token mechanism as Hazelcast's FencedLock, and a plain RLock adds a watchdog and an on-by-default replica-synchronization check for everyday coordination.

Does Redisson Give Me a Near Cache Like Hazelcast's?

Yes — RLocalCachedMap keeps hot entries in the application's memory for local-speed reads and invalidates them across the cluster when the shared value changes.