[JsonDemWitOster]

I'll do you one better: do you really need Postgres and all these extensions when you already have a filesystem?

> only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative

I love Postgres as a DB but, really, this is ridiculous. No doubt these extensions can do the job well-enough but you might as well invest in learning the right tool for the problem from the start, when the stakes are still pretty low. Why wait until, ahem, Postgres is pushed to the limit before you spin up a Redis cluster?

You don't get free opcost by using Postgres for everything. Arguably if you end up with a monolith of a database, you are paying a higher opcost (imagine if too much caching can affect all CRUD ops in your platform). Or you can manage a cluster of PG instances but that's no less complex---each plugin still comes with its own opcost!

No Silver Bullet, No Free Lunch, and all that. If your problem domain really warrants something outside of relational storage, you're gonna pay that complexity cost one way or another. You can't escape it by shoehorning everything in Postgres, fantastic as a DB as it is.

[pooloo]

I don't understand why the answer is to always bloat the system with more specialized software and technical debt, instead of optimizing the existing system. If Postgres can truly handle all of these situations, then mastery of that one tool should be focused on.

I guess its more the rapid start-up mindset to get it up and running fast to sell the company, and leave the problem for someone else which is why a lot of our world is falling apart...

[whstl]

Yeah. I feel it's more of a "ticking all the boxes" situation than anything.

For example: I worked with Rails from 2009-2024 and I haven't come across a single Rails project in the wild that didn't have the queue du jour installed: sideqik+redis, delayed-job before, etc. And then since it's there, people just end up using.

[JsonDemWitOster]

As I don't want to repeat myself, with emphasis added:

> No Silver Bullet, No Free Lunch, and all that. If your problem domain really warrants something outside of relational storage, you're gonna pay that complexity cost one way or another. You can't escape it by shoehorning everything in Postgres, fantastic as a DB as it is.

So as not to bloat the system, you will end up bloating your Postgres installation instead.

Also, Unix principle/KISS: do one thing and only one thing well. Of course this comes back down to your definition of "one thing". "_Any_ Data Storage" seems to be your one thing but not for me. "Relational Data Storage" is a well-scoped one thing for me.

I'm not saying don't take advantage of the plugin system. But we must exercise good sense so as not to abuse it when we avail of its advantages. TFA's suggestion of "only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative" does not sound like good sense. It sounds like a personal and an organizational burnout waiting to happen. Wait until PG is at its limit does not sound like technical debt to you?

> If Postgres can truly handle all of these situations, then mastery of that one tool should be focused on.

Thus you have conceived the conundrum of The Database of Theseus: after how many plugins is your Postgres cluster no longer a mere Postgres cluster to the point where it is unreasonable for a seasoned/certified Postgres DBA to have a good grasp of the system in a reasonable time span?

This is almost textbook https://en.wikipedia.org/wiki/Inner-platform_effect in that this is the second paragraph of the "Examples" section. I acknowledge that Postgres' plugin system mitigates this somewhat but I just can't be convinced that all those plugins will play well with each other for all eternity and especially under stress (unless you make a PG instance for each sub-system, in which case, refer to my original comment).

For the record

- I've used PG for caching with UNLOGGED. Still had Redis for a message queue and other caching. - I've used PostGIS because it made sense to be able to make geo query when latlon is already a (small) part of your schema. - I've used JSONB but only because the alternative is Mongo. I still had an Elasticsearch cluster indexing all that data for search.

[PaulHoule]

Filesystems aren't efficient for small bits of data.

Like right now I am thinking about a system that has a password reset process and you need to keep track of a user id and a reset token, one or two timestamps, maybe a state variable and a flag or two. That's well under 100 bytes and the cluster size for a typical fs is 4kb or more plus there is the cost of the directory entry. If the OS is Windows it has to ask the Security Manager when ever you open it or delete it which is even more heavyweight.

It's common now for applications that handle lots of little "files" to store them as blobs in SQLlite! See https://sqlite.org/fasterthanfs.html

[JsonDemWitOster]

I can no longer edit my comment above so I'm just leaving this here, picking you arbitrarily out of the handful that addressed my filesystem suggestion:

I am being sarcastic to show what a ridiculous idea it is to shoehorn everything into Postgres. If you find eschewing a relational DB for the filesystem incredulous, you should maybe reconsider if eschewing specialized software in favor of Postgres is advisable.

[Onavo]

Do filesystems offer ACID guarantees though? Depending on the use case, something like sqlite might work better (or write to a CAS system like S3).

[buremba]

Filesystem is best when there is a single writer and many readers.

If you have bunch of files and don't have any structure, yes filesystem is great but the moment when you need consistency & performance (which you need sooner rather than later) use databases.

Investing early doesn't hurt when you build a product that you know will have many writers.

[scuff3d]

In my experience the real answer is almost always "just don't do that other stuff". Most of the complexity Postgress is claiming to fix here doesn't need to exist in the first place.