If you grow and you hit hardware limits then congratulations you are the next facebook/google/etc. Also there's nothing stopping you from switching your current database to something else.

Absolutely majority of the companies will do just fine, because the hardware improves faster than their demands. Starting out with a distributed system "because one day we might need it" is just silly, because chances are you'll never hit it, and you'll have to pay for the overhead of having a distributed system (which is non trivial).

Actually my company started using PG and had presentation and someone asked if we considered a distributed database so we can scale. The presenter nicely said it was evaluated and this solution worked best, but that was too nice.

1. It's only about 100GB of data

2. The hardware is barely utilized, we didn't tune it (except some standard memory settings), because there's no need yet.

3. Our data is relational (in fact most data from most companies is relational)

Is it? Because there are a ton of companies out there running postgres, mysql and scaling workloads just fine.

I upvoted you because you’re technically right for many cases, but if you’d ever dealt with a database you couldn’t scale further (we were using multiple of the largest instances EC2 had at the time) and new data was flowing in faster than you could delete it and downtime wasn’t an option, you too would hate any predecessors who said “you can always scale higher” before things got so bad it was almost impossible to recover.

Yeah. There are definitely cases where the scaling options make sense along different axis for sure. My point is mostly that relational DBs tend to strike a good default ground if you aren't sure what axis you'll care about.