Infinispan: an in-memory data grid that runs inside your JVM or as a server
Infinispan is an open source data grid platform and highly scalable NoSQL cloud data store.
At a glance
- What is it?
- infinispan/infinispan is an Apache-2.0 in-memory key/value database from Red Hat, used as a library inside Keycloak, Hibernate and Debezium and also deployable as a standalone clustered store. Choose it when the cache has to live in the same process as your application, not when you want a cache you talk to over a socket.
- Who is it for?
- Adopt Infinispan if your application is on the JVM and the cache belongs in the same process, which is the situation Keycloak, Hibernate and Debezium are in, or if you need clustered counters, locks and multimaps as first-party primitives. Do not adopt it if you want a cache that is operated separately from your application or if your services are not all on Java, in which case a server-side store such as Redis is the simpler deployment.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Two shapes, one codebase
Infinispan is an open source in-memory database that stores key/value pairs and distributes them across elastically scalable clusters. The README describes two roles for it: a volatile cache or a persistent data store, with the same clustering and fault tolerance in both.
What makes it different from the cache most people reach for is that the first deployment shape is a library. The README's own badge says it is used by Keycloak, Hibernate and Debezium, and those are all cases where Infinispan runs embedded in the application's JVM rather than as a separate service. Hibernate's second level cache is the classic example: the cache has to be in the same heap to avoid a network hop on every entity load.
The second shape is a server. The repository carries a distribution/ tree alongside core/, so the same engine ships as something you deploy and talk to over the network.
That dual nature is the decision you are actually making. If your cache should be in your process, Infinispan is one of very few mature options. If it should not be, you are paying for an embedding capability you will not use.
What the repository is actually made of
The root listing shows a large Maven project with a clear separation between the engine and its integrations. core/ and commons/ hold the engine. api/ and client/ expose it to callers. persistence/ handles durable stores, and query/ handles indexing and search.
The data structures beyond plain keys sit in their own modules: counter/ with counter-api/, lock/, multimap/ and anchored-keys/. These are the clustered primitives that are genuinely hard to build yourself, and having them as first-party modules is the point of a data grid rather than a map.
Standards coverage is broad. jcache/ implements JSR-107, cdi/ covers context and dependency injection, jboss-marshalling/ handles serialisation, and there is a hibernate/ module and a quarkus/ module for the two ecosystems most likely to embed it. gridfs/ points at a GridFS integration.
There is also a graalvm/ directory, which matters if you want to compile an application embedding Infinispan to a native image, and a cli/ directory for command line administration. The documentation/ tree holds the docs, and integrationtests/ is separate from the module tests.
Getting the dependency and the first cache
The README does not include a code sample. It points at infinispan.org, a five minute getting started guide, and a separate repository of simple tutorials. Maven Central is the distribution channel, and the README badge gives the artifact as org.infinispan:infinispan-core. The badge marks the 16.1 prefix as the stable version line and the 16.2 prefix as the development line, so those are the two prefixes to choose between when you pick a version, and the repository's own releases show 16.0.15 published on 2026-09-11 and 16.2.3 published on 2026-09-03.
The released tags give exact version numbers to pin, and two of them are 16.0.15, published on 2026-09-11, and 16.2.3, published on 2026-09-03. Set the version against the line you intend to follow rather than against whatever the badge resolves to on the day.
For a first runnable example the README directs you to the separate simple tutorials repository at github.com/infinispan/infinispan-simple-tutorials, which is where the sample code lives. Since neither the README nor the repository files in front of us contain an install command or a code sample, there is nothing here to copy and paste, and the five minute getting started guide on the website is the documented starting point.
Building Infinispan itself is a separate matter. The root carries pom.xml plus mvnw and mvnw.cmd wrappers, an Ant build.xml, and a README-Build.md that documents the process, which tells you the build is not a single obvious command.
JVM support is stated in the README badge as versions 17 through 25, so anything older than 17 is out.
Version lines and release behaviour
Two releases appear in the repository: 16.0.15, published on 2026-09-11, and 16.2.3, published on 2026-09-03. The last push to the repository was on 2026-09-15.
The presence of a 16.0 maintenance branch alongside 16.1 stable and 16.2 development means three lines are being serviced at once. That is normal for a project with this many downstream consumers, and it also means the release notes are mostly backports. Reading 16.0.15's notes gives a fair picture of what the project spends its time on: a Soft Index File Store compactor throwing ArrayIndexOutOfBoundsException, RocksDB write-ahead log cleanup after flushing the meta column family, clustered lock schema links, and CLUSTER SLOTS and CLUSTER SHARDS not reporting the full slot range.
Those are storage and clustering correctness issues, not feature work. It is the profile of a mature engine whose remaining bugs are in the corners of persistence and partition handling.
For anyone adopting it, the practical consequence is that you should follow the stable line and watch the maintenance releases for fixes that affect your store type, since several recent fixes are specific to RocksDB or to the Soft Index File Store.
Search and vector workloads
The repository topics list search-engine, semantic-search and vector-database alongside datagrid and key-value-store, which is not what most people expect from a cache.
The query/ module is where this lives, and the positioning is that you can index the entries you already have in the grid and run queries against them without moving the data into a separate search cluster. For an application that already embeds Infinispan, that removes a whole system from the deployment.
The README itself says nothing about search, so the capability is visible only in the topics and the module layout rather than documented on the front page. Anyone evaluating it for semantic search should start at infinispan.org rather than the repository, and should check which store types support the index you need.
Where the documentation leaves you
The README is short, and that is a real friction point. It gives no configuration example, no cache definition, no clustering setup and no code. Everything is deferred to the website, the getting started guide and the tutorials repository.
For a project of this size that is a defensible choice, since documenting an engine with this many deployment shapes inline would take hundreds of lines. It does mean the repository is not self-serve. You cannot clone it and read your way to a working cache.
One unusual thing in the root listing is a set of AI-oriented documents: AI.md, AI-CODE.md, AI-CONFIG.md, AI-ISSUES.md and AI-TEST.md, alongside .cursor/. The project has written down how AI assistance is expected to be used in its own development, which is more explicit than most.
The trade-off to weigh is complexity. This is a large Java project with an Ant build file next to Maven, many modules, and its own marshalling layer. That is fine when it is embedded in something you already deploy, and heavy when you only wanted a cache.
Redis as the alternative
The comparison people search for is Infinispan versus Redis, and the difference is architectural rather than a feature list.
Redis is a server. Your application is always a client, every access is a network round trip, and the data lives in a process you scale and operate separately. That buys you a simple operational model and clients in every language, at the cost of a hop on every get.
Infinispan can be that, and it can also be a library in your own JVM, where a read is a map lookup. That is the reason Hibernate and Keycloak embed it. It also brings Java-native integration that Redis cannot: JCache through the jcache/ module, CDI through cdi/, Hibernate second level caching through hibernate/, and Quarkus through quarkus/.
Choose Redis when your services are polyglot or you want the cache operated by someone else. Choose Infinispan when your application is on the JVM, the cache must be in-process, or you need clustered counters, locks and multimaps as primitives rather than something assembled from Lua scripts.
Licence and upkeep
Infinispan is Apache-2.0, with a LICENSE.md at the root and a dco.txt covering contributions. Apache-2.0 is permissive and carries an explicit patent grant, so embedding it in a commercial product carries no copyleft obligation.
Governance is documented rather than implied. The root has GOVERNANCE.md, CODEOWNERS, CONTRIBUTING.md, REVIEW.md and SECURITY.md, and contributions are subject to the Developer Certificate of Origin. For a project embedded in other people's products, that paper trail matters more than it would for an application.
Upkeep is the cost of the embedding decision. Because the cache is in your process, an Infinispan upgrade is an application rebuild and redeploy, not a separate service upgrade. With three version lines in service and JVM support spanning 17 to 25, plan upgrades rather than taking them opportunistically, and check the maintenance release notes against whichever store type you run.
Editorial conclusion
Adopt Infinispan if your application is on the JVM and the cache belongs in the same process, which is the situation Keycloak, Hibernate and Debezium are in, or if you need clustered counters, locks and multimaps as first-party primitives. Do not adopt it if you want a cache that is operated separately from your application or if your services are not all on Java, in which case a server-side store such as Redis is the simpler deployment. Before committing, decide which of the two shapes you need, pin the 16.1 stable line rather than 16.2, and confirm your runtime is on JVM 17 or newer, since the README badge lists 17 through 25 and nothing older.
Frequently asked questions
Is Infinispan a cache or a database?
The README describes it as an in-memory distributed database that can be used either as a volatile cache or as a persistent data store, with data spread across elastically scalable clusters.
Which Java versions does Infinispan support?
The README badge states supported JVM versions 17 through 25, so anything older than Java 17 is not covered.
How do I add Infinispan to a Maven project?
The Maven Central badge in the README gives the coordinates as org.infinispan:infinispan-core, and the badge marks 16.1 as the stable version line and 16.2 as the development line.
Does Infinispan run as a standalone server?
Yes. Alongside the embeddable library, the repository carries a distribution/ tree, and a cli/ directory exists for command line administration.
Where are the Infinispan code examples?
The README contains no code samples and points to infinispan.org, a five minute getting started guide, and the separate infinispan-simple-tutorials repository for runnable examples.
Does Infinispan support search or vector search?
The repository topics include search-engine, semantic-search and vector-database, and there is a query/ module, but the README itself does not document these features, so infinispan.org is the place to check.
Community notes