Show HN: Lux – Drop-in Redis replacement in Rust. 5.6x faster, ~1MB Docker image

by mattyhogan • 4 months ago

59 30 4 months ago

mattyhogan6• 4 months ago

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.

karunamurti• 4 months ago

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

mattyhogan6• 4 months ago

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

redfloatplane• 4 months ago

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.

mattyhogan6• 4 months ago

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

deminature• 4 months ago

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

0xMohan• 4 months ago

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.

mattyhogan6• 4 months ago

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

mholubowski• 4 months ago

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

s900mhz• 4 months ago

Looks like the repo is very young.

First thing to do is try it out in a hobby project see how it works out!

kay_o• 4 months ago

not excited trusting their data storage to a vibe coded database without a single unit test

nvme0n1p1• 4 months ago

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)

bmcahren• 4 months ago

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.

whattheheckheck• 4 months ago

Who cares about the 1mb image?

ArchieScrivener• 4 months ago

Very cool. Clean.

japgolly• 4 months ago

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

ares623• 4 months ago

Rivetting

kaoD• 4 months ago

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?

tmaly• 4 months ago

sounds like it was vibe coded?

Bnjoroge• 4 months ago

yeah a repo with only about 18 or so commits and about 3 days of commit history is definitely not vibecoded

gerdesj• 4 months ago

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.

delduca2• 4 months ago

I bet it does not support Lua scripting.

mattyhogan6• 4 months ago

It does not but will soon!

mattyhogan6• 4 months ago

It does now

delduca2• 4 months ago

What is the difference between your project and the linux fundation fork?

_pdp_• 4 months ago

Typically you wait OSS projects to mature before you add a cloud offering but I guess not in the age of AI.

rvz• 4 months ago

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.

FergusArgyll• 4 months ago

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?!?!

bysiber• 4 months ago

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.

nathanjordan• 4 months ago

Dunning-Kruger on full display

Show HN: Lux – Drop-in Redis replacement in Rust. 5.6x faster, ~1MB Docker image

Related Stories