Part of being a SharePoint solutions architect means designing a
solution based on technical, maintenance and governance
requirements. One of the most important initial design questions
that I have to take into consideration is whether to recommend
Sites or Site Collections for a solution. So for this blog I wanted
to outline the reasons for each approach as well as a list out the
pros and cons.
The biggest factor in choosing to go with sites is size. A
single site collection cannot span multiple content databases.
Microsoft recommends that a single content database should not grow
beyond 200 Gigabytes. This isn't a hard limit, and with expensive
hardware (Disk sub-system performance of 0.25 IOPs per GB. 2 IIOPs
per GB) you can go up 4 TB however 200GB is the best practice for
optimal performance and reasonable backup procedures. That being
said, it really depends on the type of site that you are designing.
For an internet facing site, a single site collection can work
great. However for an enterprise portal and document management
system that will service thousands of users and multiple
departments, multiple site collections is usually the better
approach since 200GB is a drop in the bucket these days.
When making the decision to do multiple site collections, there
are some tradeoffs to be aware of. Without the use of custom code,
a master page cannot span multiple site collections. Any highly
branded site would usually have a custom Master page. Master pages
are like the skin of the site and define its look and feel as well
as layout. That being said, by developing a custom feature you can
have a unified master page across multiple site collections however
making changes to that Master page cannot be deployed from
SharePoint designer. You will have to deploy it via custom code as
Another drawback is security groups. Site collections don't
share security groups, and if you have very granular security,
there may potentially be a lot of maintenance in replicating the
same groups in each site collection. If you need to have multiple
site collections, one way of mitigating this is by using active
directory groups inside of SharePoint groups. That way you can make
the change in one place and have it reflected in each site
collection as long as they all reference the same AD Group.
Lookup lists are another reason to use a single site collection.
Site columns which use lookup lists only work in the same site
collection. Though you can use the content type hub to replicate
content types across site collections, lookup lists can't be
For the best user experience, global navigation (also called the
top menu) should be the same across your entire portal whether you
are using single or multiple site collections. Global
navigation is limited to a single site collection, so again unless
you use a custom control or code, you will be doing a lot of manual
updates to keep every site collections navigation in sync.
The biggest advantage of going to site collections is that your
content databases will scale much better beyond the recommended
limit of 200GB. What this means is that you can use multiple
databases to power your portal, which also means potentially
multiple database servers. This allows your SharePoint server to
scale much better along the data tier with additional servers.
Also of advantage is the ability to place database servers in
separate geo distributed locations to increase the performance of
farms that are accessed across multiple offices around the
This was listed as a positive for sites, however if your
requirements need certain sites to be highly secured and have very
different and separate security groups (for example multiple
domains) then splitting out a site as a site collection is a better
Backup and Performance
Since using multiple site collections allows you to use multiple
content databases, it also makes backing up your databases much
more practical since each one will be a manageable size. Another
advantage, though not as apparent, is when you go to do an update
of a service pack or hotfix or even an upgrade of the whole server,
this also means updating your content database. If you have a
database that is terabytes in size the update could take an
extremely long time which means more downtime for your users.
As you can see there are many factors that go into planning a
SharePoint portal. So make sure you take these items under
consideration because splitting out a site collection into multiple
site collections is very difficult once it is already built
This article by Neil Barkhina was orginally posted on