Never understood why each customer would have their own DB. Must be a nightmare to maintain.
The alternative would be we both have access to the same tables with a permission layer to grant access to row.
Both choices have trade offs but if company makes a mistake and I now have access to your rows? Seems easier to control access at the table layer rather than the column layer.
Or... you can just split things by tables. Or even shard by databases where I don't have access to your database and vice versa.
doing stuff in the application and leaving everything in one database/schema is an option... but don't think you aren't making trade offs and leaving open possible issues by not taking the more comprehensive option like sharding.
And that's just one question to ask. Another is what about upgrading the database and segregating customers. can't do that if everyone is on the same database/schema. What if a customer doesn't want to be updated or upgraded? Much like companies paying for Windows XP support because stuff they have relies on the older version of software?
"where user.id = 123" is a simple solution that quickly becomes more complicate to put it mildly.
edit: I tell a lie, I separated the forums and wordpress databases on a website I run.
Thankfully, our product has customer specific use patterns that we've been able to manage/plan/predict peak load for and what not. Of those 300, a random subset of 20-30 would be 'busy/critical' at any given time, and the others can easily tolerate a delay as migrations + schema changes lock and manipulate things.