If you are going to quote Jonathan Haidt, I suggest you take a look at his latest book, the Anxious Generation published in 2024. My reading is that reducing face time is definitely NOT a positive factor for happiness.
Separating things orthogonally into different functions/silos sounds like how stable and large companies are run. Sounds like a recipe for disaster for a startup.
By most standards, this was a resounding success. I won't have to work again ever if I don't want to. This being my first company, I was obsessed with it. Towards the end, I burnt myself out, I had neglected my wife and kids for years, and I was just so miserable. I used to love programming, but I could not concentrate anymore. I started developing resentment against the entitlement of the software engineers I would hire. My heart was broken every time I would read articles/comments on HN about how working for a start up is a scam that only benefits the founders.
It was time to get out. I was lucky that I sold in 2021, when the multiples were higher than ever. But I have lost my marriage along the way, and I have definitely lost a few years of life expectancy.
I really wonder if it was really all worth it. I know at the end of the day though I had to go through that. I had to see it with my own eyes.
In the end, things worked out for me. I can't even fathom how I would feel if the whole thing had failed. I really came to the conclusion that most of the time, starting a company is for suckers.
It depends on a lot of factors, my unscientific rule of thumb is that if the data doesn't fit in the RAM of the server, then that's when you may start worrying about how the data will be fetched from the disk when you query it (if performance matters).
The problem case is when the data needed to serve an average query is "scattered across the disk". This means that you will need to potentially fetch way more information from the disk (because data is returned by blocks/pages, not by bytes) than necessary to fulfill the query.
A worst case example: say to compute a query, you need to get 5000 rows (with a size of 100 bytes per row, 500KB in net total), if they are "perfectly scattered" (i.e. each row on a different page), you will really need to bring in 5000 pages of 8KB per page (default page size in Postgres) for a total of 40MB. By fetching 80 times more data than needed, you've essentially reduced your throughput by 80x.
Note that the example above assumes that an index (e.g. btree) can be leveraged. The index would point directly to the numerous pages, which is likely still much better compared to doing a full scan. But that index doesn't solve all your problems, only part 1.
It may not be a big deal as bringing 40MB from a disk would go fast, but this will limit 1) the number of concurrent user you'll be able to serve, 2) if you need 100,000 rows instead of 5000, then your query will take longer to process and it may be negatively noticeable by your user.
If you can co-locate the data on the disk (i.e. put them on same or contiguous pages) deterministically, then you would feel much better about your throughput. Cluster Index (or Indexed Views as it's called in SQL Server) is the typical mechanism to sort the data on the disk in RDBMS. MySQL does that by default with the primary key, but not Postgres.
For all of its greatness and (mostly well deserved) praises, the lack of a reasonable cluster index capability (as in data order at storage layer) is Postgres' biggest limit IMHO.
Unfortunately, The CLUSTER command not only "blocks" the table for WRITE ops, but more importantly, it also blocks READ operations [0]. pg_repack helps, but is not always available when using a managed PG offering.
Not being able to control data ordering on disk is a potential deal breaker once the data reaches a certain size.