netpaladinx

I like the thread per core model. EloqKV, DragonflyDB, ScyllaDB all follow this pattern.

We’ve been using EloqKV to replace one of our largest Redis node (we didn’t want to run Redis Cluster, just a single big node). One pain point we had with Redis was the RDB fork causing latency jitter during persistence. EloqKV handles this much better — the fork-related stalls are gone, and so far it’s been a smooth drop-in replacement for our workload.

object storage here do you mean the recent released S3 Vector?

Ursa published a blog post saying their leaderless, stateless, object storage–based Kafka replacement can reduce costs by up to 95%. Has anyone here tried Ursa in production? How much cost reduction have you actually seen compared to Kafka or MSK in real workloads?

All your points are valid. I don't think most people "dislike" C. People have options and most choose non-C. From my perspective, when the software or the system itself is already extremely complex, using C just adds more complexity on top. Many people including me choose not to add more.

I remembered other Robotaxis operated one year ago

Which database is behind Claude Code? Cursor built on top of object storage. They failed with Yugabytes and Postgres

Talking about transactions in Redis, one area came on top of my head is metadata in file systems. I've seen colleagues/collaborators run large-scale training on a distributed file system w/ a billion files, which puts a lot of pressure on the metadata part. They tried a few options and Redis was one of them. It's fast and Lua is good enough to support metadata ops. But the thing is that it cannot scale (or Lua is gone) and may lose data from time to time, which is annoying. It looks like this durable-transactional combination may fit in. Will wait to see how this is unfolded.

Probably not. Data flow is declartive in data transformations and "differential" refers to be incremental. But what the link tries to model seems to relate to asynchronous transformations. Not on the same level.