1. No persistence for redis. 2. Redis would get OOM killed. 3. The default config coming with the image was used. 4. Yes, I gave it 2 cpus.
I wanted to compare how would my http server behave if I used postgres for caching and what the difference would be if I used redis instead.
This benchmark is only here to drive the point that sometimes you might not even need a dedicated kv store. Maybe using postgres for this is good enough for your use case.
The term production environment might mean many things. Perhaps you're processing hundreds of thousands of requests per second then you'll definitely need a different architecture with HA, scaling, dedicated shared caches etc. However, not many applications reach such a point and often end up using more than necessary to serve their consumers.
So I guess I'm just trying to say keep it simple.
Redis is one of the simplest services I’ve used… we could flip the script and say “for many db use cases postgresdb is overkill, just use Redis… you get caching too”. I’m not sure exactly what this commentary adds to a real world architecture discussion. The whole thing seems a little sophomoric, tbh.
> No persistence for redis
In this case, I would expect that a fairer comparison would be running Postgres on tmpfs. UNLOGGED only skips WAL writes, not all writes; if you do a clean shutdown, your data is still there. It's only lost on crash.