11–20 of 30 posts
As always, "it depends". There are situations where you can use Postgres as a queue perfectly fine. But there is no way Postgres can do as well or better than RabbitMQ in all situations. Same for text search, and so on.
Every expert / expert team should know what to use when.
Sure, but I need it embedded (so my app controls the installed version it needs).
1. It's nice if you can avoid using Postgres to store large files. 2. It's nice if you can avoid using Postgres for an event stream with massive volume (say billions of records per month that must be maintained and queried).
Postgres will work for either of these, but there are real advantages that come if you can keep your database lighter than these allow for.
I've found this bias to be useful with two main exceptions: 1. It's nice if you can avoid using Postgres to store large files. 2. It's nice if you can avoid using Postgres for an event stream with massive volume (say billions of records per month that must be maintained and queried). Postgres will work for either of these, but there are real advantages that come if you can keep your database lighter than these allow…
As always, "it depends". There are situations where you can use Postgres as a queue perfectly fine. But there is no way Postgres can do as well or better than RabbitMQ in all situations. Same for text search, and so on.
Most applications, in most environments are not ever going to see more than 10k simultaneous users. You can vertically scale an RDBMS like PostgreSQL a LOT.
Not to mention, there are also a lot of ways to approach similar techniques with PostgreSQL that you might reach for a different DB platform for. JSONB in Postgres is actually easier to reason with IMO than MongoDB as a platform. Depending on your needs, it's a much better fit with hybrid tables with additional details in JSONB.
All of these points are valid, when given a caveat of "if Postgres covers your actual needs". Like, I've personally worked on many systems that used Redis for absolutely no reason. As it was not actually measurably improving the latency of any part of the system. It was basically just another place to store data. Obviously, Postgres and Redis are not the same, and there are situations where keeping data in memory at…
Of course, I'm more inclined today to just use PostgreSQL unless and until something truly needs to break the mold.
I mostly agree with this... > Use Postgres for Fulltext Search instead of Elastic. Yea, that's not quite the same. Im going to make the argument that a well tuned search platform along side your data storage is probably one of the most useful things you can have. It's one of the first places where you will be "let down" by the Postgres solution. As a document store, a queue, Postgres will do the job up to a point. Wh…
Many/most applications don't have those needs. Then again, I'm also a fan of using JSONB for details in fewer tables over overly normalized structures. It varies.
> Use Postgres for caching instead of Redis with UNLOGGED tables This is not the same thing, is it? Redis is in-memory, while the Postgres tables will be on disk, even UNLOGGED.
I thought unlogged was used so crash recovery would truncate / dump the table on a crash with 100% Dataloss but this let you put stuff on a tempfs / ramdisk?
A lot of points made here is also is why I believe Phoenix framework is the BEST stack for building mvps in 2024. 1. you get concurrency and pubsub built in with no external dependancies. 2. postgres suppport out of the box. our entire deployment is just phoenix + postgres 3. creating a microservice is easy. create a genserver, add it to your application.ex -> DONE. no need to create a seperate repo. its already able…