Matthew, thank you. Your example makes total sense to me. I've seen a lot of threads asking the question "How should I... different databases or one database?" for essentially the same scenario you pointed out. And while in the past my preference has been separate databases, you do run into the redundancy of common data, or the separate DB for common data issue. And, as you briefly mentioned, any modification to sprocs have to be deployed across all the databases, where here you just have the one copy in production. (or I guess you could have schema specific sprocs if you needed them, but I like one common set of code most of the time). Of course, you still have the issue of any changes to table definitions have to be rolled out to all schemas.

So again, thanks for providing a reasonable use.