Valkey GLIDE vs valkey-java: Differences and When to Use Each

Valkey GLIDE and valkey-java are the two Java clients that the Valkey project maintains itself. GLIDE is an asynchronous client whose connection handling, clustering and failover logic live in a Rust core shared by every GLIDE language. valkey-java is a fork of Jedis: a blocking, pooled client with the Jedis API under the io.valkey package.

For new code on Valkey 8 or 9, GLIDE is the more capable and more actively developed of the two, as long as an asynchronous API and a native library are acceptable. valkey-java fits existing Jedis-style code and Sentinel deployments, but its latest release is from October 2025. If you need more than commands, such as locks, collections or caching, the third Java client on Valkey's client list is Redisson, which we build.

This guide compares GLIDE and valkey-java on the points that decide the choice in practice. For a wider table that includes Redisson, and for where Jedis and Lettuce stand on Valkey, see Valkey Java clients compared. Versions are the latest stable releases on Maven Central as of October 30, 2026: GLIDE 2.5.3 and valkey-java 5.5.0.

What Is Valkey GLIDE?

Valkey GLIDE (General Language Independent Driver for the Enterprise) describes itself as "an official open-source Valkey client library", backed and supported by AWS and Google Cloud. Version 1.0 shipped in July 2024. Java, Python, Node.js and Go clients are built from one repository, and all of them share a core written in Rust. The Java client is a layer over that core, which it calls through JNI.

Every command returns a CompletableFuture. A client sends its commands over one multiplexed connection to each node, so a single instance serves every thread in the application without a pool. Topology discovery, reconnection and retries happen in the core, and the configuration model is the same in every language, which is a large part of GLIDE's appeal to teams running services in several of them.

Releases are frequent: 2.3.0 shipped in March 2026, 2.4.0 in May, 2.5.0 in July and 2.5.3 in September, and 2.6.0 has been in release candidate since mid-October. Those releases added dynamic Pub/Sub subscriptions (2.3), client-side caching (2.4), and server-assisted cache invalidation and an opt-in circuit breaker (2.5).

What Is valkey-java?

valkey-java is, in its README's words, "Valkey's Java client, derived from Jedis fork". It is MIT-licensed, targets Java 8, and keeps the Jedis 5 API almost class for class: Jedis, JedisPool, JedisPooled, JedisCluster and JedisSentinelPool are all there, moved from redis.clients.jedis to io.valkey. Commands block the calling thread, and concurrency comes from a commons-pool2 connection pool. Upstream Jedis has since moved on: 7.2 made the RedisClient builders the recommended entry points and 8.0 removed JedisPooled, so valkey-java code looks like Jedis code from before those changes.

It carries a few Valkey-specific additions. It declares the CLIENT CAPA redirect capability on every connection by default, supports the conditional SET ... IFEQ and DELIFEQ commands, and in 5.5.0 added the hash-field expiration commands that arrived in Valkey 9.0. Releases are infrequent. Maven Central lists three: 5.3.0 in August 2024, 5.4.0 in July 2025 and 5.5.0 on October 10, 2025. The last commit to the repository is from December 22, 2025. The README carries no deprecation notice, and its roadmap still lists asynchronous support and fewer connections in cluster mode as future work.

GLIDE vs valkey-java, Head to Head

Programming Model

valkey-java is synchronous: each call returns the reply. GLIDE is asynchronous: each call returns a future that you chain or block on with get(). Blocking on every call works, but it gives up the concurrency GLIDE is designed for and makes the code longer than its Jedis equivalent. If your code base is synchronous and will stay that way, valkey-java's model is the simpler fit. GLIDE also publishes a Jedis-compatible synchronous layer, covered below, but it implements only part of the Jedis API.

Connections and Threads

A valkey-java connection isn't thread-safe, so each thread borrows one from the pool while it runs its commands. Concurrency is capped by the pool size (maxTotal, 8 by default, per node in cluster mode), and a slow command keeps its connection until it returns. GLIDE sends requests from all threads over one connection per node and limits them with inflightRequestsLimit, 1,000 by default. Fewer connections means fewer client slots used on the server, which helps on managed services that cap connections per node.

Because the connection is shared, a blocking command such as BLPOP holds up every command queued behind it, so GLIDE's documentation recommends a separate client for blocking commands and suggests one for busy Pub/Sub. With valkey-java, a blocking command simply occupies one pooled connection.

Topologies: Cluster, Replicas and Sentinel

Both clients support cluster mode and follow MOVED and ASK redirects. They differ on the other two deployment questions:

• Reads from replicas. GLIDE has six read strategies: PRIMARY (the default), PREFER_REPLICA, ALL_NODES and three availability-zone modes. valkey-java has none: in a cluster it sends every command to the primary that owns the slot.

• Sentinel. valkey-java supports it through JedisSentinelPool and JedisSentineled. GLIDE doesn't. Its Java configuration has a standalone mode, which takes a list of node addresses and detects the primary among them, and a cluster mode. Neither asks Sentinel where the primary is.

If your deployment uses Sentinel today, that difference may settle the choice on its own.

Valkey-Only Features

Valkey has added server features that Redis doesn't have, and Java code can only use one once its client implements it:

Replica redirect matters in standalone and Sentinel deployments, where a failover can leave a client connected to a node that has just become a replica. With the capability declared, that node answers reads and writes with a redirect to the new primary instead of serving the read itself or rejecting the write. Lua scripts are not redirected. The client has to follow the redirect, and in valkey-java only UnifiedJedis built on a RedirectConnectionProvider does; JedisPool and JedisSentinelPool throw a JedisRedirectionException. Because the capability is on by default, a valkey-java pool pointed at a replica gets redirects even for reads, unless the connection sends READONLY or the client configuration sets clientCapaConfig(ClientCapaConfig.DISABLED).

Availability-zone reads matter on AWS and Google Cloud, where a read served from another zone adds latency and a transfer charge. AZ affinity for Valkey in Java covers the read modes and the cost arithmetic.

Defaults That Change Behaviour

Both clients send reads to the primary by default, but two other defaults differ enough to surprise anyone switching between them:

• Timeouts. GLIDE's requestTimeout defaults to 250 milliseconds and covers sending the request, waiting for the reply and any reconnection or retry along the way. valkey-java's connection and socket timeouts default to 2,000 milliseconds. A Lua script that runs for 400 milliseconds succeeds on valkey-java and times out on GLIDE until you raise the setting.

• Protocol. GLIDE speaks RESP3 unless told otherwise. valkey-java stays on RESP2 unless you ask for RESP3. It matters for custom commands, whose replies can come back in a different shape under RESP3, and for server-assisted caching, which requires RESP3.

Operations and Security

GLIDE builds in more of what production teams usually add themselves: OpenTelemetry traces and metrics, IAM authentication for ElastiCache and MemoryDB with token refresh (since 2.2), client-side caching with a TTL and optional server-assisted invalidation, lazy connection, the 2.5 circuit breaker, and experimental value compression for GET and SET. valkey-java inherits Jedis's hooks, such as a credentials provider you can feed tokens through, but has no built-in tracing, metrics, caching or cloud authentication.

Packaging and Runtime

valkey-java is a 0.9 MB pure-Java jar plus commons-pool2, slf4j-api, gson and org.json. GLIDE needs its native library. It publishes one jar per platform, selected with a Maven classifier (Linux on x86_64 and ARM64 with glibc or musl, macOS on Intel and Apple silicon, Windows on x86_64), and a larger jar that bundles all of them. The Rust library alone is about 14 MB uncompressed for Linux x86_64. GLIDE runs on JDK 8 or later, and its README strongly recommends JDK 11 or later.

Release Activity and Support

Both projects are open source under the valkey-io organisation. GLIDE's README says it is backed and supported by AWS and Google Cloud, but neither project sells a support contract for the client. They differ in release cadence. GLIDE ships most months; valkey-java has released about once a year, three times in total, and the latest was a year ago. For a new project that matters, because a client on that cadence picks up commands from newer Valkey versions late, and fixes depend on a small team. Which companies offer Valkey support covers support for the server and the clients.

The Same Operations in Both Clients

Here is a set and a get, followed by a two-command pipeline. In valkey-java, a pooled Jedis connection runs both, and the pipeline returns its replies when you sync it:

// valkey-java 5.5.0
import io.valkey.Jedis;
import io.valkey.JedisPool;
import io.valkey.JedisPoolConfig;
import io.valkey.Pipeline;
import java.util.List;

JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(32);                       // caps concurrent commands

// create the pool once per application; it is closed here only to keep the example short
try (JedisPool pool = new JedisPool(poolConfig, "localhost", 6379);
     Jedis jedis = pool.getResource()) {
    jedis.set("user:1:name", "Alice");
    String name = jedis.get("user:1:name");       // "Alice"

    Pipeline pipeline = jedis.pipelined();
    pipeline.set("a", "1");
    pipeline.incr("counter");
    List<Object> replies = pipeline.syncAndReturnAll();
}

In GLIDE, one client serves every thread. Each call returns a future, and a pipeline is a Batch, the same class that sends a MULTI/EXEC transaction when its flag is true:

// Valkey GLIDE 2.5.3
import glide.api.GlideClient;
import glide.api.models.Batch;
import glide.api.models.configuration.GlideClientConfiguration;
import glide.api.models.configuration.NodeAddress;
import java.util.concurrent.CompletableFuture;

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

try (GlideClient client = GlideClient.createClient(config).get()) {
    client.set("user:1:name", "Alice").get();            // block on the future...
    String name = client.get("user:1:name").get();       // "Alice"

    CompletableFuture<String> bob = client.set("user:2:name", "Bob")
            .thenCompose(ok -> client.get("user:2:name"));   // ...or chain, then wait once
    String bobName = bob.get();                           // "Bob"

    Batch batch = new Batch(false)                       // false = pipeline, true = MULTI/EXEC
            .set("a", "1")
            .incr("counter");
    Object[] replies = client.exec(batch, true).get();
}

GLIDE vs valkey-java vs Redisson at a Glance

Where Redisson Fits

GLIDE and valkey-java are both command-level clients: they send Valkey commands and return the replies. Once an application needs a distributed lock, a shared cache or a queue, someone has to build it on top, usually out of SET NX, Lua scripts and retry loops. Redisson, the third Java client on Valkey's list, ships those pieces, and it is the only one of the three that the list tags with all seven of the advanced features it tracks. (The tags haven't yet caught up with GLIDE's client-side caching, added in 2.4.) It adds:

• Java objects instead of commands. Over 60 distributed objects and services, including Map, Set, List, Queue, locks, semaphores and rate limiters, each implementing the matching java.util or java.util.concurrent interface where one exists.

• Four APIs over one object. Synchronous, asynchronous, Reactive Streams and RxJava 3, so synchronous and reactive code can share the same data.

• No native library. Pure Java on Netty, so it runs wherever the JVM does.

• Reliable messaging. Reliable PubSub, Reliable Queue and JMS API implementation.

• AI. Semantic Caching, Agent Memory, Vector Store, Embeddings Cache, Spring AI Starters

• Every topology. Cluster, Sentinel, replicated, master/replica and single-server deployments, with availability-zone read modes in every topology that has replicas since 4.8.0.

• Caching and framework integrations. Client-side caching, Spring Cache, JCache, Hibernate and Spring Session, plus a connection factory for Spring Data Redis.

• Support. Redisson PRO adds 24x7 technical support with an SLA.

Config config = new Config();
config.useClusterServers()
      .addNodeAddress("valkey://127.0.0.1:7000")
      .setReadMode(ReadMode.AZ_AFFINITY)             // replicas in this zone first
      .setClientAvailabilityZone("us-east-1a");
RedissonClient redisson = Redisson.create(config);

RMap<String, Integer> scores = redisson.getMap("leaderboard");
scores.put("player:1", 100);                          // synchronous
RFuture<Integer> previous = scores.putAsync("player:2", 90);   // same map, asynchronous

RLock lock = redisson.getLock("job:lock");
lock.lock();
try {
    // one thread across all JVMs runs this at a time
} finally {
    lock.unlock();
}

redisson.shutdown();

Already on GLIDE? Valkey GLIDE vs Redisson compares the two in depth, and the Valkey GLIDE to Redisson migration guide maps GLIDE's commands to Redisson objects. Coming from valkey-java, the Jedis to Redisson migration guide applies almost line for line, because it starts from the same JedisPool and JedisPooled API, with io.valkey in place of redis.clients.jedis.

Frequently Asked Questions

Is valkey-java Still Maintained?

It is still published under the valkey-io organisation, and its README has no deprecation notice, but activity is low. The latest release is 5.5.0, from October 10, 2025, Maven Central lists three releases in total, and the last commit to the repository was on December 22, 2025. GLIDE, the other Java client the Valkey project maintains, shipped versions 2.3, 2.4 and 2.5 between March and September 2026.

Is Valkey GLIDE Faster Than valkey-java?

We found no published benchmark that compares the two. The designs favour different workloads: GLIDE multiplexes many concurrent requests over one connection per node, while valkey-java needs a pooled connection for each command in flight. GLIDE's repository includes a benchmark tool that compares it with Jedis and Lettuce. Because valkey-java shares the Jedis API, you can swap it in for Jedis and run the tool with your own payload sizes and concurrency.

Can I Run valkey-java Code on GLIDE Without Rewriting It?

Partly. GLIDE's Jedis compatibility layer implements the Jedis API on top of GLIDE in the redis.clients.jedis package, so valkey-java code needs its io.valkey imports changed and a few classes, such as JedisPoolConfig, replaced. In version 2.5.3 it covers the common commands, Lua scripts and basic transactions, but not Jedis pipelining, JedisPubSub subscriptions or Sentinel, and unsupported methods can fail at run time rather than at compile time.

Does Valkey GLIDE Support Sentinel?

No. GLIDE's Java client connects in standalone mode, to a list of node addresses, or in cluster mode, and has no Sentinel configuration. Spring Data Valkey reflects this: Sentinel works there only with the Lettuce or Jedis drivers. valkey-java and Redisson both support Sentinel.

Which Client Does Spring Data Valkey Use?

GLIDE by default: the Spring Boot starter pulls it in and selects it unless you choose another driver. Lettuce and Jedis are optional drivers, and the Jedis driver is Redis's own Jedis rather than valkey-java. Sentinel requires Lettuce or Jedis, and the reactive API requires Lettuce.