Do you need separate systems when you already have Postgres?

Posted by b-man 4 hours ago

Do you need separate systems when you already have Postgres?(postgresisenough.dev)

99 points | 73 commentspage 2

h1fra 3 hours ago|

I have yet to have used UNLOGGED table in production, but I really want to try at some point. Anybody actually replaced a large Redis instance with this?

ubercore 2 hours ago||

I love postgres, but the complexity of using it for everything starts to get pretty high, compared to more tailor-suited tools. We should probably use it for _more_, in general, but the cost of "everything in postgres" is generally higher than I see acknowledged in articles like these.

pooloo 2 hours ago|

These specialized tools are likely the cause for the increased complexity within Postgres. I would imagine that if we had more individuals focused solely on Postgres, there would be more discussions, articles, and solutions for a lot of the problems "solved" by adding more tools to the problem.

devin 3 hours ago||

> This isn't about dogma. Sometimes you genuinely need specialized infrastructure. But the bar should be high: only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative.

I've seen a few "Use Postgres for Everything!" posts lately. It seems to be fashionable. It reminds me of the Choose Boring Technology[1] thing from 2018 or so, but more specific to a database.

I think the ideas of "don't add unnecessary dependencies" and "ruthlessly evaluate tradeoffs" and "prefer simplicity" and so on are general and have very little to with postgres, so when I see things like "All you need is X" I roll my eyes a little, because these decisions are highly dependent on your use case, and taken as blanket advice it is generally _bad_ advice even if the underlying rationale is sound.

[1]: https://mcfunley.com/choose-boring-technology

ETA: I am going through their list and so much of this means that you are going to manage your own PG cluster and not take advantage of Aurora or RDS, which means you're already committing to a major tradeoff if you want to use a lot of these custom extensions.

simonbarker87 3 hours ago||

Couple that with a framework with decent server side rendered template support and htmx for network based interactions and you’ve got 90% of the <acronym_of_the_moment> stack with 10% of the complexity.

polycancel 3 hours ago||

> Document store -> FerretDB

Love FerretDB, but it doesn't really replace MongoDB's GridFS which is main reason why most people who are really using Mongo now day. Anyone knows a good replacement for GridFS?

matharmin 2 hours ago|

Why would anyone use GridFS for any serious use case? It costs 10-20x as much as storing the files on S3. If unless you already have all your data in MongoDB and don't want an additional dependency for a small number of files it makes sense, but it definitely is not a case for using MongoDB by itself.

DonsDiscountGas 2 hours ago||

I suspect a lot of this is resume driven design.

valentynkit 2 hours ago||

The thing that usually pushes you off Postgres is rarely raw throughput, it's two workloads that want opposite tuning on the same box.

Kinrany 2 hours ago|

The solution might be to move to separate Postgres boxes everything that needs performance tuning at all.

I'm not in the "use Postgres for everything" camp, but only because I think it's too complex to be used like that. It should be replaced with a bunch of simple primitives in this role. No SQL and query planning magic please.

mamcx 2 hours ago||

YES!

The problem of all the datastores is that are applications (like Wordpress) so you are too late to fix anything deep.

We need "frameworks" (so each sub-component can be used as-is or even swapped) and even wondering what a "system level" data engine could be.

goosethe 3 hours ago||

agree:

https://github.com/seanwevans/pg_os

https://github.com/seanwevans/pg_git

https://github.com/seanwevans/pg_gpt2

etc...

Sharlin 3 hours ago|

https://thombrown.blogspot.com/2026/07/load-plcbmbasic81-com...

samrus 3 hours ago||

Reminds me Kai Lentit's ffmpeg video

https://youtu.be/9kaIXkImCAM

mrkeen 2 hours ago|

The reason for separate systems is that some of them go down. And by "go down", that includes you wanting to deploy a new version. Or restore from backup as the article suggested.

munk-a 2 hours ago|

I think it's rather rare to use different services for redundancy and in most cases if you want that redundancy (e.g. to support red-black or blue-green deployments or just to support better availability via failover) I'd usually suggest using the same technology for that purpose.

I don't believe it's ever easier to manage updating two technologies than one.

mrkeen 49 minutes ago||

I mean if I was only going to use 'one thing', it would be tech that doesn't have downtime when you replace its parts. Something like Kafka or Cassandra. Then since postgres is useful, I would likely end up adding it into the system.

More comments...