# Hazelcast: an in-memory data grid that grew into a streaming platform

> Hazelcast is a Java distributed data platform that stores data in memory across a cluster and processes streams with its Jet engine. It suits teams that need low-latency state and stream processing in one process, and it is heavier than a simple cache.

**hazelcast/hazelcast** — Hazelcast is a unified real-time data platform combining stream processing with a fast data store, allowing customers to act instantly on data-in-motion for real-time insights.

- Repository: https://github.com/hazelcast/hazelcast
- Website: https://www.hazelcast.com
- Stars: 6,614 · Forks: 1,896
- Language: Java
- License: NOASSERTION
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/hazelcast-hazelcast

## What Hazelcast is used for, and who it is for

Hazelcast is a Java platform that keeps data in memory across a cluster of nodes and processes events on top of that data. The README frames it as a unified real-time data platform: a distributed key-value store, pub-sub and queue messaging, SQL over streaming and batch sources, and a stream processing engine called Jet. The repository is the Java server and client; separate client repositories exist for Python, Node.js, .NET, C++, and Go.

The audience is JVM teams building systems where a network round trip to a database is the bottleneck. The documented use cases include caching with read-through and write-behind patterns, low-latency queue-based messaging, distributed coordination for microservices, and replicating data between data centers with WAN replication. If your application already runs on the JVM and you need shared state with predictable latency, the fit is direct. If you are building a small service that needs a cache and nothing else, the platform is larger than the problem.

## How the cluster, the data grid and the Jet engine fit together

A Hazelcast deployment is a set of nodes that discover each other and form a cluster. Data is partitioned across those nodes, and the README describes the key-value store as distributed, partitioned, and queryable, with event listeners. That store can hold contextual data used to enrich event streams at low latency.

On top of the store sits Jet, the built-in data processing engine. The README states Jet builds both streaming and batch pipelines that are elastic, and that pipelines can query streaming and batch sources directly with SQL. Connectors exist for Kafka, Hadoop, S3, RDBMS, JMS, and others. The architecture is therefore one process holding state and running the pipeline, rather than a separate compute layer reading from a remote store.

The README makes two guarantees worth noting for pipeline design: at-least-once and exactly-once processing for stream processing pipelines. It also claims microsecond performance for key-value point lookups and pub-sub, and cites a single node aggregating 10 million events per second with latency under 10 milliseconds. Those are the project's own figures, published in its README and linked blog posts, not independent measurements. Treat them as vendor benchmarks and reproduce them on your own hardware before designing around them.

## Installing Hazelcast and running a first cluster node

The README does not walk through installation itself. It points to the Getting Started Guide at docs.hazelcast.com for installing and starting Hazelcast, and the repository ships a Docker image referenced by a Docker pulls badge. For a source build, the README requires JDK 17 at minimum and recommends the included Maven wrapper.

```bash
$ git pull origin master
$ ./mvnw clean package -DskipTests
```

Running that build produces the packaged artifacts. The README notes a `quick` build activated with the `-Dquick` system property, which skips validation tasks such as tests, checkstyle, javadoc, and source plugins, and does not build the `extensions` and `distribution` modules. That is the faster path when you only need the core artifacts locally.

Running the test suite is a separate decision. The README warns that the default build executes thousands of tests and can take considerable time, and lists three profiles.

```bash
./mvnw test
./mvnw test -P nightly-build
./mvnw test -P all-tests
```

The default profile runs quick and integration tests, which the README says can run in parallel without network access using the `-P parallelTest` profile. `nightly-build` runs tests that are slow or cannot run in parallel. `all-tests` runs everything serially using the network. Some tests need Docker; set `-Dhazelcast.disable.docker.tests` to skip them.

For an application dependency rather than a server build, the related searches include "hazelcast maven", and the repository is the Java client and server published under the `com.hazelcast` group. The README's javadoc badge points at `com.hazelcast/hazelcast`. Exact coordinates and versions should come from the Getting Started Guide and Maven Central, since the README does not print a dependency snippet.

## Spring Boot integration and what it actually gives you

The repository contains `hazelcast-spring`, `hazelcast-spring-boot-autoconfiguration`, and `hazelcast-spring-tests` at the top level, so Spring support is part of this codebase rather than a separate project. The README does not document the integration, and the related searches show that "hazelcast spring boot" and "can Hazelcast be used with Spring Boot to cache data" are common questions.

What can be said from the repository layout is that Spring configuration and Spring Boot autoconfiguration modules exist and are tested here. The practical consequence is that a Spring Boot application can wire Hazelcast through configuration rather than manual cluster setup. The specific properties, annotations, and cache manager behavior are not in the README, so check the Spring integration documentation before assuming a particular configuration style. If your reason for choosing Hazelcast is Spring caching specifically, verify that path first, because the platform's wider feature set is not what you would be using.

## Where Hazelcast is the wrong tool

The clearest boundary is scale of problem. Hazelcast is a cluster: nodes discover each other, data is partitioned, and operations such as rolling upgrades and WAN replication are part of the design. A single application that needs a small cache with a TTL gets none of that benefit and takes on JVM memory pressure and cluster configuration instead.

A second boundary is operational. The README advertises zero-downtime operations with rolling upgrades, but rolling upgrades are a version-to-version procedure, not a free property. Upgrading a cluster means the upgrade path must be supported and the cluster must be healthy enough to move partitions. Teams without JVM operations experience should weigh that honestly.

A third boundary is licensing. The README states that source in the repository is covered by either Apache License 2.0 or the Hazelcast Community License, and that the default throughout the repository is Apache License 2.0 unless a file header specifies another license. That means a file-by-file check is the only reliable way to know what governs a given module. If your organization has strict license review, this is a real cost, not a formality. The README does not say which modules carry which license, and neither can you without reading the headers.

Finally, the performance claims in the README are the project's own. The 10 million events per second figure and the sub-10ms latency figure come from linked posts, and the README also claims 99.99% latency under 10ms for streaming queries. Those numbers depend on hardware, payload, and pipeline shape. Any adoption decision that rests on them should rest on your own benchmark instead.

## Hazelcast versus Redis: different centers of gravity

The most common comparison in the related searches is Hazelcast versus Redis, and the difference is architectural. Redis is a data structure server: clients connect to it and issue commands against keys, lists, sets, streams, and so on. Hazelcast embeds a data grid in JVM processes and adds a processing engine that runs inside the same cluster.

That changes what you can do without a second system. With Hazelcast, a Jet pipeline can read from a Kafka topic, join against data held in the distributed map, and push results to subscribers, all within the platform the README describes. With Redis, stream processing happens in your application or in a separate processor.

It also changes the failure surface. Hazelcast nodes are JVM processes that participate in partitioning and can run your pipeline code; a Redis deployment is a server you connect to. If your team's operational model is a managed cache endpoint, Hazelcast asks for more. If your model is a JVM service that owns its own state and logic, Hazelcast asks for less glue. The right question is not which is faster on a point lookup, but where you want the processing to live.

## Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-21, one day before this article's date, so the codebase is being changed. The recent release list shows v5.7.0 on 2026-05-13, v5.6.0 on 2025-10-15, and v5.5.0 on 2024-07-26. The gap between v5.5.0 and v5.6.0 is roughly fifteen months, and the gap to v5.7.0 is about seven months. That is a slow, deliberate release cadence rather than a continuous stream of minor versions, and it means an upgrade is a planned event, not something you absorb casually.

The README states that Hazelcast supports zero-downtime operations with rolling upgrades, so the upgrade mechanism exists in the product. What the README does not document is which version-to-version paths are supported, how long a given release receives fixes, or what happens to a cluster mid-upgrade if a node fails. Those answers live in the documentation site and release notes, not in this repository's README.

On licensing, the dual-license structure has a direct maintenance implication: because the default is Apache License 2.0 unless a header says otherwise, an audit of the modules you actually depend on is the only way to know your obligations. This is not legal advice, and the license texts themselves are the authority.

## Conclusion

Adopt Hazelcast when you need in-memory state and stream processing in the same JVM-based system, and you are willing to run and size a cluster. Do not adopt it as a drop-in replacement for a small Redis cache, or if your team cannot operate JVM services. Before committing, verify three things: whether the modules you use fall under Apache License 2.0 or the Hazelcast Community License, which client library matches your stack, and whether rolling upgrades are supported for the version you deploy.

## FAQ

### What is Hazelcast used for?

The README lists stateful processing over streaming and batch data, SQL queries over those sources, connector-based ingestion, pub-sub and queue messaging, caching patterns such as read-through and write-behind, distributed coordination for microservices, and WAN replication between data centers.

### Which is better, Redis or Hazelcast?

They differ in architecture: Hazelcast embeds a partitioned data grid in JVM processes and includes the Jet stream processing engine, while Redis is a data structure server that clients connect to. The README does not compare the two, so the choice depends on whether you want processing inside the data platform.

### How does Hazelcast cache work?

The README describes a distributed, partitioned, queryable key-value store with event listeners, and lists caching patterns such as read/write-through and write-behind. The store can also hold contextual data used to enrich event streams at low latency.

### Can Hazelcast be used with Spring Boot to cache data?

The repository contains hazelcast-spring, hazelcast-spring-boot-autoconfiguration, and hazelcast-spring-tests modules, so Spring and Spring Boot integration is maintained here. The README does not document the configuration properties, so consult the Spring integration documentation.

### How do you install Hazelcast?

The README points to the Getting Started Guide at docs.hazelcast.com for installing and starting Hazelcast, and the repository publishes a Docker image. Building from source requires JDK 17 at minimum and uses the included Maven wrapper.

### What is a Hazelcast cluster?

It is a set of Hazelcast nodes that discover each other and share partitioned data. The README describes data replication between data centers and geographic regions using WAN, and zero-downtime operations with rolling upgrades.

## Sources

- [hazelcast/hazelcast on GitHub](https://github.com/hazelcast/hazelcast)
- [Issues](https://github.com/hazelcast/hazelcast/issues)
- [Project website](https://www.hazelcast.com)
- [README](https://github.com/hazelcast/hazelcast/blob/master/README.md)
- [Releases](https://github.com/hazelcast/hazelcast/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hazelcast-hazelcast