3 ms·

I am of the firm opinion that Postgres + Redis are basically the only DBs you ever need.

nimchimpsky 4y ago
[dead]
jaggederest 4y ago
Agreed, and I'm over in the corner sharpening an axe, looking at Redis with highly malicious intent, too. I think many of the things people use Redis for could be accomplished with a small postgres server and a decent schema e.g. `create table redislike (id bigserial primary key, contents jsonb);`
- code_biologist 4y ago
  You can stuff some pretty insane stuff in Redis keys beside ints, giant multi MB strings with globby query patterns. Your general point is dead on.
klysm 4y ago
What do you use redis for?
- white_dragon88 4y ago
  Caching frequently fetched complex objects to mitigate load on the Postgres DB.
  - throwawaaarrgh 4y ago
    You could also cache those in the VFS or VMS. A cache is a cache, but one that is built into everything and doesn't require networking can be quite a bit less maintenance, risk, etc
  - klysm 4y ago
    So are you caching the query results keyed by query or something higher up?
kevincox 4y ago
And 95% of the time you don't even need Redis.
bigfatfrock 4y ago
amen. I've run both in furious production conditions for over a decade with failures only caused by myself or other inept coders!
electroly 4y ago
I definitely think they're great picks but I don't think the statement is making a particularly strong or interesting claim. I think it's equally true with basically any RDBMS in place of PostgreSQL. MySQL + Redis? Absolutely you'd be fine, tons of high-performance sites do this, probably more than use PostgreSQL. SQL Server + Redis? Still fine; you're Stack Overflow. Oracle + Redis? Weird choice but you'll still be fine. Also most companies probably don't need the Redis. So... what are we saying here, exactly? Are we saying that you don't need a no-SQL database, and that just SQL is enough with some Redis frosting on the cake to taste? I agree with that, but now we're not really talking about PostgreSQL any more, we're just debating SQL vs. no-SQL.
- fastball 4y ago
  Well what I'm saying here is that SQL is great and sometimes it's genuinely helpful to have a much faster key-value store in a variety of scenarios. That's basically all you need. From there, it's PostgreSQL and Redis specifically because Postgres is the best SQL database and Redis is the best high-performance KV store.
wiredfool 4y ago
I think a columnar database can be super useful. I use Postgres a lot, but with a largish database, I managed to get the whole database footprint in Clickhouse smaller than the primary key index in Postgresql. (~80GB vs 160GB, and 1.2 TB for the whole unencrypted PG database) Now, it wasn't a great index key and the original schema wasn't good, but optimizing PG got me about a factor of 3 or 4, and Clickhouse compression got me another order of magnitude.

[dead]

Agreed, and I'm over in the corner sharpening an axe, looking at Redis with highly malicious intent, too. I think many of the things people use Redis for could be accomplished with a small postgres server and a decent schema e.g. `create table redislike (id bigserial primary key, contents jsonb);`

code_biologist 4y ago
You can stuff some pretty insane stuff in Redis keys beside ints, giant multi MB strings with globby query patterns. Your general point is dead on.

klysm 4y ago

What do you use redis for?

white_dragon88 4y ago
Caching frequently fetched complex objects to mitigate load on the Postgres DB.
- throwawaaarrgh 4y ago
  You could also cache those in the VFS or VMS. A cache is a cache, but one that is built into everything and doesn't require networking can be quite a bit less maintenance, risk, etc
- klysm 4y ago
  So are you caching the query results keyed by query or something higher up?

kevincox 4y ago

And 95% of the time you don't even need Redis.

bigfatfrock 4y ago

amen. I've run both in furious production conditions for over a decade with failures only caused by myself or other inept coders!

electroly 4y ago

I definitely think they're great picks but I don't think the statement is making a particularly strong or interesting claim. I think it's equally true with basically any RDBMS in place of PostgreSQL. MySQL + Redis? Absolutely you'd be fine, tons of high-performance sites do this, probably more than use PostgreSQL. SQL Server + Redis? Still fine; you're Stack Overflow. Oracle + Redis? Weird choice but you'll still be fine. Also most companies probably don't need the Redis. So... what are we saying here, exactly? Are we saying that you don't need a no-SQL database, and that just SQL is enough with some Redis frosting on the cake to taste? I agree with that, but now we're not really talking about PostgreSQL any more, we're just debating SQL vs. no-SQL.

fastball 4y ago
Well what I'm saying here is that SQL is great and sometimes it's genuinely helpful to have a much faster key-value store in a variety of scenarios. That's basically all you need. From there, it's PostgreSQL and Redis specifically because Postgres is the best SQL database and Redis is the best high-performance KV store.

wiredfool 4y ago

I think a columnar database can be super useful. I use Postgres a lot, but with a largish database, I managed to get the whole database footprint in Clickhouse smaller than the primary key index in Postgresql. (~80GB vs 160GB, and 1.2 TB for the whole unencrypted PG database) Now, it wasn't a great index key and the original schema wasn't good, but optimizing PG got me about a factor of 3 or 4, and Clickhouse compression got me another order of magnitude.