I built Lux because Redis is single-threaded and hasn't changed architecturally since 2009. Lux uses a sharded concurrent architecture in Rust with per-shard reader-writer locks, zero-copy RESP parsing, and pipeline batching. It speaks RESP natively so every Redis client works unchanged. We benchmarked against Redis 7, Valkey 9, and KeyDB with redis-benchmark (50 clients, 1M requests) - full results in the README. The Docker image is ~1MB on ARM. MIT licensed, no plans to change that. If you don't want to self-host, there's managed hosting at luxdb.dev. Happy to answer questions about the architecture or benchmarks.

Why isn’t this getting any love? What’s the catch?

Very cool. Clean.

Good read here - https://www.luxdb.dev/architecture

Discussion in Rust's subreddit, with some fair criticism: https://old.reddit.com/r/rust/comments/1ruq7tk/lux_a_rust_re...

Some highlights that made me think:

> It's easy to say you're faster if you don't actually support everything or maybe even made a mistake.

> I don't see any tests so I wouldn't use this.

---

> the repo has 5 commits and the first one is from 3 hours ago. "I've been working on" is probably more accurately "this morning I asked an ai to write this for me".

---

> The single-threaded design of redis was specifically so that operations are ordered sequentially, so that the WAL-like log would be replayable and you'd get the exact same state as when shutting down the server.

> Did you take any measures to ensure a sequential order of executed commands?