mattyhogan's comments

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

[mattyhogan]

It does now

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

[mattyhogan]

It does not but will soon!

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

[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 → mattyhogan]

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.

[mattyhogan → redfloatplane]

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

[0xMohan → mattyhogan]

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.

[mattyhogan → 0xMohan]

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

[deminature → mattyhogan]

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

[karunamurti → mattyhogan]

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

[mattyhogan → karunamurti]

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

On: Still haven't deployed an agent? This post will change that

[mattyhogan]

With all the frameworks and apis out there, it can be really easy to get an agent running locally. However, the difficult part of building an agent is often bringing it online.

It takes longer to spin up a server, add websocket support, create webhooks, manage sessions, cron support, etc than it does to work on the actual agent logic and flow. We think we have a better way.

To prove this, we've made the simplest workflow ever to get an AI agent online. Press a button and watch it come to life. What you'll get is a fully hosted agent, that you can immediately use and interact with. Then you can clone it into your dev workflow ( works great in cursor or windsurf ) and start iterating quickly.

It's so fast to get started that it's probably better to just do it for yourself (it's free!).