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.
I'm assuming it's a meme project. In case it isn't, what's the point? Just trying to understand.
Isn't rust's one of the main selling point is the barrow checker right?
Also how's the memory is handled? I know it'll drop every thing once it's out of scope but it seems you can make copies as much as you want. Looking at the loop example, I feel like this introduces memory leaks & undefined behavior.
but the other things such as writing, just can't do it without LLMs's help. Looking up things, I defaulted to LLMs.
So in 2026, I just want to stop relying on LLMs.
Lol but I do like building LLMs (training from scratch, pre-training, fine-tuning, etc.). as a matter of fact, I'm pre-training a 1b model for last 2 days.
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.