[chipdart]

> You can connect to Redis over a local socket, no network overhead.

I think at some point we need to stop and think about the problem, and if an idea makes sense.

Even Redis has a disclaimer in their docs on how SQLite is faster due to the way it does not require network calls. The docs also explain how it's an apples-to-oranges comparison.

https://redis.io/docs/latest/operate/oss_and_stack/managemen...

[vundercind]

(Nit: redis incurs at least IPC overhead, not necessarily network, which would be a ton worse—but if you’re not using Redis for IPC then I don’t know why you’re using it, so IPC overhead goes with the territory)

Redis is best for “smart” shared-memory-type resources. Queues that manage themselves, cache or locks or sessions with built-in expiration, that kind of thing. Shared smart logic for heterogenous same-host clients via extensions.

Remote Redis has never made much sense to me. Clustered-mode, sure, potentially, but with remote clients as the primary method of connection? No. It’s a really good (excellent, even) product but its sweet-spot is pretty narrow (even if the need is common) and basically nonexistent in now-typical container-heavy no-two-resources-are-required-to-be-on-the-same-actual-hardware situations.