> 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?
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.
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.
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
There are six source files. No comments that I could see on a casual glance. It looks to me as vibed with post processing prompts enforcing minimalism.
To be fair, this thing is a bare bones effort, ie v1 release to public. It looks like there is no config file and associated processing which might add a fair bit of code but that is probably an include and a stanza or two.
If this is redis pared to the bone then it might actually fly. I suppose I ought to look at the source for redis to compare.
Sometimes, the test suite is a moat in open source and can be used to show you are a true 1:1 replacement with 100% compatibility, or with the test suite being closed source to protect against competing rewrites, just like with SQLite.
So this isn’t a “drop-in Redis replacement”. It has no tests at all to verify 1:1 Redis functionality and of course it is fully AI generated.
What's the future of Show HN? What do I as a reader do? just never look at it again? wait until it's used by a million people? Do I have to read the code of every new project posted here? I guess get codex to read it?!?!
Curious about persistence - does this support RDB/AOF snapshots or is it purely in-memory? That's usually the first question that comes up when teams evaluate Redis alternatives.
30 comments
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?
Cool project.
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.
I used the official
redis-benchmarktool run with Redis, Lux, Valkey, and a few others. Can be reproduced in a few minutesTo be fair, this thing is a bare bones effort, ie v1 release to public. It looks like there is no config file and associated processing which might add a fair bit of code but that is probably an include and a stanza or two.
If this is redis pared to the bone then it might actually fly. I suppose I ought to look at the source for redis to compare.
So this isn’t a “drop-in Redis replacement”. It has no tests at all to verify 1:1 Redis functionality and of course it is fully AI generated.
Avoid.