3 ms·

Exactly what https://www.amazingcto.com/postgres-for-everything/ https://www.amazingcto.com/postgres-for-everything/ says; keep it simpel and use PostgreSQL.

antisthenes 9mo ago
Isn't Redis just a lot less relevant these days since enterprise NVME storage is so ridiculously fast? How much latency could you really be saving versus introducing complexity? But I am not a storage/backend engineer, so maybe I don't understand the target use of Redis.
- aynyc 9mo ago
  You'll be amazed on what the new breed of engineers are using Redis for. I personally saw an entire backend database using Redis with RDB+AOF on. If you redis-cli into the server, you can't understand anything because you need to know the schema to make sense of it all.
- SomeUserName432 9mo ago
  > But I am not a storage/backend engineer, so maybe I don't understand the target use of Redis. We use it to broadcast messages across horizontally scaled services. Works fine, probably a better tool out there for the job with better delivery guarantees, but the decision was taken many years ago, and no point in changing something that just works. It's also language agnostic, which really helps. We use ElasticCache (Valkey i suppose), so most of the articles points are moot for our use. Were we to implement it from scratch today, we might look for better delivery guarantees, or we might just use what we already know works.
- everforward 9mo ago
  Redis still has a niche. For something like a job queue, SQL is probably fine because adding a few ms of latency isn't a big deal. For something like rate-limiting where each layer of microservice/monolith component has their own rate-limit, that can really add up. It's not unheard of for a call to hit 10 downstreams, and a 10ms difference for each is 100ms in latency for the top of the waterfall. Redis also scales horizontally much, much easier because of the lack of relational schemas. Keys can be owned by a node without any consensus within the cluster beyond which node owns the key. Distributed SQL needs consensus around things like "does the record this foreign key references exist?", which also has to take into account other updates occurring simultaneously. It's why you see something like Redis caching DB queries pretty often. It's way, way easier to make your Redis cluster 100x as fast than it is to make your DB 100x as fast. I think it's also cheaper in terms of hardware, but I haven't done much beyond napkin math to validate that.
yandrypozo 9mo ago
I love the idea of PG for everything, but every time I suggest it I get the same answer "When you're a hammer, everything looks like a nail" which makes sense to me, but not sure how to give a good answer to that phrase :(
- solid_fuel 9mo ago
  I mean, that's just a truism - it's not really engineering advice. Maybe Postgres is just a hammer, but when you're building a house there's a lot of nails. If you've got to store 5 GB videos, maybe reach for object store instead of postgres. But for most uses postgres is a solid choice.

antisthenes 9mo ago

Isn't Redis just a lot less relevant these days since enterprise NVME storage is so ridiculously fast? How much latency could you really be saving versus introducing complexity? But I am not a storage/backend engineer, so maybe I don't understand the target use of Redis.

aynyc 9mo ago
You'll be amazed on what the new breed of engineers are using Redis for. I personally saw an entire backend database using Redis with RDB+AOF on. If you redis-cli into the server, you can't understand anything because you need to know the schema to make sense of it all.
SomeUserName432 9mo ago
> But I am not a storage/backend engineer, so maybe I don't understand the target use of Redis. We use it to broadcast messages across horizontally scaled services. Works fine, probably a better tool out there for the job with better delivery guarantees, but the decision was taken many years ago, and no point in changing something that just works. It's also language agnostic, which really helps. We use ElasticCache (Valkey i suppose), so most of the articles points are moot for our use. Were we to implement it from scratch today, we might look for better delivery guarantees, or we might just use what we already know works.
everforward 9mo ago
Redis still has a niche. For something like a job queue, SQL is probably fine because adding a few ms of latency isn't a big deal. For something like rate-limiting where each layer of microservice/monolith component has their own rate-limit, that can really add up. It's not unheard of for a call to hit 10 downstreams, and a 10ms difference for each is 100ms in latency for the top of the waterfall. Redis also scales horizontally much, much easier because of the lack of relational schemas. Keys can be owned by a node without any consensus within the cluster beyond which node owns the key. Distributed SQL needs consensus around things like "does the record this foreign key references exist?", which also has to take into account other updates occurring simultaneously. It's why you see something like Redis caching DB queries pretty often. It's way, way easier to make your Redis cluster 100x as fast than it is to make your DB 100x as fast. I think it's also cheaper in terms of hardware, but I haven't done much beyond napkin math to validate that.

yandrypozo 9mo ago

I love the idea of PG for everything, but every time I suggest it I get the same answer "When you're a hammer, everything looks like a nail" which makes sense to me, but not sure how to give a good answer to that phrase :(

solid_fuel 9mo ago
I mean, that's just a truism - it's not really engineering advice. Maybe Postgres is just a hammer, but when you're building a house there's a lot of nails. If you've got to store 5 GB videos, maybe reach for object store instead of postgres. But for most uses postgres is a solid choice.