Just Use Postgres for Everything

A lot of points made here is also is why I believe Phoenix framework is the BEST stack for building mvps in 2024.<p>1. you get concurrency and pubsub built in with no external dependancies.<p>2. postgres suppport out of the box. our entire deployment is just phoenix + postgres<p>3. creating a microservice is easy. create a genserver, add it to your application.ex -&gt; DONE. no need to create a seperate repo. its already able to send and receieve messages from other parts of your monolith using the built in pubsub system<p>4. Oban, the background worker library uses postgres.<p>end result is that as a small team, we are able to knock out a lot of features and scale it without any of the complexity most startups have. Its been 4 years and only now we are starting to consider bringing in an external message queue.

As always, &quot;it depends&quot;. 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 <i>all</i> situations. Same for text search, and so on.

I mostly agree with this...<p>&gt; Use Postgres for Fulltext Search instead of Elastic.<p>Yea, that&#x27;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&#x27;s one of the first places where you will be &quot;let down&quot; by the Postgres solution.<p>As a document store, a queue, Postgres will do the job up to a point. When and where it breaks down in one of these ancillary roles you&#x27;re likely to have the resource to support more systems, or a more &quot;focused&quot; tool.

I&#x27;ve found this bias to be useful with two main exceptions:<p>1. It&#x27;s nice if you can avoid using Postgres to store large files. 2. It&#x27;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).<p>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>Just use Postgres for everything</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33934139">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=33934139</a> - Dec 2022 (431 comments)

&gt; Use Postgres for caching instead of Redis with UNLOGGED tables<p>This is not the same thing, is it? Redis is in-memory, while the Postgres tables will be on disk, even UNLOGGED.

My leading use for redis on a system where I am already using Postgres is to use Celery. I suspect this is just one of many cases where people add an additional datastore because their frameworks and&#x2F;or libraries make it easier to to that than to use Postgres for that type of data.

Can you use a ton of extensions with a managed Postgres, or should you just host it yourself?

All of these points are valid, when given a caveat of &quot;if Postgres covers your actual needs&quot;.<p>Like, I&#x27;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.<p>Obviously, Postgres and Redis are not the same, and there are situations where keeping data in memory at all times is important for latency. Hence the caveat. But most companies are not in any such situation.<p>Same story with the rest of these technologies - people often reach for them without really considering whether they are any sort of improvement over just storing the data in a relational database. This is commonly done by engineers who underestimate the capabilities of a relational database.

Sure, but I need it embedded (so my app controls the installed version it needs).

“AmazingCTO” and “just using xxx for everything” surely fit each other .