> In a benchmark I made for the company I work for, Redis was only 30 - 40% faster than Postgres for our use cases because of the network trips. Obviously I'm

> In a benchmark I made for the company I work for, Redis was only 30 - 40% faster than Postgres for our use cases because of the network trips. Obviously I'm not familiarized with your use case, but there are a couple of things to keep in mind when performing these kind of analysis; The first one is connection cost & limit - Postgres client connection cost is quite high when compared to Redis (thats why tools like PGPool exist). Also, the upper bound connection limit in Postgres is quite low, compared to what you can achieve with Redis. Then there's the caching issue - it seems, from your description - you were actually benchmarking Postgres & filesystem cache. This happens if your dataset is small enough and your query is simple enough, but also indicates the database is idle - no other queries are running that will compete for cache resources or trigger disk I/O or buffer invalidation. If this is not your production scenario, the numbers you measured are meaningless. Following the cache issue, by the description (and how well it fitted in cache), it seems you're not analyzing throughput. Reading 10 items is different from reading 10^6 items, and you will quickly find out that the throughput of your database server is several times lower than what you can achieve with Redis, specially considering you can easily store your data compressed. It may or may not be relevant to your particular case, but its always good to also check this. Finally, there is the predictability aspect of the design. Having data available with predictable performance cost on a system that will happily handle tens of thousands of "simultaneous" operations, with a very low connection cost, instead of hammering your complex, multi purpose database is often a godsend, even if the performance difference was 0.