SaaS: one web app to one database VS. many web apps to many databases

Question

I am planning to develop a fairly small SaaS service. Every business client will have an associated database (same schema among clients' databases, different data). In addition, they will have a unique domain pointing to the web app, and here I see these 2 options:

1. The domains will point to a unique web app, which will change the connection string to the proper client's database depending on the domain. (That is, I will need to deploy one web app only.)
2. The domains will point to their own web app, which is really the same web app replicated for every client but with the proper connection string to the client's database. (That is, I will need to deploy many web apps.)

This is for an ASP.NET 4.0 MVC 3.0 web app that will run on IIS 7.0. It will be fairly small, but I do require to be scalable. Should I go with 1 or 2?

Answer 1

This MSDN article is a great resource that goes into detail about the advantages of three patterns:

1. Separated DB. Each app instance has its own DB instance. Easier, but can be difficult to administer from a database infrastructure standpoint.
2. Separated schema. Each app instance shares a DB but is partitioned via schemas. Requires a little more coding work, and mitigates some of the challenges of a totally separate schema, but still has difficulties if you need individual site backup/restore and things like that.
3. Shared schema. Your app is responsible for partitioning the data based on the app instance. This requires the most work, but is most flexible in terms of management of the data.

In terms of how your app handles it, the DB design will probably determine that. I have in the past done both shared DB and shared schema. In the separated DB approach, I usually separate the app instances as well. In the shared schema approach, it's the same app with logic to modify what data is available based on login and/or hostname.

Answer 2

I'm not sure this is the answer you're looking for, but there is a third option:

Using a multi-tenant database design. A single database which supports all clients. Your tables would contain composite primary keys.

Scale out when you need. If your service is small, I wouldn't see any benefit to multiple databases except for assured data security - meaning, you'll only bring back query results for the correct client. The costs will be much higher running multiple databases if you're planning on hosting with a cloud service.

If SalesForce can host their SaaS using a multitenant design, I would at least consider this as a viable option for a small service.