59 points by mattyhogan 2 days ago | 30 comments on HN
| Neutral High agreement (3 models)
Landing Page · v3.7· 2026-03-15 23:10:12 0
Summary Digital Access & Expression Acknowledges
This GitHub repository landing page exhibits structural support for human rights primarily through GitHub's platform infrastructure: open access enables freedom of expression and association in technical collaboration, HTTPS and security headers protect user privacy and integrity, and the open-source model facilitates education and knowledge sharing. The page itself contains minimal editorial content; the human rights alignment derives from GitHub's underlying architecture rather than explicit commitment statements on this specific URL.
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.
> 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?
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.
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)
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.
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.
GitHub's open-source repository infrastructure allows developers of all backgrounds to collaborate and contribute without discrimination. This structural feature supports equal dignity, though no explicit commitments visible on this page.
No cookie consent banner (+0.0 modifier); HTTPS encryption (+0.05 modifier); no third-party tracking (+0.05 modifier). User data protected from monitoring and interference during repository interactions.
Repository openly accessible across geographic boundaries; users can freely contribute, view, and distribute code. Open-source model supports freedom of movement in technical collaboration.
GitHub infrastructure supports freedom of expression: repository permits public discussion via issues, pull requests, and comments without pre-publication censorship. No cookie consent barrier (+0.0 modifier); no third-party tracking (+0.05 modifier) reduces surveillance chilling effect.
Repository structure supports freedom of association: users can collaborate, fork, and contribute without gatekeeping. No consent barriers (+0.0 modifier) for joining discussion.
Repository structure supports education rights: code is publicly available for learning, forking, and study. Cached DCP modifier 0 for accessibility indicates basic support but no comprehensive accessibility features visible. Open-source model enables technical education.
Repository participates in open-source culture that enables sharing in scientific/technical advancement. Basic accessibility present (+0.0 modifier per DCP). Limited evidence of cultural or artistic protection on this page.