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...

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

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.

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).

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.