> 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.
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.
Those with a bit more experience understand faster is not always better. Databases thought to be battle-tested encounter incredibly complex and near impossible to predict failures of the most absurd kind. You can go back and look at some crazy behavior hundreds of people have worked to resolve regarding TTL contracts within Redis.
The ease of "appearance of value" today is the uncanny valley for software. The repo looks professionally organized, you can PAY for it, the preliminary benchmarks are looking good. Overlooked are the testing, validation, backup, failure recovery, practical behaviors, and most importantly: honesty.
These projects would get more love if it was declared up front that they were heavily AI generated projects and shouldn't be used in production since it has the air of practical utility.
It's probably a great drop-in replacement for Redis for a raspberry pi project that has low stakes. The smaller 1MB disk footprint and the performance difference could be impactful. Personally, I wouldn't be using this in production for at least a few years after hobbyists have their go at revealing its hidden near-guaranteed flaws.
At least I can broach TTL issues and gather reasonable insight on Redis vs Elasticache nuance based on the thousands who have encountered the issues.
Because it's AI slop that some grifter vibecoded yesterday with no unit tests that supports about 2% of Redis's feature set (notably missing transactions and any attempt at data integrity)
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?!?!
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.
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?
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.
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.
Good point! There's an issue RE license so this will be addressed tomorrow
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.
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
Adding some tests that prove equivalent functionality to Redis would make people much more likely to adopt this. Very cool project otherwise.
Are the commands fully compatible with Redis? We use a lot of commands like TTL PTTL EXPIRE PEXPIRE to create various rate limiters.
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.
yeah a repo with only about 18 or so commits and about 3 days of commit history is definitely not vibecoded
Typically you wait OSS projects to mature before you add a cloud offering but I guess not in the age of AI.
Good read here - https://www.luxdb.dev/architecture
Rivetting
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.
Why isn’t this getting any love? What’s the catch?
Those with a bit more experience understand faster is not always better. Databases thought to be battle-tested encounter incredibly complex and near impossible to predict failures of the most absurd kind. You can go back and look at some crazy behavior hundreds of people have worked to resolve regarding TTL contracts within Redis.
The ease of "appearance of value" today is the uncanny valley for software. The repo looks professionally organized, you can PAY for it, the preliminary benchmarks are looking good. Overlooked are the testing, validation, backup, failure recovery, practical behaviors, and most importantly: honesty.
These projects would get more love if it was declared up front that they were heavily AI generated projects and shouldn't be used in production since it has the air of practical utility.
It's probably a great drop-in replacement for Redis for a raspberry pi project that has low stakes. The smaller 1MB disk footprint and the performance difference could be impactful. Personally, I wouldn't be using this in production for at least a few years after hobbyists have their go at revealing its hidden near-guaranteed flaws.
At least I can broach TTL issues and gather reasonable insight on Redis vs Elasticache nuance based on the thousands who have encountered the issues.
Who cares about the 1mb image?
not excited trusting their data storage to a vibe coded database without a single unit test
Because it's AI slop that some grifter vibecoded yesterday with no unit tests that supports about 2% of Redis's feature set (notably missing transactions and any attempt at data integrity)
Looks like the repo is very young.
First thing to do is try it out in a hobby project see how it works out!
I bet it does not support Lua scripting.
It does not but will soon!
What is the difference between your project and the linux fundation fork?
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?!?!
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.
Avoid.
Very cool. Clean.