Valkey GLIDE vs Redisson: Choosing a Valkey Client for Java

Valkey GLIDE and Redisson are both listed as Java clients on Valkey's client page, GLIDE as a client the Valkey project maintains itself. They are built for different jobs. GLIDE is a command client: a Rust core shared with GLIDE's clients for other languages, under an asynchronous Java API that sends everything over one connection per node. Redisson is a pure-Java client that wraps Valkey commands in distributed Java objects, locks, caches and queues, with synchronous, asynchronous, Reactive and RxJava APIs.

Redisson is our product. Every statement about GLIDE below comes from GLIDE's documentation, its source code or our own tests, and the page says where GLIDE is ahead. The versions compared are GLIDE 2.5.3 and Redisson 4.8.0, the latest releases on Maven Central on October 30, 2026, and the code samples were run against Valkey 9.0.0. For the wider field, see Valkey Java clients, and for GLIDE against the Valkey project's other Java client, Valkey GLIDE vs valkey-java.

Valkey GLIDE vs Redisson at a Glance

Architecture: A Rust Core or Pure Java

GLIDE's README describes it as "implemented using a core driver framework written in Rust". The core handles connections, cluster topology, retries and reconnection once, and each language binds to it, so a Python service and a Java service on the same cluster get the same routing and failover logic. For a company running several languages against Valkey, that consistency is GLIDE's strongest argument.

The cost on the JVM is a native library. GLIDE publishes a jar per platform, selected with a Maven classifier, for Linux (glibc and musl) on x86-64 and ARM64, macOS on x86-64 and ARM64, and Windows on x86-64, and an unclassified jar that bundles all of them. Container images need the right classifier, and a platform outside that list, such as Windows on ARM, has no build. GLIDE's Java README says Alpine Linux is not supported, although musl jars are published. Redisson runs on Netty in plain Java, so it goes wherever the JVM does.

One Connection per Node, or a Pool

GLIDE sends every request from every thread through one multiplexed connection per node and pipelines them. Its documentation says "using a single client instance (a single connection) is the best way to ensure high performance". GLIDE's connection-management guide lists the cases where that connection gets in the way:

• Blocking commands. A BLPOP holds up every command queued behind it, so GLIDE recommends "a new client for each blocking command".

• WATCH. It is connection state, so a WATCH on one thread watches the keys for every thread, and an EXEC on one thread unwatches them for all. GLIDE says separate clients are required.

• Pub/sub and large values. High-throughput pub/sub and large values slow every other request on a shared connection, and GLIDE suggests a dedicated client for them.

Redisson keeps a pool per node, 64 connections at most and 24 kept idle by default, plus a pool of up to 50 connections for subscriptions. A blocking read such as RBlockingQueue.take() holds one pooled connection while it waits, and the rest of the application carries on through the others, so one RedissonClient handles blocking reads and pub/sub. Redisson has no WATCH API to share: RTransaction uses locks instead. The trade is more connections per node, which matters on servers with a low maxclients limit. Both pool sizes can be changed, and the best practices for Java applications cover sizing them.

Connecting

The same set and get, with each client:

// Valkey GLIDE: every command returns a CompletableFuture
GlideClientConfiguration config = GlideClientConfiguration.builder()
        .address(NodeAddress.builder().host("localhost").port(6379).build())
        .requestTimeout(1000)   // milliseconds; the default of 250 includes retries and reconnects
        .build();

try (GlideClient glide = GlideClient.createClient(config).get()) {
    glide.set("greeting", "hello").get();
    String value = glide.get("greeting").get();
}

// Redisson: blocking calls by default, with async, Reactive and RxJava views of the same objects
Config config = new Config();
config.useSingleServer().setAddress("valkey://localhost:6379");
RedissonClient redisson = Redisson.create(config);

RBucket<String> greeting = redisson.getBucket("greeting", StringCodec.INSTANCE);
greeting.set("hello");
String value = greeting.get();
RFuture<String> pending = greeting.getAsync();

redisson.shutdown();

To use GLIDE synchronously, call .get() on each future, as above. For non-blocking code, Redisson's redisson.reactive() and redisson.rxJava() return the same objects with Reactor and RxJava types; see non-blocking Valkey and Redis in Java.

Defaults That Change Behaviour When You Switch

Code that works on one client can fail or read different data on the other with every setting left at its default. These are the ones to carry across on purpose:

Feature by Feature

The table lists what each client gives you as an API. "Commands only" means GLIDE has the matching Valkey commands and your code does the rest, such as serializing values. The sections after the table cover the rows that need more than a cell.

Valkey Server Features

Some Valkey server features reach Java code only once the client implements them. The first three are Valkey-only, and the last needs the module loaded on the server:

GLIDE shipped AZ affinity first, in version 1.2 in November 2024. How to turn each feature on with Redisson is in the Valkey-only settings section of the Redis to Valkey migration guide.

Locks, Collections and Queues

The largest difference is what each client gives you beyond commands. GLIDE's own summary of the two clients puts it this way: "Redisson offers rich distributed data structures and services (locks, semaphores, queues, etc.)", while "Glide focuses on core Redis commands with high performance". With GLIDE, a distributed lock is code you write and maintain.

RLock lock = redisson.getLock("lock:order:1234");
if (lock.tryLock(5, TimeUnit.SECONDS)) {   // wait up to 5 seconds for the lock
    try {
        // critical section: the watchdog extends the 30-second lease while this thread holds the lock
    } finally {
        lock.unlock();
    }
}

RLock implements java.util.concurrent.locks.Lock, is reentrant, wakes waiting threads over pub/sub instead of polling, and renews its lease while the holder is alive. The same family includes fair, read/write, fenced, spin and multi locks, semaphores and countdown latches, listed in the locks and synchronizers documentation. Beyond locks, Redisson has maps, sets, lists, blocking queues, streams, rate limiters, atomic counters and Bloom filters, each implementing the matching Java interface where there is one. With GLIDE, each of these is a set of commands and, where it has to be atomic, a Lua script. How to use Redis locks in Java covers the lock patterns in more depth.

Client-Side Caching

GLIDE has had a client-side cache since 2.4.0. According to its documentation, it caches the replies to GET, HGETALL and SMEMBERS and nothing else. Entries expire by TTL. In Java only, since 2.5.0, it can also ask the server for invalidations, using CLIENT TRACKING ON BCAST, which sends the client an invalidation for every key modified anywhere on the server:

// Valkey GLIDE: the cache belongs to the client configuration
ClientSideCache cache = ClientSideCache.builder()
        .maxCacheKb(10_240)
        .entryTtlMs(60_000)
        .serverAssisted(true)   // Java only; needs RESP3, which is GLIDE's default
        .build();

GlideClientConfiguration config = GlideClientConfiguration.builder()
        .address(NodeAddress.builder().host("localhost").port(6379).build())
        .clientSideCache(cache)
        .build();

Without serverAssisted, GLIDE's documentation warns that entries can go stale "if any client modifies the underlying data, including the same client that cached the value". We confirmed it on Valkey 9.0: in TTL-only mode, a GLIDE client that cached a price and then ran its own SET read the old price back. With server-assisted mode on, the same test returned the new value. GLIDE's documentation also notes that server-assisted mode is unavailable on ElastiCache Serverless, which rejects CLIENT TRACKING.

Redisson's near cache is a map whose entries live in the JVM and are invalidated, or updated, one by one when any Redisson instance writes to the map. It does not depend on CLIENT TRACKING or RESP3. The flip side is that it only sees writes made through Redisson: an HSET from another client or the CLI leaves the cached entry stale until its local TTL runs out, where GLIDE's server-assisted mode catches writes from any client.

import org.redisson.api.options.LocalCachedMapOptions;

RLocalCachedMap<String, String> prices = redisson.getLocalCachedMap(
        LocalCachedMapOptions.<String, String>name("prices")
                .cacheSize(10_000)
                .timeToLive(Duration.ofMinutes(10))
                .syncStrategy(LocalCachedMapOptions.SyncStrategy.INVALIDATE));

prices.put("product:42", "100");
String price = prices.get("product:42");   // read from JVM memory until a Redisson instance changes the entry

For buckets, maps, sets, lists, sorted sets, queues, streams and geo objects, redisson.getClientSideCaching(...) adds tracking-based caching on RESP3. It drops a whole object on any change, and Redisson's own documentation steers maps to the local cached map instead. Redisson PRO adds local-cached versions of its Spring Cache, JCache and Hibernate caches.

Pipelining and Transactions

GLIDE batches commands in a Batch (or ClusterBatch), and one constructor flag decides whether it is a plain pipeline or a MULTI/EXEC transaction. Redisson's RBatch is a pipeline by default and becomes atomic with an ExecutionMode such as IN_MEMORY_ATOMIC. RTransaction is a separate API, with locking and rollback over Redisson objects. Redis pipelining explains why keeping throughput and atomicity apart matters.

Pub/Sub

GLIDE used to fix a client's subscriptions when the client was created. Since 2.3.0 it can also subscribe and unsubscribe at runtime. Messages go to a callback set in the client's configuration, or into a queue the application polls with getPubSubMessage(), and GLIDE resubscribes after reconnects and topology changes. Sharded pub/sub is supported in cluster mode.

Redisson's RTopic, RPatternTopic and RShardedTopic take listeners at any time, on subscription connections kept apart from the command pool. Redisson PRO adds Reliable Queue, with acknowledgements, visibility timeouts and dead-letter queues, and Reliable PubSub, with consumer groups and delivery limits.

Running GLIDE and Redisson in One Application

Teams do run both, for example Spring Data Valkey on GLIDE for repositories and caching, and Redisson for locks and queues. That works against the same server, with two rules. The first is serialization. Redisson's default codec is Kryo5Codec, and GLIDE works with plain strings and bytes:

// StringCodec writes the plain UTF-8 string that GLIDE expects
RBucket<String> name = redisson.getBucket("user:1:name", StringCodec.INSTANCE);
name.set("Ada");
String fromGlide = glide.get("user:1:name").get();   // "Ada"

// Written with the default codec, the same value is Kryo-encoded
redisson.getBucket("user:2:name").set("Ada");
glide.get("user:2:name").get();
// ExecutionException: GlideException: Unexpected return type from Glide: got GlideString expected String
GlideString raw = glide.get(GlideString.gs("user:2:name")).get();   // bytes 03 41 64 E1

Use StringCodec, or another codec both sides can read, for any key that both clients touch. Serialization codecs for Valkey and Redis compares the options.

The second rule is to leave Redisson's own structures to Redisson. An RLock, for instance, is a hash whose field names the holding client and thread, renewed by a watchdog and released by a script, and a local cached map publishes its invalidations on a channel of its own. GLIDE code that writes to those keys directly breaks the protocol, and a GLIDE write to a hash that Redisson near-caches leaves Redisson's local copy stale. Two clients also means two sets of connections per node.

Moving From GLIDE to Redisson

The move the other way is mostly mechanical: swap the dependency, build a Config, set the read mode to match GLIDE's primary-only default, set the codec to StringCodec or ByteArrayCodec so Redisson can read what GLIDE wrote, and replace command calls with objects. The Valkey GLIDE to Redisson migration guide walks through each step with side-by-side code, and the AZ affinity guide maps GLIDE's availability-zone strategies to Redisson's read modes.

Frequently Asked Questions

Is Valkey GLIDE Better Than Redisson?

It depends on the job. GLIDE suits teams that want the same client design across several languages, built-in OpenTelemetry and IAM authentication, and plain commands from asynchronous code. Redisson suits Java applications that need distributed locks, collections, queues or a near cache, synchronous and reactive APIs, framework integrations, or a support contract. Both are listed as Java clients on Valkey's client page.

Does Valkey GLIDE Support Distributed Locks?

Not as an API. A GLIDE lock is built from SET with NX and an expiry, plus a Lua script, or DELIFEQ on Valkey 9.0 and later, to release it only if the caller still holds it. Nothing renews the expiry unless you schedule the renewal yourself, waiting callers have to poll, and the lock is not reentrant. Redisson's RLock implements java.util.concurrent.locks.Lock with a watchdog that renews the lease.

Can I Use Valkey GLIDE and Redisson in the Same Application?

Yes, against the same Valkey server, as long as both clients serialize shared keys the same way. Redisson's default codec is Kryo, which GLIDE's String API cannot read, so use StringCodec for keys both clients touch. Leave Redisson's own structures, such as lock hashes, to Redisson.

Does Valkey GLIDE Have a Synchronous API?

GLIDE's Java API is asynchronous and returns a CompletableFuture for every command, so synchronous code calls get() on each one. A separate artifact, valkey-glide-jedis-compatibility, offers a Jedis-style synchronous API on top of GLIDE. Redisson's objects have synchronous, asynchronous, Reactive and RxJava versions.

Does Redisson Support Valkey?

Yes. Redisson supports Valkey 7.2.5 and later, accepts valkey:// and valkeys:// addresses, and is listed as a Java client on Valkey's client page. It added replica-redirect handling in 4.1.0, numbered databases in cluster mode in 4.0.0, and availability-zone read modes in 4.8.0.

Which Client Does Spring Data Valkey Use?

Valkey GLIDE by default, with Lettuce and Jedis as alternatives. Spring Data Valkey is the Valkey project's fork of Spring Data Redis. Redisson works through Spring Data Redis instead, with its own connection factory, so existing RedisTemplate code keeps working.

Next Steps

For GLIDE, Redisson and valkey-java side by side, see Valkey Java clients, and for GLIDE against valkey-java, Valkey GLIDE vs valkey-java. For who supports the server and the client, see which companies offer Valkey support, and for the server-side differences, Valkey vs Redis. The feature comparison lists what Redisson PRO adds to the Community Edition, and a PRO trial lets you test it against your own cluster.

Similar articles

• Valkey GLIDE to Redisson Migration Guide
• Valkey GLIDE vs valkey-java: Differences and When to Use Each
• Feature Comparison: Redisson vs Lettuce
• Redisson vs Jedis
• Redisson vs Spring Data Redis