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.