3 ms·

1. Redis can handle a lot more connections, more quickly, than a database can. 2. It's still faster than a database, especially a database that's busy. #2 is a

by manv1 4y ago

1. Redis can handle a lot more connections, more quickly, than a database can. 2. It's still faster than a database, especially a database that's busy. #2 is an interesting point. When you benchmark, the normal process is to just set up a database then run a shitload of queries against it. I don't think a lot of people put actual production load on the database then run the same set of queries against it...usually because you don't have a production load in the prototyping phase. However, load does make a difference. It made more of a difference in the HDD era, but it still makes a difference today. I mean, redis is a cache, and you do need to ensure that stuff works if your purge redis (ie: be sure the rebuild process works), etc, etc. But just because it's old doesn't mean it's bad. OS/390 and AS/400 boxes are still out there doing their jobs.

nijave 4y ago
A pretty small Redis server can handle 10k clients and saturate a 1Gbps NIC. You'd need a pretty heavy duty Postgres database and definitely need a connection pooler to come anywhere close.
- anarazel 4y ago
  I agree that redis can handle some query volumes and client counts that postgres can't. But FWIW I can easily saturate a 10GBit ethernet link with primary key-lookup read-only queries, without the results being ridiculously wide or anything. Because it didn't need any setup, I just used: SELECT * FROM pg_class WHERE oid = 'pg_class'::regclass; I don't immediately have access to a faster network, connecting via tcp to localhost, and using some moderate pipelining (common in the redis world afaik), I get up to 19GB/s on my workstation.
  - e12e 4y ago
    > SELECT * FROM pg_class WHERE oid = 'pg_class'::regclass; This selects every column (*) from every table (ObjectID is of type regclass)?
    - anarazel 4y ago
      Sorry, I should have used something more standard - but it was what I had ready... It just selects every column from a single table, pg_class. Which is where postgres stores information about relations that exist in the current database.
hobobaggins 4y ago
and those have reliable backup/restore infrastructure. Using redis as a cache is fine, just don't use it as your primary DB.

by manv1 4y ago

nijave 4y ago

A pretty small Redis server can handle 10k clients and saturate a 1Gbps NIC. You'd need a pretty heavy duty Postgres database and definitely need a connection pooler to come anywhere close.

anarazel 4y ago
I agree that redis can handle some query volumes and client counts that postgres can't. But FWIW I can easily saturate a 10GBit ethernet link with primary key-lookup read-only queries, without the results being ridiculously wide or anything. Because it didn't need any setup, I just used: SELECT * FROM pg_class WHERE oid = 'pg_class'::regclass; I don't immediately have access to a faster network, connecting via tcp to localhost, and using some moderate pipelining (common in the redis world afaik), I get up to 19GB/s on my workstation.
- e12e 4y ago
  > SELECT * FROM pg_class WHERE oid = 'pg_class'::regclass; This selects every column (*) from every table (ObjectID is of type regclass)?
  - anarazel 4y ago
    Sorry, I should have used something more standard - but it was what I had ready... It just selects every column from a single table, pg_class. Which is where postgres stores information about relations that exist in the current database.

hobobaggins 4y ago

and those have reliable backup/restore infrastructure. Using redis as a cache is fine, just don't use it as your primary DB.