At my previous job, we hosted not just one database per client -- in most instances, it was more than that! As I left, there were over 4,500 databases running in one MariaDB cluster, nearly 7,000 in another (ironically smaller) cluster, and 4 "shards" (completely separate, independent web and database servers, even in a wholly separate data center) each hosting 200-500 databases in a single MySQL server. And that company is still growing at a good clip.
The long and the short is that the success of that company proves that such an architecture is indeed feasible. (Caveat: Contrary to the apparent gains in isolation by using separate databases, all data was accessed through a trio of tightly coupled applications that all used the same database user/pass! I suspect performance may have suffered ever-so-slightly if each client had a separate user/pass -- but only slightly.)
From my experiences working closely with the sys admins (technically I was a programmer with the company, but in reality I was the best DBA they had, and the only person they had who knew how to set up a firewall!), performance-related concerns boiled down to concurrent accesses, query complexity/time, index performance, etc. -- all the usual suspects, in other words, and the number of databases on the server played no discernible part, a conclusion affirmed by the highly-paid specialist consultants we consulted regularly.
The bottom line is that you should focus your concerns on your application, on your infrastructure, and not on the number of databases you happen to have. All those other factors will be more than enough to keep you busy resolving performance problems and bottlenecks.