title: SQL Server: Separate schemas or separate databases
body: <p>We have two products that get implemented at customer sites, one of which requires the presence of the other. I implemented a separate schema within the same database as the main product for the database objects needed by the add-on. Because the add-on could theoretically become an add-on to future products as well (although none are currently planned), I am reconsidering that decision. We currently use 2005, but plan to migrate to 2008 R2 or Denali in a year or so. </p>
  
  <p>One factor is that maintaining the separate schemas in separate VS 2010 database projects is difficult because of the inability to restrict the view of a VS project to one schema when comparing the project schema to a database that contains another schema.</p>
  
  <p>Are there any reasons to avoid splitting the two schemas into separate databases, assuming they will always be in the same SQL Server instance? </p>
  
  <p>Backups are handled by scripts that operate on all databases in the instance, so that is not a concern. We are hoping to offer the products on a hosted (SaaS) basis in the future, so the impact on multi-tenancy is a factor. We would likely host multiple customers within an instance.</p>