As background, I've never been a fan of multiple instances. It's a useful thing to have available and I use it on a server today, but it's never provided a solid way of isolating resources for each instance.

Next, one of the things I evangelize is that DBA's should make every effort to make a database portable. Portability is important because sometimes we run short of space and/or performance, and the ability to quickly and easily move a db to another server is a nice thing to have. We used to use views to abstract three part and four part lookups, but since SQL 2005 synonyms are a cleaner way to solve that problem. Actually, it only solves part of the problem, since we still have jobs that access the database, external reports, and often linked servers.

We can fix some of that by setting up a DNS alias for each database (thanks for my friend John J for that idea) so that we don't require any app code change if we move a db, and that should handle reports too. Linked servers aren't terribly hard, but what about jobs? Is there an elegant way to handle them besides a good naming convention such as DBName - Job Name, or creating a category that maps to each db, or just using the dbid assigned as the job context?

Instead, I propose a simpler model - every database runs in a separate VM. That forces portability because everything moves as a package. It's a challenge as far as licensing because unless you have the Enterprise Edition you have to buy licenses for each VM, but it might be worth spending more (or getting MS to change the licensing model). Nothing that says you couldn't put more than one database on a VM when it made sense - an example might be a lookup db or an archive db that you really do want in the same place all the time).

Licensing is a negative, I think all the rest is positive if you can live with SQL on a VM. It's a brute force solution, but it also feels mildly elegant. If the licensing question could be fixed would you consider this as a solution?