Discussion

Search code, repositories, users, issues, pull requests...

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

s900mhz: Looks like the repo is very young.First thing to do is try it out in a hobby project see how it works out!

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

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.

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

ArchieScrivener: Very cool. Clean.

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

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

gerdesj: 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.

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

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

nvme0n1p1: 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)

ares623: Rivetting

bmcahren: 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.The ease of "appearance of value" today is the uncanny valley for software. The repo looks professionally organized, the preliminary benchmarks are looking good. Overlooked are the testing, validation, practical behaviors, and most importantly: honesty.These projects would get more love if it was declared up front that they were 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.

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.

whattheheckheck: Who cares about the 1mb image?