[mattyhogan]

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.

[redfloatplane]

Just a minor thing - your readme claims “MIT licensed forever” but here you say there are “no plans to change that”. Those are different things!

Cool project.

[mattyhogan]

Good point! There's an issue RE license so this will be addressed tomorrow

[0xMohan]

I'm not a DB expert but from what I know, theoretically multi-threading might not bring the performance boost you might expect as on real-world deployment higher contention & latency will kill your throughput as a result your performance would be bad because shared locks will be held longer.

So lock-free single threaded with event-loops DBs should in most cases (when implemented properly) outperform the multi-threaded DBs with shared locks in a high contention & latency environment.

But you claim Lux is more performant than Redis & Valkey, I have no idea on the internals of Lux or the benchmark environment to reject your claims. As more people try it in real workloads, we'll know the actual performance of Lux.

[mattyhogan]

Totally fair, a lot of people on reddit were questioning benchmarking. Should've included in the post

I used the official `redis-benchmark` tool run with Redis, Lux, Valkey, and a few others. Can be reproduced in a few minutes

[deminature]

Adding some tests that prove equivalent functionality to Redis would make people much more likely to adopt this. Very cool project otherwise.

[karunamurti]

Are the commands fully compatible with Redis? We use a lot of commands like TTL PTTL EXPIRE PEXPIRE to create various rate limiters.

[mattyhogan]

Yeah I'd say we're at 80% command coverage with plans to fill it out soon. But all the ones you mentioned are supported! Rate limiters using an INCR / EXPIRE pattern will work just fine