The primary reason to avoid doing so is avoiding thrashing your buffers, along with increased size of backups, WAL bloat, etc.
Can you? Yes. Should you? Not at anything beyond a toy scale, unless you want to pay for more RAM to ensure that your normal OLTP queries don’t take a performance hit.
I had a system that has ~600gb of blob data in bytea that could have easily been an S3 bucket + db reference. It made backups way more of a pain than necessary.
It was intentional in the design, because I wanted total consistency with a single backup for the system. It worked great for years. But as we got more and more clients, it really should have been migrated to the above design to make sure our backups could be taken / restored faster.
So the original advice actually still stands. You can still start off with Posgres, store it in BYTEA columns, and then work on a plan to use an object storage as you grow. S3 may not be possible and you will be evaluating other options like Minio
You know what, I agree...original advice stands. I should have known that the data I was storing would eventually grow larger than reasonable, so in this case it would have been smarter to design it properly from the start. Hindsight.
But there are still plenty of cases I would say BYTEA is perfectly reasonable choice.
I guess I just don’t see the point for most applications. If you’re using a DBaaS, as most are, object storage from the same provider is almost certainly going to be cheaper, and it’s a trivial amount of code to handle the separate push / pull code.
Can you? Yes. Should you? Not at anything beyond a toy scale, unless you want to pay for more RAM to ensure that your normal OLTP queries don’t take a performance hit.