Single vs multi-tenant SAAS
Ryan Mohr

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.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.