Redis vs Hazelcast: A Java Developer's Comparison

Redis and Hazelcast get compared constantly, and most of the comparisons go wrong in the same way: they line up features in a grid as though the two were the same kind of product. They are not. Redis is a server written in C that you connect to over a socket. Hazelcast is a Java library that can become your cluster. Almost every difference below follows from that one fact.

This comparison is written for a Java team choosing between them in 2026, and it covers the things that actually decide the question: how each one deploys, what "single-threaded" really means, what the licences now say, what happens during a network partition, and what each costs to operate.

What Each One Actually Is

Redis is an in-memory data structure store written in C. It runs as a separate process, speaks a wire protocol, and has client libraries in every language. The current release is 8.10.1. Valkey, the Linux Foundation fork created after the 2024 licence change, is wire-compatible and currently at 9.1.2. Everything in this article that applies to Redis applies to Valkey unless stated otherwise.

Hazelcast Platform is a distributed in-memory computing platform written in Java. A cluster is a set of JVM members that partition data between them and hold backups of each other's partitions. It also contains a stream-processing engine — the former Hazelcast Jet, folded into the Platform at 5.0. If you are configuring it today, our guide to Hazelcast cache in Spring Boot covers the setup in detail. The current Enterprise release is 5.7.1; the latest Community Edition is 5.7.0, and that gap is not accidental (see licensing below).

One point of housekeeping, because stale comparisons still cite it: the older Hazelcast IMDG product line has had no release since 4.2.8 in May 2023, and standalone Hazelcast Jet none since 4.5.4 in December 2022. Both were folded into Platform. If a benchmark or comparison you are reading is built on IMDG 3.x, it is describing software that no longer ships.

Deployment: Embedded or Client/Server

This is the structural difference, and it is the one most comparisons skip entirely.

Hazelcast can run embedded: you add the jar, and your application instances are the cluster members. Data lives in the same JVM as the code that reads it, so a cache hit on locally-owned data costs no network round trip at all. Hazelcast's documentation puts the main benefit simply — "all your Java classes are visible to Hazelcast", which is what makes entry processors and queries over your own domain objects possible.

It can also run client/server: dedicated Hazelcast members, with your application connecting as a client. That looks much more like Redis.

The interesting part is which one Hazelcast itself recommends. Their deployment guide says client/server offers "more predictable and reliable performance, easier identification of problem causes and, most importantly, better scalability", and lets you scale the cluster independently of the application. Embedded mode is the one thing Redis structurally cannot do, and Hazelcast's own documentation steers you away from it for production.

That matters when weighing the two. If you deploy Hazelcast client/server — as most production users do — you have given up the embedded advantage and are running a separate cluster, which is what Redis was to begin with. The comparison then turns on everything else in this article.

Redis has no embedded mode. It is always a server you connect to, and your application talks to it through a Java client.

Threading, and What Single-Threaded Means

"Redis is single-threaded" is the most repeated claim in this comparison and the one most often stated without the qualification that makes it useful.

What is true: Redis executes commands on a single thread. Redis's own documentation describes it as "a single-threaded server from the POV of commands execution". The keyspace is mutated by one thread, which is precisely why Redis operations are atomic without locking.

What is usually left out: Redis has had io-threads since 6.0, and they parallelise socket reads, socket writes and protocol parsing — not command execution. They also ship disabled. In Redis 8.10.1 the default is io-threads 1, and the setting is immutable at runtime, so enabling it requires a restart. redis.conf suggests "enabling it only in machines that have at least 4 or more cores".

And the part that matters more than either: single-threaded is a per-process property, not a per-server ceiling. The standard answer to needing more CPU is to run more Redis instances — Redis Cluster exists for exactly this. Redis's own benchmark documentation says so: "It is not designed to benefit from multiple CPU cores. People are supposed to launch several Redis instances to scale out on several cores if needed."

Hazelcast is genuinely multi-threaded within a member, with a configurable partition-thread pool, and the Enterprise edition adds a thread-per-core engine. On a single large machine that is a real architectural advantage. Across a cluster, both scale by adding nodes.

Be careful with benchmark claims in either direction. The most widely cited Hazelcast-versus-Redis benchmark compares Hazelcast Enterprise 3.12 against Redis Open Source 5.0.3 — a Redis release from December 2018, which predates io-threads by two years, measured against a Hazelcast product line that no longer ships.

Licensing: The Part Most Comparisons Skip

Both products changed their licensing in ways that matter to a procurement conversation, and most published comparisons are describing the situation as it was several years ago.

Redis and Valkey

Redis 8's LICENSE.txt establishes a tri-licensing model. Contributions are governed by, in its own words, "your choice of: (a) the Redis Source Available License v2 (RSALv2); or (b) the Server Side Public License v1 (SSPLv1); or (c) the GNU Affero General Public License v3 (AGPLv3)". Redis 7.2 and earlier remain BSD-3-Clause.

Two half-truths circulate about this and both are worth correcting. "Redis is AGPL now" is incomplete — AGPL is one of three options, not the licence. "Redis is SSPL" is equally incomplete. And AGPLv3, while OSI-approved, is a network copyleft licence that plenty of enterprise legal departments refuse outright, so the return to an OSI licence does not automatically unblock adoption.

Valkey is plain BSD-3-Clause, governed by the Linux Foundation. For a team whose legal department blocks both AGPL and source-available licences, that is the escape hatch, and because Valkey is wire-compatible, Jedis, Lettuce and Redisson all work against it unchanged. Our Valkey vs Redis comparison covers the fork in detail.

Hazelcast

Hazelcast Community Edition is licensed under "the Apache License, Version 2.0, and a Hazelcast Community License". Enterprise is a separate download — Hazelcast is explicit that "you can't turn a Community Edition into an Enterprise Edition by adding a license key".

The detail that catches teams out is the patch policy, quoted from Hazelcast's release notes:

"From release 5.4, patch releases are only available for Enterprise Edition i.e. no patch releases (e.g. 5.4.1, 5.5.2) will be made available for Community Edition."

Maven Central bears this out: 5.5.0, 5.6.0 and 5.7.0 exist as Community artifacts; 5.6.1, 5.6.2 and 5.7.1 do not. A Community Edition user cannot take a security fix without waiting for the next minor release. For a regulated environment that is often the deciding fact, and no other comparison on the subject mentions it.

What is behind the Enterprise licence: disk persistence, WAN replication, rolling upgrades, blue/green deployment, the High-Density off-heap store, the thread-per-core engine, CP Subsystem persistence, and CVE patch releases.

One myth worth correcting in the other direction, because older articles get it wrong: Hazelcast's security features are not paywalled. TLS over the wire, mutual TLS authentication and JAAS integration all ship in Community Edition. Any article telling you Enterprise is required to encrypt Hazelcast traffic is out of date.

Consistency, Failover and Split-Brain

This is where the two differ most and where most comparisons offer a single sentence.

Redis replicates asynchronously. The cluster specification is candid about what that costs: "Redis Cluster uses asynchronous replication between nodes, and last failover wins implicit merge function… There is always a window of time when it is possible to lose writes during partitions."

The mechanics are bounded, though, which is the part worth knowing. In Redis Cluster, a master is only failed over when it is unreachable "by the majority of masters" for at least NODE_TIMEOUT, and the minority side "will start refusing writes as soon as NODE_TIMEOUT time has elapsed" — so the window in which writes can be lost has a defined end. Failovers themselves are "usually executed in a matter of 1 or 2 seconds".

Sentinel adds a distinction that is widely misreported. The quorum setting decides how many Sentinels must agree the master is down — but "the quorum is only used to detect the failure". Performing the failover requires "the vote of the majority of the Sentinel processes", which is why three Sentinels is the practical minimum and why a two-Sentinel setup can never fail over.

Hazelcast's IMap sits in the same availability-first category: partitioned data with backups, split-brain protection you configure with a minimum cluster size, and merge policies to reconcile diverged data after a partition heals.

But Hazelcast also has something Redis has no equivalent for. The CP Subsystem implements Raft consensus and provides linearizable structures — FencedLock, IAtomicLong, ISemaphore, CPMap. Operations are "committed and executed only after they are successfully replicated to the majority of CP members", and the structures "always maintain linearizability and prefer consistency over availability during network partitions". If you need a strongly consistent distributed lock and cannot accept the failure modes of a lease-based one, this is a real advantage and it deserves stating plainly.

Two caveats attached to it. The CP Subsystem is off by default — "By default CP data structures operate in unsafe mode", with cp-member-count at 0, and enabling it requires a cluster restart. And CP persistence is an Enterprise feature, so a full CP-member restart loses state on Community.

One open question is worth flagging rather than resolving: Hazelcast's March 2024 Community Edition blog stated the CP Subsystem "will no longer be supported as of Hazelcast Platform 5.5", yet 5.6 and 5.7 both shipped enhancements to it and the current feature comparison lists it in both editions. We could not find a follow-up announcement explaining the change. If you are planning around CP, confirm its status with Hazelcast directly.

Persistence

Redis gives you two mechanisms in the free product, and you can run both together. RDB performs "point-in-time snapshots of your dataset at specified intervals" — compact, fast to restore, with bounded loss between snapshots. AOF "logs every write operation received by the server" and replays it at startup; the default fsync policy is every second. Redis's own guidance is to use both "if you want a degree of data safety comparable to what PostgreSQL can provide you". Our Redis persistence entry covers the trade-offs.

Hazelcast's disk persistence is an Enterprise feature. On Community Edition the only durability path is MapStore and MapLoader — write-through or write-behind to a database you already run and operate.

That is a genuine asymmetry and it is almost never mentioned: a free Redis gives you durable storage out of the box; a free Hazelcast requires you to bring your own database behind it.

Near Cache: Two Different Mechanisms

Both systems can keep hot entries in application memory. They invalidate them very differently.

Hazelcast's Near Cache "maintains copies of distributed data in local memory for very fast access", avoiding the network and deserialization cost of a remote read. It works on members and on clients, and in client/server mode "you must enable the Near Cache separately on the client". Hazelcast is upfront about the trade: "Near Cache breaks the strong consistency guarantees; you might be reading stale data." Invalidation is asynchronous at cluster level.

Redis inverts the responsibility. With server-assisted client-side caching, "the Redis server remembers or tracks the set of keys that each client connection has previously read", and when a tracked key changes it "sends an invalidation message to all clients that have accessed that key previously". That runs over CLIENT TRACKING and RESP3 push messages, so the server drives invalidation rather than the client polling or waiting for a TTL.

Neither is strictly better. Hazelcast's is simpler to reason about and eventually consistent; Redis's pushes invalidation from the authoritative side. Our near cache entry covers the pattern generally, and client-side caching covers the Redis mechanism in depth.

Data Structures and the Java API

Here is the strongest argument for Hazelcast in a Java shop, and it is not performance. IMap implements java.util.concurrent.ConcurrentMap. FencedLock is a Lock. The cluster looks like java.util.concurrent, which means a Java developer already knows the API on the first day.

Raw Redis offers no such thing. It offers commands — GET, HSET, ZADD — and leaves the mapping to Java types entirely to your client library. With Jedis or Lettuce you write that mapping yourself.

Redisson is what closes that specific gap: it presents Redis as Java objects and collections, so RMap is a ConcurrentMap, RLock is a Lock, and roughly sixty data structures follow the same principle. For the Spring side of that, see our Spring Boot Redis cache guide. That makes the fair comparison for a Java team Redis + Redisson versus Hazelcast, and the tables below are exactly that comparison — not a comparison of the servers alone.

Distributed Collections

The sorted-set gap is the one that matters most in practice. Redis sorted sets underpin leaderboards, rate limiters, priority queues and delay queues, and Hazelcast has no direct equivalent — you build the ordering yourself.

Locks and Synchronizers

On locking it is a split decision. Redisson offers more varieties of lock; Hazelcast's FencedLock offers a stronger guarantee, because it is backed by Raft rather than by a lease in an asynchronously replicated store. Which matters more depends on whether your correctness argument can tolerate the failure modes of a lease. See distributed lock for the underlying problem.

Framework Integration and Serialization

Hazelcast has its own serialization framework — IdentifiedDataSerializable, Portable, Compact serialization and standard Java serialization — rather than pluggable third-party codecs. It is capable, and it is one more thing to learn. Our codec guide covers the Redis side.

Messaging

Both systems are used as message transports, and both have a weak option and a stronger one. The interesting differences are in where the delivery state lives and what survives a restart.

Fire-and-Forget Pub/Sub

Redis Pub/Sub and Hazelcast's ITopic are the same class of thing, and Redis is the more candid of the two about it. Redis documents the guarantee as at-most-once: "a message will be delivered once if at all… If the subscriber is unable to handle the message (for example, due to an error or a network disconnect) the message is forever lost."

Hazelcast never uses those words for ITopic, but describes publishing as "async. It does not wait for operations to run in remote members; it works as fire and forget." There is no TTL, no store and no subscription state in TopicConfig, so the behaviour is the same. One Hazelcast-specific detail worth knowing: message ordering across publishers is not guaranteed by default — global-ordering-enabled is false, and the documentation shows two subscribers legitimately observing different interleavings. Enabling it routes publishes through a partition owner.

The Reliable Tier

Both offer something stronger, and this is where they diverge properly.

Hazelcast's ReliableTopic is backed by a Ringbuffer with "one synchronous backup by default", so events survive a member failure. What it does not give you is server-side delivery tracking. MessageListener has exactly one method, onMessage. There is no ack, no nack, no redelivery timer. To get a delivery guarantee you implement ReliableMessageListener and checkpoint sequence numbers yourself; Hazelcast's javadoc is explicit that storeSequence "is called before the message is processed; so it can be persisted on some non-volatile storage" — storage you provide. Add one to the stored sequence for at-most-once, replay it for at-least-once.

A slow consumer is also a real failure mode rather than a queueing problem. The buffer is capacity-bounded, TopicOverloadPolicy defaults to BLOCK, and the javadoc states the outcome plainly: a listener "will not get duplicates and there will only be gaps if it is too slow", after which Hazelcast terminates it.

Redis Streams put that state on the server. A consumer group tracks a pending entries list, consumption "requires an explicit acknowledgment using a specific command" (XACK), and unacknowledged work is inspectable with XPENDING and reassignable with XCLAIM or XAUTOCLAIM. The guarantee is at-least-once, and the redelivery bookkeeping is the broker's rather than yours.

Redis documents the limits of that too. Consumer-group state is replicated asynchronously, so "after a failover something can be missing". Durable messaging on Redis wants AOF with a strict fsync policy, not defaults.

Redisson's counterpart is RReliablePubSubTopic, and the trade runs both ways: it supplies what ReliableTopic leaves to the application, but it is a Redisson PRO feature where Hazelcast ships ReliableTopic in Community. Hazelcast gives you replication free and asks you to build the delivery guarantee; Redisson sells the guarantee.

Queues, and a Ceiling Worth Knowing About

Hazelcast's IQueue carries a constraint that surprises people, and Hazelcast states it directly:

"Queue is a non-partitioned data structure, so all entries of a queue reside in one partition."

One queue lives on one member, with backups elsewhere. It does not scale across the cluster the way IMap does, and Hazelcast's own suggested workaround concedes the cost: "In the case of a lot of producers and consumers for the queue, using a list of queues may solve the queue bottlenecks. In this case, be aware that the order of the messages sent to different queues is not guaranteed."

The same applies to Ringbuffer — "create a Ringbuffer that can safely fit in a single cluster member" — and by extension to ReliableTopic, since each one gets its own Ringbuffer. Redis Streams are a single key and therefore a single shard too, but the sharding unit is a stream rather than the whole structure, and consumer groups scale readers within it.

On the Redis side a plain BLPOP is destructive on delivery, with the same crash-loses-the-item exposure as IQueue.take(). The at-least-once pattern is BLMOVE onto a processing list, and Redis documents that as a pattern you assemble rather than a feature you switch on. Our guide to reliable queues covers what production use actually requires.

What Neither Gives You for Free

Two gaps are worth stating because they decide architectures.

Neither persists messages to disk by default. Hazelcast's persistence documentation lists what can be persisted: map and JCache contents, streaming job snapshots, and SQL metadata. Topics, reliable topics, ringbuffers and queues are not on that list, so even on Enterprise with persistence enabled, a full cluster restart empties them. The exceptions are the QueueStore and RingbufferStore interfaces, which are SPIs you implement against a database you already run. Redis persists streams through RDB and AOF like any other key, which is a genuine difference in the free product.

Neither has a built-in dead-letter queue. There is no dead-letter element on QueueConfig, TopicConfig or ReliableTopicConfig, and no dead-letter concept in the Hazelcast documentation at all; the nearest primitive is ReliableMessageListener.isTerminal(), which decides whether to kill the listener, not where to send the poison message. On Redis you build the same thing from a delivery counter and a second stream.

JMS

If you need the Jakarta Messaging API, this is a clean split rather than a matter of degree.

Hazelcast does not implement JMS. There is no com.hazelcast.jms package in the 5.7 API, and you cannot point a jakarta.jms.ConnectionFactory at a Hazelcast cluster. The request has been open on their tracker since 2012, at low priority. What Hazelcast does ship is a Jet connector that reads from and writes to external JMS brokers — "Apache ActiveMQ and ActiveMQ Artemis, Amazon SQS, IBM MQ, RabbitMQ, Solace" — so Hazelcast is a client of somebody else's broker. Its own fault-tolerance documentation makes the distinction for us, describing a JMS queue as an "acknowledging source" whose redelivery belongs to the broker.

Redisson implements the JMS API on Redis: JMS 2.0, 3.0 and 3.1, passing the TCK, through RedissonConnectionFactory, with programmatic and JNDI configuration. See JMS messaging over Valkey and Redis for the implementation.

What a Broker Layer Adds

Underneath that JMS surface sit two Redisson PRO objects that between them cover most of what a Hazelcast team ends up hand-building. RReliableQueue is point-to-point delivery with the bookkeeping on the server: a poll makes a message invisible for a visibilityTimeout rather than removing it, and it reappears if nobody calls acknowledge. RReliablePubSubTopic is the fan-out equivalent, with subscriptions as named server-side objects that outlive the client that created them. Both carry a deliveryLimit, a dead-letter destination and deduplicationById; the topic adds Position and seek for replay, and a SyncMode that can hold an acknowledgement until the write reaches AOF on disk. Full configuration is in our guides to reliable queues and reliable pub/sub.

That last setting is the sharpest line in the messaging comparison. ACK_AOF makes an acknowledgement wait for disk. Hazelcast has no disk path for topic or queue contents in any edition, so the equivalent does not exist to be configured.

Hazelcast's advantage in this area is Jet: a real stream-processing engine with windowing, joins and exactly-once connectors, in the same product. If your messaging need is a processing pipeline rather than a transport, that is a strong argument and Redis has no equivalent. Our Redis Streams vs Kafka comparison covers where a log-shaped transport stops being enough.

What Each Does That the Other Cannot

Hazelcast Only

• Embedded deployment. No network hop for locally-owned data, and full visibility of your classes.
• Entry processors. Send the code to the data and mutate an entry on the member that owns it, atomically, without moving it across the network. There is no Redis equivalent short of a Lua script.
• Stream processing. The Jet engine is part of the Platform, with a pipeline API for windowing and joins, and exactly-once connectors to Kafka, Pulsar, Kinesis and external JMS brokers.
• Distributed SQL over map contents.
• Raft-backed linearizable structures via the CP Subsystem.
• Predicates and indexes over your own Java objects, without a separate search product.

Redis Only

• Sorted sets, bitmaps, HyperLogLog and geospatial indexes as native server-side types.
• Streams with consumer groups for at-least-once processing, with server-side acknowledgement and a pending-entries list rather than sequence numbers you checkpoint yourself.
• Any language. Hazelcast has clients for several; Redis is the default in-memory store for nearly every runtime, which matters in a polyglot estate.
• No JVM in the data tier. No garbage collection to tune on the storage side.
• A managed service from every major cloud — ElastiCache, MemoryDB, Azure Cache, Memorystore, OCI Cache, IBM Cloud Databases and Redis on SAP BTP. Hazelcast Cloud exists, but the field is not comparable in breadth.
• Free durable persistence, per the section above — including for message streams, which Hazelcast's persistence does not cover.

Operational Weight

The cost of Hazelcast is the JVM. Cache memory and application memory come from the same heap in embedded mode, garbage collection pauses affect data access, and heap sizing becomes a capacity-planning exercise. The Enterprise High-Density store moves data off-heap and largely solves this — behind the licence.

There is also a hard floor that catches teams by surprise: Hazelcast Platform 5.7 requires Java 17 as a minimum, tested on 17, 21 and 25. Java 8 and Java 11 are not supported. Note also that on Java 25 the SecurityManager is non-functional due to JDK changes. If your estate is still on Java 11, current Hazelcast is not an option at all.

Redis imposes no JVM constraint on the data tier — it is a C process. Your Java client has its own requirements, but the storage layer does not participate in your garbage collection.

Against that, Hazelcast has a real operational advantage in an all-Java shop: one technology, one packaging model, one set of libraries, and no separate server to provision if you deploy embedded.

Which Should You Choose?

Most comparisons end without answering this. Here is the answer.

Choose Hazelcast when: you are a JVM-only shop and want your cluster to look like java.util.concurrent; you need computation next to the data, through entry processors or the Jet stream-processing engine; you need a strongly consistent, Raft-backed distributed lock; embedded deployment fits your architecture; or you are already buying Enterprise and will use persistence, WAN replication and the off-heap store.

Choose Redis or Valkey when: more than one language needs the same data; you want sorted sets, streams, bitmaps or geospatial types without building them; you need a queue that shards across the cluster, or the Jakarta Messaging API; you want a managed service and not a cluster to operate; you need durable persistence without a licence; you want no JVM in the data tier; or your legal team needs a permissive licence, in which case Valkey's BSD-3 is the cleanest answer available from either vendor.

The reality for most Java teams is that Redis or Valkey is already running somewhere in the estate, and the question is whether a second, JVM-specific clustering technology earns its operational cost. If what you want from Hazelcast is Java collections and locks rather than embedded compute, you can have those on Redis through Redisson without adding a cluster to operate. If what you want is compute next to data, Hazelcast is the right tool and no Redis client changes that. For teams that have already decided to move, our Hazelcast alternative page covers the case for Redisson.

Migrating in Either Direction

The programming model transfers more cleanly than people expect. Hazelcast's IMap becomes Redisson's RMap, both implementing ConcurrentMap; sets, lists, queues, topics, atomics and executor services all have counterparts implementing the same java.util and java.util.concurrent interfaces. Near caching, per-entry TTL, distributed locks and pub/sub all have direct equivalents.

What does not transfer is the compute layer — entry processors and Jet pipelines have no direct Redisson analogue, and that boundary should be established before any migration starts. Our Hazelcast to Valkey or Redis migration guide walks through the mapping structure by structure, and the wider category is covered in our comparison of in-memory data grids.

Frequently Asked Questions

Is Hazelcast Better Than Redis?

Neither is better in general; they solve overlapping problems differently. Hazelcast is stronger when you want computation next to your data, an embedded deployment, a Raft-backed linearizable lock, or a cluster that presents itself as ordinary Java collections. Redis is stronger when several languages share the data, when you want sorted sets, streams and geospatial types as native server-side structures, when you want durable persistence without a licence, and when you would rather consume a managed service than operate a cluster.

What Is Hazelcast Used For?

Distributed caching, distributed Java data structures such as maps, locks and queues, session replication, and stream processing. Its distinguishing capability is running computation on the member that owns the data — entry processors and the Jet pipeline engine — which makes it a fit for workloads that transform data in place rather than simply reading and writing it.

Does Redis Need Third-Party Clustering?

No, and this is a common error in older comparisons. Redis Cluster has been part of Redis since version 3.0 in 2015, with native sharding across 16,384 hash slots, automatic failover and client-side redirection. Redis Sentinel additionally provides monitoring and automated failover for non-clustered deployments. Neither requires third-party software.

Is Redis Still a Good Choice in 2026?

Yes, with a licensing caveat worth understanding. Redis 8 is tri-licensed under RSALv2, SSPLv1 or AGPLv3 at your choice, and Redis 7.2 and earlier remain BSD-3-Clause. If a copyleft or source-available licence is a problem for your organisation, Valkey is a Linux Foundation fork under plain BSD-3-Clause that is wire-compatible, so existing Java clients work against it unchanged.

Next Steps

If you are weighing the two for a Java application, the practical question is usually whether you need a data grid at all or a shared in-memory store with a good Java API. Our in-memory data grid comparison covers the wider category, what a data grid is covers the concept, and distributed caching in Java covers the implementation on the Redis side.

To see how Redisson's Java API compares in practice, try Redisson PRO free or review the feature comparison.

Similar articles

• Feature Comparison: Redis vs Ehcache
• Feature Comparison: Redis vs Apache Ignite
• In-Memory Data Grids Compared
• Migrating from Hazelcast to Valkey or Redis