Migrating from Apache Ignite to Valkey or Redis

If you run Apache Ignite for distributed caching and data structures and you're evaluating a move to Valkey or Redis, this guide walks the migration using Redisson as the Java client. Redisson turns Valkey or Redis into a full distributed-objects platform — RMap, RLock, RQueue, and 50+ more — with a broader collection and lock model than Ignite's, richer async and reactive APIs, and managed-cloud support Ignite doesn't offer.

It helps to be clear about scope. Apache Ignite is a large platform — a distributed database and compute engine with ANSI-99 SQL, ACID transactions, native disk persistence, and a compute grid. This guide is about the very common case of using Ignite as a distributed cache and data-structure layer, where Redisson on Valkey or Redis is the simpler operational fit: a client to a server you likely already run, rather than an Ignite cluster you stand up and manage. For a feature-by-feature breakdown, Redisson maintains a Redis vs. Apache Ignite comparison and an overview of why Redisson is a strong Apache Ignite alternative; this guide focuses on how to make the move.

Signs You're Ready to Move Off Ignite

• You use Ignite mainly as a cache and distributed data-structure layer — maps, queues, locks, atomics — rather than as a SQL database or compute grid.
• You already run Valkey or Redis and would rather consolidate than operate a separate Ignite cluster.
• You want managed-cloud caching — AWS ElastiCache or MemoryDB, Azure Cache, Google Cloud Memorystore — which Ignite doesn't offer from the major providers.
• You want a wider set of distributed collections and locks, and first-class async, reactive, and RxJava APIs, which Ignite's client only partially provides.

Apache Ignite vs. Redisson at a Glance

For the full table, see the Redis vs. Apache Ignite comparison.

What Redisson Gives You Over Ignite

• A wider distributed-collection suite. Beyond the maps, sets, lists, and queues Ignite provides, Redisson adds distributed objects Ignite doesn't — deques, sorted sets, multimaps, a JSON store, and specialized queues (delayed, transfer, reliable) — all implementing the familiar java.util and java.util.concurrent interfaces.
• A richer lock family. Ignite offers locks, semaphores, and count-down latches; Redisson's lock family adds reentrant RLock with a watchdog, RFencedLock with a fencing token, and fair, multi-, and read/write locks.
• Reliable messaging and JMS (Redisson PRO). Beyond basic pub/sub, Redisson PRO adds persistent, at-least-once messaging — a Reliable Queue and Reliable PubSub — which also back a JMS and Jakarta Messaging provider (JMS 2.0, 3.0, and 3.1).
• Async, reactive, and RxJava APIs. Every Redisson object has synchronous, asynchronous, Reactive, and RxJava3 variants; Ignite's client offers only partial async support.
• Faster JCache with near cache. Both implement JCache (JSR-107); Redisson's JCache with a near cache reports reads up to 45x faster than a plain remote cache — a vendor benchmark figure, but the near-cache pairing is a Redisson strength.
• Managed-cloud simplicity. Redisson connects to managed Valkey/Redis (AWS ElastiCache and MemoryDB, Azure Cache, Google Cloud Memorystore) with no cluster to operate; Ignite has no fully managed offering from the major cloud providers.

Compatibility

Redisson connects to Redis 3.0+ and Valkey 7.2.5+, via the redis://, rediss://, valkey://, and valkeys:// schemes, including the managed services above. Where Ignite is a cluster you deploy and run, Redisson points at a Valkey or Redis endpoint — often one you already operate.

Two Ways to Bring in Redisson

Many Ignite applications reach it through Spring or JCache, which gives you a low-friction path alongside the native one.

Which Path?

Path A (swap the provider) fits when you use Ignite through Spring Cache or the JCache API and want to change configuration, not call sites. Path B (native objects) fits when you access IgniteCache and Ignite data structures directly and want Redisson's full object model. They combine — swap the provider now, adopt native objects where you need them.

Path A — Swap the Spring Provider

Ignite plugs into Spring's cache abstraction through SpringCacheManager. Swap that for Redisson's manager, and your @Cacheable annotations don't change:

// Ignite — Spring Cache backed by Ignite caches
@Configuration
@EnableCaching
class CacheConfig {
    @Bean
    SpringCacheManager cacheManager() {
        SpringCacheManager manager = new SpringCacheManager();
        manager.setConfiguration(new IgniteConfiguration().setIgniteInstanceName("cache-node"));
        return manager;
    }
}

// Redisson — Spring Cache backed by Valkey/Redis
@Configuration
@EnableCaching
class CacheConfig {
    @Bean
    CacheManager cacheManager(RedissonClient redisson) {
        return new RedissonSpringCacheManager(redisson);
    }
}

Because IgniteCache is a JCache (JSR-107) implementation, a JCache-based setup swaps the same way — replace Ignite's org.apache.ignite.cache.CachingProvider with Redisson's org.redisson.jcache.JCachingProvider, and the javax.cache code is unchanged. See the Spring integration and Spring Cache docs.

Path B — Native Objects

An Ignite node (or thin client) becomes a RedissonClient, and Ignite's caches and data structures map to Redisson objects.

Connection:

// Ignite — start or join a cluster node
Ignite ignite = Ignition.start();
// (thin client: Ignition.startClient(new ClientConfiguration().setAddresses("127.0.0.1:10800")))

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

Cache → RMap:

// Ignite — IgniteCache (a JCache/JSR-107 implementation)
IgniteCache<String, String> cache = ignite.getOrCreateCache("products");
cache.put("1", "Widget");
String value = cache.get("1");

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

Near cache → RLocalCachedMap:

// Ignite — near cache via NearCacheConfiguration
IgniteCache<String, String> cache = ignite.getOrCreateCache(
        new CacheConfiguration<String, String>("products"),
        new NearCacheConfiguration<>());

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

Per-entry TTL → RMapCache:

// Ignite — expiry via a JCache ExpiryPolicy on the cache configuration
CacheConfiguration<String, String> cfg = new CacheConfiguration<String, String>("products")
        .setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(new Duration(TimeUnit.MINUTES, 10)));
IgniteCache<String, String> cache = ignite.getOrCreateCache(cfg);

// Redisson — per-entry TTL (and max-idle)
RMapCache<String, String> mapCache = redisson.getMapCache("products");
mapCache.put("1", "Widget", 10, TimeUnit.MINUTES);

Atomics → RAtomicLong:

// Ignite
IgniteAtomicLong counter = ignite.atomicLong("visits", 0, true);
counter.incrementAndGet();

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

Queues → RBlockingQueue:

// Ignite — IgniteQueue (distributed blocking queue)
IgniteQueue<String> queue = ignite.queue("tasks", 0, new CollectionConfiguration());
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();

Sets → RSet:

// Ignite
IgniteSet<String> set = ignite.set("tags", new CollectionConfiguration());
set.add("java");

// Redisson — RSet implements java.util.Set
RSet<String> rset = redisson.getSet("tags");
rset.add("java");

Locks → RLock / RFencedLock:

// Ignite — IgniteLock (reentrant)
IgniteLock lock = ignite.reentrantLock("order:1234", true, false, true);
lock.lock();
try {
    // critical section
} finally {
    lock.unlock();
}

// Redisson — RLock (watchdog + replica-sync); RFencedLock adds a fencing token
RLock rlock = redisson.getLock("order:1234");
rlock.lock();
try {
    // critical section
} finally {
    rlock.unlock();
}

Technical Considerations and Implementation Pitfalls

• Plan replacements for Ignite's database features. Ignite is also a SQL database and compute engine — ANSI-99 SQL over JDBC/ODBC, distributed ACID transactions, native disk persistence as a system of record, and a compute grid. Redisson is a data client on Valkey or Redis, not a SQL database or compute platform, so those capabilities have no drop-in equivalent. If you rely on them, keep Ignite for that part or plan a separate replacement before cutover; move only the caching and data-structure workloads to Redisson.
• Serialization changes. Ignite uses its binary object format; Redisson uses a configurable codec (Kryo/JSON/etc.). Types you cache must serialize under the codec you choose.
• Cluster → client mindset. Ignite can hold data close to compute; with Redisson every operation is a call to the Valkey/Redis 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 Ignite-to-Redis transfer; plan a dual-write or replay, or treat the cache as cold-fillable on cutover — and note that if Ignite was your system of record (native persistence), you must move that data to a durable store, not just a cache.
• Single object placement in a cluster. By default a Redisson object lives on one master; spreading one large structure across cluster nodes (data partitioning) is a Redisson PRO feature.

Community vs. PRO

Redisson's community edition is Apache 2.0 and covers this whole migration: the full object suite, near cache (RLocalCachedMap), RMapCache, the lock family including RFencedLock, the JCache and Spring Cache integrations, and the executor service — with TLS (rediss:///valkeys://) and password/ACL auth included, since those are the Valkey/Redis server's job. 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. On the Ignite side, Apache Ignite is Apache 2.0 while GridGain offers commercial editions built on it.

Frequently Asked Questions

Is Redisson a Drop-In Replacement for Ignite?

For distributed caching and data structures, it's a broader superset — IgniteCache maps to RMap/RMapCache, and you gain a wider collection suite, richer locks, and async/reactive APIs. Ignite's SQL, ACID transactions, native persistence, and compute grid have no direct equivalent and need a planned replacement rather than a swap.

Do I Still Need to Run a Cluster?

Not an Ignite one. You run Valkey or Redis (single node, cluster, sentinel, or a managed service) and Redisson connects as a client.

Can I Keep My Spring or JCache Code?

Largely yes. If you use Ignite through Spring Cache or the JCache API, you swap the provider to Redisson and your @Cacheable/javax.cache code is unchanged.