The measurement will be dominated by network IO time. Does the driver wait for acknowledgement when writing? Does it wait for each read before transmitting the next query? These details matter.
Postgres reads might be so fast because the test script reads keys in the order they were written. Postgres benefits from cache locality, as the table file maintains that order.
also the value data structure is way to beneficial for postgres.
the value should be a string and change in size and if the value changes more table bloat is occured so that a fillfactor might be a good idea. also most cache at least support a ttl which might be even worse for postgres on the query side since it needs to evaluate the expiration date on the client side while redis supports that directly.
> also most cache at least support a ttl which might be even worse for postgres on the query side since it needs to evaluate the expiration date on the client side while redis supports that directly.
Afaik redis will check TTLs on access as well as in a background process, so postgres isn't really behind on this one.
Postgres reads might be so fast because the test script reads keys in the order they were written. Postgres benefits from cache locality, as the table file maintains that order.