[chipdart]

> The "Fast" part is a little funny. If you don't care about joins, then row inserts and retrievals are pretty damn fast too =)

What makes SQLite exceptionally fast in a server environment is that you do not require a network call to do the query or even retrieve the data. Your remarks about joins and transactions are meaningless once you understand you're just reading stuff from your very own local HD, which is already orders of magnitude faster.

[vundercind]

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

Modern cloud architecture hates local sockets and wants to push everything to the network, but if you care about performance and are using Redis, that’s how you’d favor deploying & connecting to it.

[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.