Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're moving to a Hyper-V cluster with data center licensing soon, and will be able to spin up several virtual servers if needed. We have about eight applications which use SQL databases. Is there any advantage/disadvantage to setting up a separate SQL server for each application, versus keeping everything running on one large SQL server?

share|improve this question
Thank you mfinni. I ask because at the moment we have one physical SQL server. Once the cluster is in place, I have a choice whether to place all the apps on a single powerful virtual SQL server or several smaller virtual servers, or some compromise. It seems advantageous to me to give every app its own server; that way if app "A" needs maintenance, app "B" is unaffected. However, I'd like to know of any potential downside to this plan, for example the added burden of administering the extra servers, in case anyone – Cory Jan 11 '13 at 15:17
...has tried out either or both scenarios and has some pros/cons in mind. – Cory Jan 11 '13 at 15:18
Edited my answer. – mfinni Jan 11 '13 at 15:28
Thank you again mfinni -- it makes sense that unless I was to pick up some kind of advantage by separating the apps out to different servers, the added overhead is just wasteful of resources. I appreciate your analysis. – Cory Jan 11 '13 at 15:34
Once you've allowed some time to see if other answers come up, don't forget to mark an accepted answer. – mfinni Jan 11 '13 at 15:41
up vote 0 down vote accepted

The fact that this is on HyperV is mostly a red herring in this situation. Approach it with the same criteria you would use for placing different SQL databases on same or different instances on actual hardware.

  1. System performance limits - memory, IO, CPU, threading/processes, etc. If putting the DBs all together will swamp your performance, scale out onto more instances on different hardware (or with a VM, scale up your provisioned hardware if possible.)

  2. Other criteria, like backup windows, scheduled jobs, clustering, which is generally an extension of the above. Security isn't generally a concern, unless you have different databases that need to get authentication from different untrusted domains.

Per your comment : if you're doing it with all on one instance now and not having problems, keep doing that, on a correctly-sized VM. Adding more VMs will just use more resources for additional OS instances. What sort of maintenance would you be doing on one database that is impacting other databases? Unless you're doing something like re-indexing in one database that is impacting performance in other systems, and they don't have overlapping maintenance windows or periods of allowed reduced performance. This is what I was getting at by saying the only real reason to do this is for performance reasons. Otherwise, try to consolidate.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.