Like Tim Obezuk, I’ve previously designed a system with multiple databases, but one code base. Effectively each client has their own schema (MySQL) and there is a a single “authentication” database not only to assert that a login is valid, but also allowing mapping of that login to a client, and therefore to a specific database.
This gave a number of advantages — the local environment was very much the same as the production one, databases are smaller (we could reasonably grab a copy of a production db, restore it locally and debug against it if needed).
We solved the upgrades problem by writing a set of tools in the product that ensured that the database is up to date on login, on request with a fall-back of this running as a cron job (checking no users are connected and upgrading databases as a background task).
We also created a set of classes that would allow a single query to be run over multiple databases (and over multiple servers) consolidating the result set.
The big risk with this approach is you can make a “quick fix” to a single database and you risk not having that made good across all databases — more a case for discipline than a technical issue.