redis-rs 2.0 fixes a 68% speed tax. 59% of Rust won't get it

Short answer: redis-rs 2.0.0-rc.1, the Rust client for Redis and Valkey, shipped on Oct 24 2026 with TCP_NODELAY turned on by default. A Redis performance engineer measured the old default costing up to 68% of throughput on a busy async connection. Our pull of crates.io says most of Rust will not see that fix for a long time: 59.3% of the last 30 days of redis downloads went to pre-1.0 versions, and only 1 of the 1,552 crates that depend on redis turns the fast setting on.

TL;DR: The redis crate did 13.6 million downloads from Sep 25 to Oct 25 2026, and 8.1 million of them (59.3%) were 0.x versions, led by 0.27.6 from December 2024 at 3.18 million. Of 1,552 crates that depend on redis, 993 (64%) still require a 0.x version in their newest release, including poem, actix-session and risc0-zkvm. In April the Rust compiler team found 574 crates breaking on old redis versions and had to ask for five backport releases. If your service talks to Redis from Rust, you can turn the fix on today with one line, on any version.

Key numbers

What	Number	Source, checked Oct 25 2026
Throughput lost to the old default (2 to 32 concurrent tasks, one async connection)	39% to 68%	redis-rs PR #2196
Median latency cut by turning TCP_NODELAY on	27% to 46%	redis-rs PR #2196
redis crate downloads, Sep 25 to Oct 25 2026	13,633,318	crates.io API, our pull
Share of those on 0.x (pre-1.0)	59.3%	crates.io API, our pull
Top single version, redis 0.27.6 (Dec 3 2024)	3,178,745 (23.3%)	crates.io API, our pull
Crates that depend on redis	1,552	crates.io reverse dependencies
Of those, newest release still requires 0.x	993 (64%)	crates.io API, our pull
Of those, enable the tcp_nodelay feature	1	crates.io API, our pull
Crates broken on old redis in a Rust compiler experiment	574	redis-rs issue #2054
redis lifetime downloads	119,989,174	crates.io

The fix is one boolean, and it took until 2.0

TCP_NODELAY is a socket flag that turns off Nagle's algorithm. Plain version: Nagle makes your computer hold small outgoing messages for a moment so it can bundle them, which is great for a 1984 telnet session and terrible for a database client that already bundles its own writes.

In redis 1.8.0, the current stable release, TcpSettings::default() sets nodelay: false. We opened the published crate source to check. In 2.0.0-rc.1 the same line reads nodelay: true, with a comment telling you how to turn Nagle back on if you really want it.

The change came from Filipe Oliveira, who lists himself as performance at Redis. His issue #2195 and PR #2196 are the kind of receipts we love: two bare-metal hosts on a dedicated 1 GbE link, three repetitions, kernel samples and packet captures.

• Throughput up 39% to 68% at 2 to 32 concurrent tasks on one multiplexed async connection, with and without mTLS.
• Median latency down 27% to 46%, and the p99.99 tail went from spikes of 4.6 ms to 930 microseconds or less.
• Under the old default, application bytes were stuck waiting in 88.8% of kernel samples, versus 15.4% with the flag on.
• Loopback tests and one-command benchmarks never show it, which is exactly why this hid for years.

The PR also says Jedis, Lettuce, go-redis and StackExchange.Redis all ship with TCP_NODELAY on. So Rust, the language people pick for speed, had the slow default among the big Redis clients. That is lowkey hilarious.

It merged on Jul 4 2026. It shipped to users on Oct 24, as a release candidate of a new major version. Seven 1.x releases went out in between with the slow default still in them. A one-line default that every peer already uses got treated like a breaking change, and that choice is the whole story below.

59% of redis downloads are versions from before 1.0

We pulled per-version download counts for the 90 most downloaded redis releases from the crates.io API, which covers 99.99% of the crate's 32.1 million downloads in the last 90 days. Then we grouped the last 30 days by version line.

The 1.x line, the one maintainers actually support, is 40.7% of downloads. Everything else is 0.x. The single most downloaded version of redis right now is 0.27.6, published Dec 3 2024, with 3.18 million downloads in a month. That is more than the three newest 1.x releases combined.

Downloads are mostly CI and build machines, not people, so read this as "how many builds pulled this version", not "how many companies". It is still the best public signal there is for what code is actually running, and it is not close.

The trend is moving the right way, just slowly. In the week of Jul 27, 1.x did 0.63 million downloads to 0.x's 1.34 million. By the week of Oct 13 it was 1.46 million to 1.78 million. 1.x more than doubled, and 0.x still grew 33% because old lockfiles keep getting rebuilt.

Our bet: 1.x passes 0.x in weekly downloads before the end of November. 2.0 will start that race again from zero, and the 0.x pile will still be there when 3.0 ships.

Who is holding Rust on old redis

crates.io lists 1,552 crates that depend on redis. For each one we read the redis requirement in its newest release. 993 of them (64%) still require a 0.x version. 557 require 1.x. Zero require 2.0, which is fair, since it is a day old.

This is not just abandoned hobby code. Of the 630 dependent crates that shipped a release in the last 90 days, 248 (39%) still pin 0.x. These are the biggest names by downloads of their newest release:

• poem 3.1.12, one of the popular Rust web frameworks, requires redis ^0.32 for its optional Redis features.
• actix-session 0.11.0, the session middleware for actix-web, requires ^0.32.
• risc0-zkvm 3.0.6, a zero-knowledge VM published in July 2026, requires ^0.30.
• testcontainers-modules 0.15.0 requires ^0.32.2, but only for its own tests, so it does not pin your build.
• rocket_contrib 0.4.11 requires ^0.9 and still pulls a redis from 2018 into builds.
• celery, redlock, r2d2_redis and sea-streamer-redis sit on 0.20 to 0.25.

The good guys exist too. deadpool-redis requires ^1.6, bb8-redis ^1.0.0 and loco-rs ^1. If your pool crate is one of those, you are one minor bump from 1.x.

And here is the stat that made us laugh out loud. In the 0.x era, the fast setting was an opt-in Cargo feature called tcp_nodelay. Out of 1,552 dependents, exactly one enables it: websurfx. Everyone else shipped the slow path by default because nobody reads feature lists. Default settings are destiny.

The Rust compiler team already paid for this once

This is not just a speed problem. In April 2026, Rust compiler team member WaffleLapkin (RustNL) opened issue #2054. The compiler wants to change how the never type falls back, a long-planned language change, and a test run over the ecosystem found it breaking a pile of crates that depend on old redis.

The count in that issue: 574 broken crates, spread across redis 0.13 to 0.25. 0.24.0 alone broke 117 and 0.25.4 broke 112. The fix already existed in newer redis. The old versions just never got it.

So the compiler team asked the redis-rs maintainers to cut patch releases for dead lines, and they did: 0.21.8, 0.22.4, 0.23.5, 0.24.1 and 0.25.5 all shipped in May 2026, five months after 1.0. Five releases of code that nobody is supposed to be running, so that a language change would not break the people who never upgraded.

That is the real cost of "0.x forever". It does not land on the lagging crates. It lands on the maintainers, the compiler team and you, the person whose build broke on a toolchain update.

Follow the money: Redis pays, Valkey users win too

Here is the part that gets spicy. Redis 8 is tri-licensed under RSALv2, SSPLv1 or AGPLv3, per the Redis LICENSE file. That licensing fight is why AWS and friends backed Valkey, the BSD-licensed fork, now at 27,508 GitHub stars against Redis's 77,093.

redis-rs itself stays on a BSD-style license, describes itself as a client for "Redis, Valkey and any other RESP compliant DB server", and its CI runs against both. Even the crates.io keywords list "valkey".

So the speed fix came from a Redis Inc. performance engineer, and it speeds up Valkey users exactly as much. We read that as Redis keeping the client neutral because the client is where Rust developers actually meet the brand. Nobody at Redis will say it that way, but owning the default client is worth more than any one benchmark war.

The losers are the framework maintainers who never bumped. Every week a pinned 0.x stays in poem or actix-session, every app on top of it inherits a slower client, a compiler-breakage risk and a support window that already closed. That is not a Redis problem. That is a Rust ecosystem culture problem, and it is giving "1.0 is a scary number".

What this means for you

You do not have to wait for 2.0. Check what you run first:

cargo tree -i redis

On redis 1.x, turn the flag on where you build the client. set_tcp_settings and TcpSettings::set_nodelay are both in 1.8.0:

use redis::{io::tcp::TcpSettings, IntoConnectionInfo};

let info = "redis://127.0.0.1/"
    .into_connection_info()?
    .set_tcp_settings(TcpSettings::default().set_nodelay(true));
let client = redis::Client::open(info)?;

On redis 0.x, it is one Cargo feature: redis = { version = "0.27", features = ["tokio-comp", "tcp_nodelay"] }. Then plan the move to 1.x, because 2.0 is coming and the support window for your line is already shut.

Benchmark it on a real network, not localhost. The PR is clear that loopback hides the effect. More Rust data pieces live on our Rust hub, the Rust topic page and our crates. We also counted how much of Rust still lives on GitHub and what crates.io download counts really measure.

If the redis upgrade breaks your build, hand it to us. Our $99 paid fix does the 0.x to 1.x move for you, and it is fixed within 24 hours or a full refund: get the upgrade done.

Sources

• redis-rs PR #2196, perf: enable TCP_NODELAY by default, Filipe Oliveira, merged Jul 4 2026
• redis-rs issue #2195, TCP_NODELAY is off by default, Filipe Oliveira, Jul 3 2026
• redis-rs 2.0.0-rc.1 release notes, Oct 24 2026
• redis-rs issue #2054, backporting the fix for the never type fallback change, WaffleLapkin, Apr 24 2026
• crates.io, redis crate: versions, per-version downloads and reverse dependencies, our pull Oct 25 2026
• redis 1.8.0 published source and redis 2.0.0-rc.1 published source, src/io/tcp.rs, checked Oct 25 2026
• Redis LICENSE.txt, checked Oct 25 2026
• valkey-io/valkey and redis/redis on GitHub, star counts checked Oct 25 2026