Replacing Infinispan and Oracle Coherence with Valkey or Redis

Infinispan and Oracle Coherence sit at opposite ends of the same category. One is Red Hat's Apache-2.0 grid, embedded in WildFly, Quarkus and Keycloak. The other is the enterprise incumbent, priced per processor and wired into two decades of WebLogic deployments. Teams evaluating a move off either one are asking the same question, and it is not "which product has more features."

The question is whether you still need a peer-to-peer cluster of JVMs holding your data, with the membership protocol, rebalancing and split-brain handling that comes with it — or whether a Valkey or Redis server plus a capable Java client covers what you actually use. This guide answers that for both products: what maps across cleanly, what does not map at all, what Infinispan's Redis-protocol endpoint can and cannot do, and what Coherence's license really costs. Most of what gets written as Infinispan vs Redis, or Coherence vs Redis, is a feature scorecard. The scorecard is not where this decision gets made.

Why Teams Are Looking in 2026

Three dated things happened between February and July, each landing on a different kind of team.

Infinispan moved the server to Java 25. From release 16.1 (February 2026), the standalone server requires Java 25 for bare-metal deployments; the container image had required it since 16.0. Infinispan's own release announcement is blunt about it: the server image "has already included Java 25 since 16.0, but we've now made this a hard requirement for bare metal deployments too," while "the clients can continue running with ye olde legacy Java versions of choice." The embedded library and Hot Rod clients still target JDK 17. The server does not.

That is the most aggressive Java baseline in the category — Hazelcast Platform's minimum supported JDK is 17, and GemFire still certifies against LTS releases going back to 8. If you run Infinispan Server on bare metal in an estate standardized on Java 17 or 21, staying current now means moving the grid's JVM ahead of everything else you run.

Coherence CE 22.06 ran out of support on 30 June 2026. Oracle committed to four years when it shipped: release 22.06 "will be maintained — patched and supported — for a period of four years, ending June 30th, 2026." It was Community Edition's first long-term-support release, and the patch line stops at 22.06.18. Non-LTS CE releases get less — they are supported only until the next release ships. If you are on 22.06 today, you are running unpatched.

Be clear about what that does and does not argue for. The cheap fix is upgrading within Coherence CE — 26.04 is current, still UPL-licensed, still free — and for many teams that is the right answer. An expired support window is not on its own a reason to leave a grid. What it is, is a forced decision point: you have to touch the deployment anyway, and that is the moment to ask whether you still need a grid at all, rather than deferring it for another four years.

Red Hat's own flagship shipped an option to stop running Infinispan. Keycloak 26.7 (July 2026) introduced a preview "stateless mode" that moves volatile session data — authentication sessions, action tokens, login-failure counters — into the database instead of Infinispan. The stated purpose is to eliminate "a separate Infinispan deployment, its monitoring, and failover/failback procedures" in multi-region setups, at a cost of roughly 8–10 ms per interaction and about double the database load.

Keycloak has not dropped Infinispan, and this article will not pretend otherwise. But the product that did more than any other to put Infinispan into production now ships an alternative whose headline benefit is not operating it — and names operational weight as the reason. That is worth noticing if you inherited Infinispan rather than chose it.

It also cuts against the pitch in this article, and the point is worth conceding plainly: Keycloak did not swap one cache-shaped cluster for another. It went to the database and accepted the latency. If your session data is small and your database has headroom, that is a legitimate answer too, and it needs no new dependency at all.

What You Are Actually Replacing

Both products are data grids: a cluster of JVMs that pool memory, partition a dataset across members with backup copies, and let you run code on the member that owns a key. Infinispan clusters over JGroups; Coherence over its own TCMP protocol. In both, members discover each other, detect failures, rebalance partitions and have to be protected against split-brain. The data is sharded across members, so adding or losing an application instance moves data.

Be honest about what changes and what does not. Redis Cluster has its own membership gossip, its own failover, its own quorum settings and its own split-brain behaviour during a partition. You are not deleting the consensus problem; you are moving it out of your application tier and into infrastructure that a platform team already runs. That is a real and valuable decoupling, and it is a smaller claim than "no more distributed systems."

Valkey and Redis are a different shape. You run a server — or a managed service — and connect to it. There is no membership protocol between your application instances, no rebalancing triggered by an application deployment, and no grid version coupled to your application's JVM. Redis Cluster still reshards when you add or remove a node — that work does not disappear, it just stops being triggered every time you deploy. Redisson supplies the programming model on top: distributed maps, locks, queues and near caches with the same semantics a grid gives you.

The honest test is short. Keep the grid if you depend on compute running inside the cluster — entry processors, distributed executors targeting the partition owner, Ickle or CohQL queries with joins and aggregation — or if your latency budget genuinely requires data in the same JVM as the code. You probably do not need one if what you use is distributed maps with TTLs, locks and counters, a near cache, session storage, and a Hibernate or Spring cache provider — in other words, distributed caching with coordination. That second list is what most grid deployments turn out to be, and all of it moves.

Infinispan: What Carries Over

Infinispan's Cache extends ConcurrentMap, so most application code is already written against an interface Redisson also implements.

The API Map

One difference in that first row deserves more than a table cell, because it is architectural rather than cosmetic. An Infinispan or Coherence cache is partitioned across every member by construction — the dataset can exceed any one machine. A Redisson RMap is a single Valkey or Redis hash living in one hash slot on one primary, and Redisson's own documentation says so: "the state of any single object instance remains confined to its assigned master node and cannot be distributed or partitioned across multiple master nodes within the cluster." Data partitioning, which spreads one structure across cluster nodes, is a PRO feature. If your grid cache holds more than a single node's worth of RAM, that is a sizing decision to make before anything else in this article matters.

Locks are where the mapping is closest and the ergonomics differ most. Infinispan's clustered locks come from a factory bound to the cache manager, must be defined before use, and return futures:

// Infinispan
ClusteredLockManager lockManager =
    EmbeddedClusteredLockManagerFactory.from(cacheManager);
lockManager.defineLock("order:1234");
ClusteredLock lock = lockManager.get("order:1234");
lock.tryLock(10, TimeUnit.SECONDS)
    .thenAccept(acquired -> { /* ... */ });

// Redisson
RLock lock = redisson.getLock("order:1234");
if (lock.tryLock(10, TimeUnit.SECONDS)) {
    try { /* ... */ } finally { lock.unlock(); }
}

Counters follow the same pattern — a factory off the cache manager on one side, a getter on the client on the other:

// Infinispan — counters, like locks, must be defined before use
CounterManager counters =
    EmbeddedCounterManagerFactory.asCounterManager(cacheManager);
counters.defineCounter("orders",
    CounterConfiguration.builder(CounterType.UNBOUNDED_STRONG).build());
StrongCounter orders = counters.getStrongCounter("orders");
orders.incrementAndGet();          // CompletableFuture<Long>

// Redisson
RAtomicLong orders = redisson.getAtomicLong("orders");
orders.incrementAndGet();          // long
orders.incrementAndGetAsync();     // RFuture<Long>

Redisson's RLock adds a watchdog that extends the lease while the owner is alive, and an on-by-default check that the lock write reached a replica before the acquisition is reported as successful. Both are distributed locks in the usual sense. If you need a fencing token to reject a stale writer at the protected resource, RFencedLock issues a monotonic one.

Say the harder thing too. A grid lock is backed by strongly consistent partition ownership. A Valkey or Redis lock is a key on a primary with asynchronous replication, and the well-known objection — a primary dies before the lock write reaches a replica, the promoted replica has no record of it, a second client acquires the same lock — is narrowed by the replica-sync check and by fencing tokens, not eliminated. If your correctness argument depends on mutual exclusion alone rather than on the protected resource rejecting stale writers, use RFencedLock and check the token at the resource.

What Redisson Has That Infinispan Does Not

Infinispan gives you clustered locks and clustered counters. It does not ship a distributed queue, deque, blocking queue, semaphore, countdown latch, rate limiter or scheduled executor.

Redisson ships all of them in the Apache-2.0 edition: RQueue, RDeque, RBlockingQueue, RBlockingDeque, RPriorityQueue, RSemaphore, RPermitExpirableSemaphore, RCountDownLatch, RRateLimiter, RScheduledExecutorService. If your Infinispan deployment has a hand-rolled work queue on top of a cache, there is a built-in shape to move it into — though not automatically a safer one.

Two fair caveats. Not shipping queues is a defensible choice for a cache-shaped product, and plenty of grid teams correctly reach for Kafka or a JMS broker rather than building one. And the free Redisson queues are Redis-list-backed and at-most-once: once an element is popped it is gone, with no acknowledgement and no redelivery if the consumer dies mid-processing. Acknowledgements, visibility timeouts and redelivery come with Reliable Queue in PRO. A careful hand-rolled queue with idempotent consumers may well be safer than RBlockingQueue; compare semantics, not type names.

The RESP Endpoint: What Works and What Does Not

Infinispan ships a RESP endpoint that speaks the Redis wire protocol, which raises an obvious question: can you point a Redis client at Infinispan and skip the migration entirely? The answer is a qualified yes, with three specifics worth knowing before you try.

It is RESP3 only. Infinispan's documentation is explicit: "Infinispan only supports RESP version 3. Attempting to use version 2, will result in an error." Redisson's protocol setting defaults to RESP2. So the default configuration fails against it, and the fix is a single setting:

singleServerConfig:
  address: "redis://infinispan-host:11222"
  protocol: "RESP3"

The isolation guarantees are different, and Infinispan says so. From the same page: "Redis utilizes a single thread to handle user requests, which provides serializable isolation and atomic behavior for multi-key requests. Infinispan provides a relaxed isolation level, which is configurable." The consequence is stated just as plainly — "concurrent requests might perceive a partial result for commands that access multiple keys, such as MSET, where only a subset of the keys were inserted in the cache before the operation finishes." If you have code that relies on multi-key atomicity, it does not transfer unchanged. In the other direction, Infinispan offers real rollback where Redis transactions do not.

One qualification Infinispan's framing leaves out, and it works against Redis rather than for it: the serializable multi-key behaviour it is comparing itself to is single-node Redis. In Redis Cluster, an MSET whose keys hash to different slots is not weakly isolated — it is rejected with CROSSSLOT. Multi-key atomicity in a clustered Redis deployment requires designing the keyspace so related keys share a hash tag. That is a real constraint a grid does not impose, and it applies to Redisson transactions and batched multi-key operations as well.

Coverage is broad but not complete. The endpoint implements Lua scripting (EVAL, EVALSHA, SCRIPT), MULTI/EXEC/WATCH, the full string, hash, list, set and sorted-set families, pub/sub, SCAN, CLUSTER SLOTS and CLUSTER SHARDS, and HyperLogLog. It goes further than stock Redis in one direction, implementing the Bloom, Cuckoo, Count-Min Sketch, Top-K and JSON families that Redis ships as modules. What is missing matters if you use it: there are no Streams commands (XADD, XREAD), no FUNCTION, and no OBJECT. Redisson's RStream, RReliableTopic and the PRO reliable-messaging stack are all built on Streams, so those do not work against it.

Used well, the endpoint is a genuinely useful bridge: it lets you port application code to a Redis client while still pointing at Infinispan, then repoint the client at Valkey or Redis when you are ready. Used as a destination, it leaves you operating a grid anyway — with weaker multi-key semantics than the API you have written against.

Oracle Coherence: What Carries Over

Coherence's surface is wider than Infinispan's, and the concurrency half of it maps to Redisson almost one-to-one. That is because the coherence-concurrent module, added in CE 21.12, deliberately implements the java.util.concurrent interfaces — which is exactly what Redisson does.

The API Map

The lock and counter code is close enough that the diff is mostly the factory call:

// Coherence — coherence-concurrent
Lock lock = Locks.remoteLock("order:1234");
AtomicLong orders = Atomics.remoteAtomicLong("orders", 0L);
Semaphore permits = Semaphores.remoteSemaphore("api", 10);
NamedBlockingDeque<Order> queue = Queues.deque("orders");

// Redisson
RLock lock = redisson.getLock("order:1234");
RAtomicLong orders = redisson.getAtomicLong("orders");
RSemaphore permits = redisson.getSemaphore("api");
RBlockingDeque<Order> queue = redisson.getBlockingDeque("orders");

The one row in that table with a dash needs explaining, because it is the sharpest gap on the Coherence side. A Continuous Query Cache is not a near cache with different plumbing. It is filter-driven and push-based: you declare a filter, Coherence materializes every entry matching it — including entries this client has never read — and keeps the set live as the data changes. RLocalCachedMap is invalidation-based and only ever holds what this JVM has already touched. If you use a CQC for "the live set of all open orders for this trader" without ever reading those entries individually, there is no Redisson equivalent, and the replacement is an application-level design using search plus an RTopic subscription.

One detail worth checking against your own usage: Coherence's Queues.queue() and Queues.deque() return structures with a maximum size of 2 GB, because a queue lives in a single partition. Spreading a larger queue across the cluster requires Queues.pagedQueue(), which pages elements over members. Redisson's queues have no documented element cap, but the practical ceiling is the same shape and less explicit: the queue is one key on one primary, bounded by that node's memory, with no equivalent of pagedQueue() in the community edition. Coherence gives you a documented limit and a documented escape hatch; Redisson gives you an undocumented one and PRO data partitioning as the escape hatch. Neither is free of the constraint.

POF and Serialization

Portable Object Format is not Coherence's default — plain Java serialization is — but it is widely adopted, because Oracle's own benchmark puts POF at roughly seven times faster to serialize and one sixth the size. That figure comes from a deliberately simple test class — a string, a long and three ints — so treat it as a ceiling rather than a number your object graph will hit. It is enabled per service, so adoption is usually partial.

This is the real lock-in in a Coherence estate, and it is opt-in lock-in: every class with a PofSerializer or a @PortableType annotation needs a new representation on the way out. Redisson's codec layer covers the equivalent ground — Kryo, Protobuf, Avro, JSON, Jackson, and a default that requires no annotation at all — but the mapping is manual work proportional to how much POF you adopted. Count your POF-annotated classes before you estimate the project.

The Coherence License Arithmetic

Coherence is the one product in this category where the license is usually the reason for the conversation, so it is worth getting the numbers right rather than gesturing at "expensive." From Oracle's Technology Global Price List dated 3 August 2026:

Coherence is not bundled with WebLogic Server Suite. It is licensed and priced separately in the same price list. There is a discounted "WebLogic Coherence Grid Edition Option" sold as a Suite add-on, and a restricted-use license that ships with SOA Suite limited to clustering, POF, local caching and internal SOA usage. If you assumed your WebLogic entitlement covered general Coherence use, that assumption is worth checking.

Community Edition is more capable than its reputation, and the cleanest way to see that is to read what Oracle says is missing rather than what marketing says is included. The Coherence repository's own README publishes the exclusion list in full:

• Management of Coherence via the Oracle WebLogic Management Framework
• Deployment of Grid Archives (GARs)
• HTTP Session Management for Application Servers (Coherence*Web)
• GoldenGate HotCache
• TopLink-based CacheLoaders and CacheStores
• Elastic Data
• Federation and WAN (wide area network) Support
• Transaction Framework
• CommonJ Work Manager

Everything else is in CE under the Universal Permissive License 1.0 — persistence, the security model, Management over REST, JMX, the Reporting framework, the gRPC proxy, the Kubernetes Operator, coherence-concurrent and distributed queues. That is a real free product, and "CE is crippled" is not a good reason to leave.

But read the exclusion list against what a normal enterprise Java application actually does, and three entries stand out. HTTP session management and the transaction framework are not exotic grid features — they are ordinary application requirements, and reaching either one takes you from a free license to $11,500 or $25,000 per processor. Federation is the third, and it is the one people usually have in mind when they say cross-datacenter.

Two of the three have direct answers on the Valkey and Redis side. Session storage is Apache-2.0 in Redisson through Spring Session and the Tomcat session manager; XA transactions through an XAResource are in PRO. Federation is the murkier one: Multi Cluster mode covers active-passive replication in PRO, but Coherence Federation also does active-active, hub-spoke and central-federation, and those topologies have no Redisson equivalent. If you run active-active across regions today, that is a blocker rather than a migration task.

So the license question is narrower and sharper than "free versus paid." If you never touch the nine, CE is genuinely free and your reason to move is operational weight, not cost. If you touch sessions or XA, you are paying Oracle per processor for capabilities that cost a dependency change here. One caveat in fairness: Redisson PRO's price is not published the way Oracle's is, so the delta is a quote rather than an arithmetic exercise — ask for one before assuming it.

What You Give Up

Before the mechanics, the honest part. Four things do not come across, and a migration plan that hides them will fail in review.

Synchronous backup acknowledgement. This is the one most often missed, and it is the most consequential. A Coherence partitioned cache does not consider a put() complete until the backup member has acknowledged it, and Infinispan offers synchronous replication to owners in the same spirit. Valkey and Redis replicate to replicas asynchronously by default, so there is a window in which an acknowledged write has not reached a replica and a failover loses it. As with locks above, that window can be narrowed — WAIT, or a managed service with stronger failover behaviour — but not closed, and you are trading a default-on guarantee for an opt-in one. If your grid data is authoritative rather than a cache of something else, price this properly or keep a system of record behind it.

Compute on the data. Coherence entry processors and Infinispan's cluster executor run your code on the member that owns the key, serialized per key. Redisson has an RExecutorService, but it dispatches tasks to worker JVMs — it does not execute on a Valkey or Redis node that owns a hash slot. The closest equivalent for atomic read-modify-write on a hot key is a Lua script, which is server-side and atomic — but Lua cannot see your Java classes or Redisson's codec, so for the common case of an RMap<K, SomePojo> there is no server-side atomic mutation at all. You are left with read, mutate, write under a distributed lock. That is a loss of atomicity, not a change of style, and if your grid usage is entry-processor-heavy it is the item most likely to turn a migration into a redesign.

Embedded, in-JVM data. Both grids can hold data inside your application processes with no network hop. Redisson is a client to a server. RLocalCachedMap recovers most of the read latency for hot keys, but it is a cache in front of a remote store, not the store itself.

Grid query languages. Coherence's CohQL and Infinispan's Ickle support filtering, projection and aggregation over the grid. Valkey and Redis offer secondary indexing and search, which covers many cases well, but a direct CohQL translation is not available and complex analytical queries usually belong somewhere else entirely.

What the Move Looks Like

Most teams use both paths below: the first to get off the grid quickly, the second to remove the abstraction afterwards.

Path A — Swap the Provider

If your application talks to the grid through JCache, Spring Cache, Spring Session or Hibernate rather than the native API, this is a dependency and configuration change with no application code touched.

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>4.7.0</version>
</dependency>

The equivalent swaps are documented per integration: JCache (JSR-107), Hibernate second-level cache, and Spring Boot @Cacheable. Micronaut, Quarkus and MyBatis cache implementations are in the same Apache-2.0 distribution.

Path B — Native Objects

Where code calls the grid directly, replace the handle and keep the shape. A Coherence NamedMap or an Infinispan Cache becomes an RMap; a near cache becomes an RLocalCachedMap (a continuous query cache does not — see above):

LocalCachedMapOptions<Long, Order> options =
    LocalCachedMapOptions.<Long, Order>defaults()
        .cacheSize(1000)
        .syncStrategy(LocalCachedMapOptions.SyncStrategy.INVALIDATE);

RLocalCachedMap<Long, Order> orders =
    redisson.getLocalCachedMap("orders", options);

Two practical notes. Grid caches are often configured with a default expiry that has no equivalent on a plain RMap — use RMapCache where you relied on it. And where the grid gave you cache listeners, the replacement is either an RTopic you publish to explicitly or Valkey and Redis keyspace notifications; the semantics differ enough to be worth a deliberate design decision rather than a mechanical translation.

For the broader category — Hazelcast, GemFire, Geode, Ignite and where each sits in 2026 — see our in-memory data grid comparison. We keep step-by-step guides for the neighboring grids too: Hazelcast, GemFire and Apache Geode and Apache Ignite. For the licensing picture across the wider ecosystem, see Redis alternatives in 2026.

Community vs. PRO

Everything described above — the maps, locks, counters, queues, semaphores, latches, near cache, JCache, Hibernate, Spring Cache and Spring Session integrations — is in the Apache-2.0 community edition. TLS and authentication come with it too, because they are the server's responsibility rather than a licensed client feature. On this axis there is no contrast to draw with either product here: Infinispan is Apache-2.0 throughout and Coherence CE includes its security model. It is a wash.

Redisson PRO adds the capabilities that grid migrations specifically tend to need: data partitioning of a single structure across cluster nodes, XA transactions through an XAResource for JTA participation, Multi Cluster mode for active-passive replication across independent clusters, reliable messaging with a JMS 3.1 provider, observability across more than 30 metrics and 20 monitoring systems with OpenTelemetry tracing, and 24×7 support. If you are replacing Coherence Grid Edition or a supported Red Hat Data Grid subscription, that is the row-for-row comparison to make — not community edition against a commercial grid.

Frequently Asked Questions

Is Oracle Coherence Free?

Coherence Community Edition is, under the Universal Permissive License 1.0, and it includes more than most people assume — persistence, security, Management over REST, reporting, the gRPC proxy, the Kubernetes Operator, coherence-concurrent and distributed queues. Oracle's own repository README lists nine features that CE does not include, and three of them are ordinary application requirements rather than exotic grid features: HTTP session management (Coherence*Web), the transaction framework, and federation and WAN support. Reaching any of those means Enterprise Edition at $11,500 per processor or Grid Edition at $25,000, plus annual support. Coherence is not included in WebLogic Server Suite; it is licensed separately.

Can I Point a Redis Client at Infinispan?

Yes, through Infinispan's RESP endpoint, with three caveats. It supports RESP3 only and errors on RESP2, so Redisson needs protocol: RESP3 set explicitly because it defaults to RESP2. Infinispan provides a relaxed, configurable isolation level rather than Redis's serializable behaviour, so multi-key commands such as MSET can be observed partially applied. And Streams, FUNCTION and OBJECT are not implemented, which rules out RStream, RReliableTopic and reliable messaging. It is a good bridge during a migration and a poor destination.

Is Redisson a Drop-In Replacement for Infinispan or Coherence?

At the API level, largely yes for cache, map, lock, counter, queue and session usage — and if you use the grid through JCache, Spring Cache, Spring Session or Hibernate, it is a dependency and configuration change. Three qualifications matter more than the API mapping does: a community-edition RMap or queue lives on one primary rather than being partitioned across the cluster, the free queues are at-most-once rather than acknowledged, and replication is asynchronous where a grid acknowledges backups synchronously. For entry processors, continuous query caches, in-JVM embedded data, CohQL or Ickle it is not a drop-in at all. Audit which list your code falls into before committing to a date.

What Happens to Entry Processors and CohQL?

Entry processors have no direct equivalent. Atomic read-modify-write maps well to a Lua script for primitive values, but Lua cannot see Redisson's codec, so for a map of Java objects there is no server-side atomic mutation at all and you fall back to read-modify-write under a distributed lock; work that fans out across partitions has to move into the application or into RExecutorService workers, which do not execute on the node owning the data. CohQL and Ickle map partly onto Valkey and Redis search and secondary indexes, and complex analytical queries usually belong in the system of record rather than the cache.

Do I Still Need to Run a Cluster?

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. The difference from a grid is that the data tier stops being coupled to your application JVMs: deployments no longer trigger rebalancing, and the server's Java version is no longer your problem, which is precisely what Infinispan's Java 25 server requirement makes concrete.

When Should You Not Use Redis?

When you need code executing on the node that owns the data, when your latency budget cannot absorb a network hop and the data must live in the application JVM, or when your access pattern is genuinely relational — joins, aggregations and ad-hoc queries over a large dataset. Those are the cases where keeping a data grid, or using a database, is the right answer. For distributed caching, coordination, sessions and queues, a Valkey or Redis server with a capable Java client is less to operate and covers the ground.