You are asking about "single tenant" (one db per customer) vs "multi-tenant" (one db for all customers) for SaaS (software as a service). You may want to Google those terms for a lot of opinions either way. MSDN has a write up on the various options.

I find single tenant (separate databases) quite tedious to maintain. If you have an explosion of customers, it quickly becomes unmanageable to maintain so many separate databases, and your scripts need to be extended to loop across all tenant databases to run any DDL or bulk operations. Expanding the number of databases has other ramifications such as affecting backup (such as if you are creating a new subdir per db name) and restoration (need to script restore across all dbs in case of failure).

Also, if you are not careful about your development strategy, schemas can get out of whack across the databases. I do not recommend doing different schemas per tenant (having different functionality for each customer's application, for instance), as it becomes a complete nightmare for ongoing maintenance and support at that point. You don't mention it, but you can also consider multi-tenant vs single-tenant in your application code deployment as well as database.

If your application provides the same schema set to each tenant, I greatly prefer the multi-tenant approach (which they label "Shared Database, Shared Schema"). As the article above notes, it can be extended to provide some limited customization per tenant if need be. Proper application coding should assure that one customer cannot access or view another customer's data. Application side, you should only have one deployment of code to a single location versus having a deployment per customer.

As someone noted, if the quantity of data is huge per customer, partitioning each customer's data to a separate file may be advantageous. I would not go this route on a whim, however -- research and testing would be required to see if customer access times lower in this scenario. I think I'd personally require the multi-tenant db to be 20G or more (and core tables be 250M+ rows) before considering partitioning.

HTH,

SQLServer 2005 DBA