Should I use a single or multiple database setup for a multi-client application?

Question

I am working on a PHP application that intends to ease company workflow and project management, let\'s say something like Basecamp and GoPlan.

I am not sure on what

Answer 1

Another point to consider is that you may have a legal obligation to keep one companies' data separate from anothers'.

Answer 2

In my view, it will depend on your likely customer base. If you could get into a situation where arch-rivals are both using your system, then you would be better off with separate databases. It also depends on how multiple databases get implemented by your DBMS. If each database has a separate copy of the infrastructure, then that suggests a single database (or a change of DBMS). If multiple databases can be served by a single copy of the infrastructure, then I'd go for separate databases.

Think of database backup. Customer A says "Please send me a copy of my data". Much, much easier in a separate database setup than if a single database is shared. Think of removing a customer; again, much easier with separate databases.

(The 'infrastructure' part is mealy-mouthed because there are major differences between different DBMS about what constitutes a 'database' versus a 'server instance', for example. Add: The question is tagged 'mysql', so maybe those thoughts aren't completely relevant.)

Add: One more issue - with multiple customers in a single database, every SQL query is going to need to ensure that the data for the correct customer is chosen. That means that the SQL is going to be harder to write, and read, and the DBMS is going to have to work harder on processing the data, and indexes will be bigger, and ... I really would go with a separate database per customer for many purposes.

Clearly, StackOverflow (as an example) does not have a separate database per user; we all use the same database. But if you were running accounting systems for different companies, I don't think it would be acceptable (to the companies, and possibly not to the legal people) to share databases.

Answer 3

Having a database per client generally does not scale well. MySQL (and probably other databases) holds resources open per table, this does not lend itself well to 10k+ tables on one instance, which would happen in a large-scale multitenancy situation.

Of course, if you have some other issue which causes other problems before you get to this level, this may not be relevant.

Additionally, "sharding" a multi-tenant application is likely€ to be the right thing to do eventually as your application gets bigger and bigger.

Sharding does not however mean one database (or instance) per tenant, but one per shard or set of shards, which may have several tenants each. You will need to discover the right tuning parameters for yourself, probably in production (hence it probably needs to be pretty tunable from the outset)

€ I can't guarantee it.

Answer 4

The following screencast explains how it's done on salesforce.com. They use one database with a special column OrgId which identifies each tenant's data. There's much more to that so you should look into this. I'd go with their approach.

There's another great article about that on MSDN. It explains in depth when you should use a shared or isolated approach. Remember that having a shared DB for all your tenants has some important security implications and if all of them share same DB objects you might want to use [row level security] - depending on the DBMS you use (I'm sure it's possible in MS SQL Server and Oracle, probably in IBM DB2 also). You can use tricks like row level security in mySQL to achieve similar results (views + triggers).