Why Postgres wouldn’t run on the same server as the app? It’s actually pretty common.
Why Postgres wouldn’t run on the same server as the app? It’s actually pretty common.
If you only have one long lived process or good global variable control, then it is much less appealing in the single-server scenario. Similarly, if you require access from multiple hosts, it becomes a less obvious choice (especially if you already have a database in the loop). And redis is also overkill is you’re using it only as a cache.
As in performance improvement - cache should never be considered a datastore, e.g. you can pull the plug and nothing else happens (aside losing performance). It'd be a lot more beneficial all the processes to have a local cache, themselves. The latter is at least 4 orders of magnitude faster than redis. Now you may like some partitioning, too.
Also, never realized redis has native support for a Bloom Filter.
Acting as shared memory for an inherently single-CPU language like JS is one I can think of. However, I don't use Redis, so you'd be better placed to drive the discussion forward with examples.
IPC, I suppose?
My Sidekiq background job system runs entirely on top of Redis. Structures like Sorted Sets become the basis for indexes. Lists provide extremely fast queue behavior and Hashes map easily to persistent objects. Databases, traditionally, have not performed well when used as queues.
Those are the big 3 structures necessary to implement anything: trees, lists and maps.
I do see the point of Redis if you have multiple hosts, but I was unsure why someone would use it on just one host.
That's perfectly fine. You can compare Redis to other specialized tools just like you can compare it with Postgres and SQLite.