title: Is there a benefit to having several connection pools over one single connection pool?
body: <p>We are taking a (large) legacy application that uses a single connection string everywhere so they can use a single connection pool.</p>
  
  <p>The plan is to take a service orientation and break up the application into smaller sub applications.  Each one of these applications will be hosted in IIS and I am trying to figure out if there is a benefit of the app pool for each application having a different identity tied to that application, i.e. [Domain]\SVC_ApplicationA rather than having all the app pools use the same identity and therefore a single connection pool. </p>
  
  <p>While we have a single (SQL Server) database now, as we move to this new model the plan is to start with a new schema inside the original DB for each application.  The dbo schema will be deprecated as legacy and in order to access dbo, the applications must do so through objects (views, procs, etc...) in their respective schema.  The caveat being that an application schema is only allowed to access objects within its own schema or from dbo, not from other application schemas.</p>
  
  <p>If each application had its own identity, we could secure each schema independently.  My concern is that if we have 50 applications we would have 50 connection pools.  Would this negatively impact performance?  I know this is a loaded question but I am really only asking in the abstract.</p>
  
  <p>Thanks!</p>