This isn't a great test setup. It's testing RTT rather than the peak throughput of Redis.

I'd suggest using Redis pipelining -- or better: using the excellent rueidis redis client which performs auto-pipelining. Wouldn't be surprising to see a 10x performance boost.

https://github.com/redis/rueidis

▲

aaronblohowiak 11 hours ago | parent | next [-]

Even so 35ms+ latency for Redis reads is very very high I’d want to understand what is happening there

▲

dizzyVik 11 hours ago | parent | prev | next [-]

Author here. Redis is definitely faster. I was specifically not going for absolute peak performance for either redis or postgres - that would require going down to the wire protocols. The idea was emphasize that there' a "good enough" level of performance. Once you need that sort of speed - sure, there are ways to achieve it.

	▲	motorest 10 hours ago \| parent [-]
		> The idea was emphasize that there' a "good enough" level of performance. Once you need that sort of speed - sure, there are ways to achieve it. To this I would add that more often than not the extra cost and complexity of a memory cache does not justify shaving off a few hypothetical milliseconds from a fetch. On top of that, some nosql offerings from popular cloud providers already have CRUD operations faster than 20ms.

▲

oa335 12 hours ago | parent | prev [-]

Postgres also supports query pipelining - at it seems like the popular go Postgres client library pgx supports it: https://github.com/jackc/pgx/issues/1113#event-6964024724