Last updated May 14, 2016. Created on July 3, 2014.
Edited by hansfn, Christopher James Francis Rodgers, hellyj, woei. Log in to edit this page.

A good overview video on the benefits and drawbacks of various multi-site configurations is Talking Drupal #021 - Multisite.

The discussion below is based on data for a Drupal 8 installation.

A multi-site Drupal 8 setup will save you 'disk space', and in theory, 'time'. Given the relatively cheap cost of electronic storage these days, disk space is of lesser importance, though not free. The major consideration you should have about whether or not to use a multi-site Drupal 8 configuration, is your time.

But in the interest of being complete, lets also consider disk space in detail, and lets start with that.

Disk Space

All Drupal sites, including Drupal 8, require: a codebase, and a database. The codebase is a single set of directories and files. The database is quite separate from the codebase, and is not stored within the codebase.

Codebase

The codebase will at first contain only the 'Drupal Core'. Later, it will include any add-on Modules and Themes (more commonly referred to as 'Contrib' modules and themes, because they are 'contributed' free-of-charge by the Drupal community). The codebase will also later contain any other files you, and your users, add to the site, including images, audio files, video, etc.

Drupal Core: (D8.0.1 as example) 51-Megabytes.

  • 63-Modules: 25-Megabytes. 41 of these are enabled by default using the 'Standard' installation. (as opposed to the only other installation option, 'Minimal', which is recommended for advanced users only)

  • 3-Themes: 0.5-Megabytes. 2 of these are enabled by default.

Let's assume that the average sizes of the Core modules and themes represents a good average for Contrib modules and themes; and that you, for example, install an additional 20-modules, and 2-themes.

In that example, you would be saving 65-MB per domain for your Core, Modules, and Themes, by using a multi-site setup as opposed to having each domain as a separate Drupal 8 installation.

If, additionally, you will have files that can be shared across domains, and you know how to do that, then you will also save on disk space by only needing one set of those shared files, instead of one set of identical files per domain.

65-MB per domain is not in itself a lot, but if your sites warrant being automatically backed-up every 5-minutes, then the disk-storage space savings from using a multi-site Drupal 8 configuration will add up.

Database

The database is where all of the textual content of a site is stored.

It is recommended that you use a separate database for each site.

It is possible for you to have all sites share a single database, and distinguish each site's database tables from each other by, for example, using a different database-table-prefix for each site, but...

If there is any possibility that at some point in the future you might want to (or need to) remove a single site from the multi-site setup, you will most definitely want to have used a separate database for each site. It is infinitely easier to simply extract a single site's database from a multi-site setup, than it is to try and extract a single site's database-tables from a shared database (if that is even feasible).

And, for security reasons, and reasons having to do with developmental glitches, when you have separate databases per domain, it prevents all domains from being affected if one domain is adversely affected. This is particularly important if any of the domains will be administered by others, and especially if separate domains are for separate business clients.

Initially, a Drupal 8 database occupies about 61-Megabytes of disk-space on my computer's hard drive, though when I export it to be saved as a backup, its size is 8MB. And, by the way, a new D8 install has 66 database tables.

Being new to Drupal 8, I can only say that with Drupal 7, a fresh install has 74-tables (Local install using 'Acquia Dev Desktop 2'), and that my three online sites have between 114, and 136-tables each.

I would conclude, therefore, that you would save 61-MB per domain by sharing a single database across all domains; plus 8-MB per domain per backup. So, if you were to carry a running total of 100 backups online at a time, at $1 per month per Gigabyte of storage, the cost savings of using a shared database, instead of one database per domain, would come to $6 per month. But, if ever you have to spend a week of 16-hour days trying to extract a site's tables from a shared database, or undo some other complication caused by your choice to share domains in one database, and if you figure your time is worth $50 dollars an hour, it would take your client 75 years to break even. And if you had to do that on your own time, you would surely agree with the following.

I would recommend that you Not share databases across domains, particularly not when the domains are for separate business clients.

Final database note: It has been that suggested that using a single database might be a benefit in the case where a web-host limits your number of databases. From personal experience, I encourage you to shop carefully before you settle on a contract with any shared hosting service. Taking BlueHost as an example, I had been using their least expensive hosting plan, which was advertised as having 'unlimited storage, bandwidth, and databases'. But then after some years into our happy relationship, my sites were shut down because I had surpassed a 1000-database-table limit. I was able to quickly remedy that sad situation, however, by deleting several of my test-case sites (not knowing how to operate Locally), so that my number of Drupal 7 sites numbered not more than seven.

Time.

The real benefit of Drupal 8 multi-site configurations is in its potential to save you time and effort in development, and maintenance.

Updating all of your sites each time Drupal Core has an update, as for example from version 8.0.0 to 8.0.1, is done more easily with a multi-site setup, because you only have to update a single set of Drupal Core files in one codebase.

News flash: I just watched the video recommend at this page top, and I learned something new; just now. Whereas manually updating Drupal, including the backup first, takes me an average of an hour per site, if I were using Drush the update process would take less than 2-minutes. So, actually, learning Drush might be a better use of my limited time on this Earth, rather than pursuing this right now. Sorry to bail on you.

Yes, a multi-site setup would save you time, however, you have to learn how to actually do it. Unfortunately, I cannot tell you how long it will take you to learn even the basics, and not because I have any doubt about any average person's ability to follow a simple set of steps to do it. It is just that I have never seen a step-by-step, mouse-click by mouse-click, keystoke-by-keystroke guide, or anything even close, which attempts to thoroughly explain in detail to beginners how to do it, and which anticipates the expected stumbling blocks along the way. You see, I myself do not know how to do it. But if my seven years of experience at drupal.org have taught me anything, it has taught me that I could expect to figure it out if I kept at it, so long as I kept my search setting at Google at 100 results a page for a page or two or three. I wouldn't take me forever; let's say, um, ..what year is it now .... I wish you all the best, and hope if you figure it out that you will take time to precisely detail the steps on this page for setting up a multi-site Drupal 8. You gotta figure that for every hour you could have saved if someone had detailed it for you first, by your detailing on this page what you learned, you will easily be saving a thousand individuals that hour, at least, over the next ten years of D8's lifetime. And that way the first five comments on this page will not continue to grow in-kind. Thanking you in advance for your help for the poor newbie to come.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

vliefooghe’s picture

I think that the main advantage of multi-sites is to reduce memory usage of PHP.
When you use the opcache statistics, you see that each instance of Drupal (set of php files under drupal root) is using memory.

Therefore, on a server with limited memory, it can be interesting to use multi-sites installation in order to reduce RAM usage

alreaud’s picture

I've used a multi-site configuration on Drupal 6 for years, with Linux hosting, and it entailed creating directories in the 'sites' directory of the root Drupal installation, and pointing the server to them as the root directory of the corresponding website. The exact process to correctly point your domain's A record will be hosting provider dependent, so I will leave that up to the reader to discover. But as an example, the 'sites' directory of my root Drupal 6 installation contains the following:

drwx---r-x 5 <redacted> 4096 Jan 13  2011 all
drwxr-xr-x 4 <redacted>  4096 Nov 20  2013 alreaud.net
dr-x---r-x 3 <redacted>  4096 Dec 18  2010 default
drwxr-xr-x 4 <redacted>  4096 Nov 27  2013 happycattech.com

My second and third sites are happycattech.com and alreaud.net, so lets take happycattech.com as an example. In that directory we have links to the needed directories that reside in the Drupal installation root directory, with individual files copied over where necessary. It was a trial and error process to discover which files/directories could not be linked. The 'sites' directory in the sites/happycattech.com directory contains the files/directories that are unique to the happycattech.com site:

drwxrwxr-x 2 <redacted>  8192 Mar 23 16:36 _db_backups
-rw----r-- 1 <redacted>   206 Jun  4  2011 cron.php
-rw----r-- 1 <redacted>  2238 Jul 24  2013 favicon.ico
lrwxrwxrwx 1 <redacted>    49 May 27  2011 includes -> <redacted>/html/includes
lrwxrwxrwx 1 <redacted>    50 May 27  2011 index.php -> <redacted>/html/index.php
lrwxrwxrwx 1 <redacted>    45 May 27  2011 misc -> <redacted>/html/misc
lrwxrwxrwx 1 <redacted>    48 May 27  2011 modules -> <redacted>/html/modules
lrwxrwxrwx 1 <redacted>    49 May 27  2011 profiles -> <redacted>/html/profiles
lrwxrwxrwx 1 <redacted>    51 Jun  3  2011 robots.txt -> <redacted>/html/robots.txt
lrwxrwxrwx 1 <redacted>    48 May 27  2011 scripts -> <redacted>/html/scripts
drwxr-xr-x 4 <redacted>  4096 May 27  2011 sites
lrwxrwxrwx 1 <redacted>    47 May 27  2011 themes -> <redacted>/html/themes
-rw----r-- 1 <redacted> 26250 Jun  8  2011 update.php
lrwxrwxrwx 1 <redacted>    51 May 27  2011 xmlrpc.php -> <redacted>/html/xmlrpc.php

The 'sites' directory in the sites/happycattech.com directory corresponds to the same entries that would be expected in a root Drupal installation. The directory contains:

drwxr-xr-x 4 <redacted> 4096 May 29  2011 all
dr-xr-xr-x 3 <redacted> 4096 May 27  2011 default

'default' in sites/happycattech.com/sites contains the site specific settings files and the site specific 'files' directory for images, etc.:

-rw----r-- 1 <redacted> 9485 May 27  2011 default.settings.php
drwxrwxr-x 8 <redacted> 4096 Jan 21  2014 files
-r-----r-- 1 <redacted> 9514 May 27  2011 settings.php

'all' in sites/happycattech.com/sites contains links to the root Drupal installation library directory, and happycattech.com site specific module and theme directories:

lrwxrwxrwx 1 <redacted>   60 May 27  2011 libraries -> <redacted>/html/sites/all/libraries
drwxr-xr-x 3 <redacted> 4096 Apr 19  2013 modules
drwxr-xr-x 3 <redacted> 4096 May 27  2011 themes

'modules' in sites/happycattech.com/sites/all contains links to the pertinent module directories of the root Drupal installation additional (non-core) modules (usually sites/all/modules) directory:

lrwxrwxrwx  1 <redacted>   69 May 29  2011 admin_menu -> <redacted>/html/sites/all/modules/admin_menu
lrwxrwxrwx  1 <redacted>   72 May 29  2011 advanced_help -> <redacted>/html/sites/all/modules/advanced_help
lrwxrwxrwx  1 <redacted>   66 May 29  2011 advpoll -> <redacted>/html/sites/all/modules/advpoll
lrwxrwxrwx  1 <redacted>   69 May 29  2011 autologout -> <redacted>/html/sites/all/modules/autologout
lrwxrwxrwx  1 <redacted>   73 May 29  2011 backup_migrate -> <redacted>/html/sites/all/modules/backup_migrate
lrwxrwxrwx  1 <redacted>   66 May 29  2011 captcha -> <redacted>/html/sites/all/modules/captcha
lrwxrwxrwx  1 <redacted>   62 May 29  2011 cck -> <redacted>/html/sites/all/modules/cck
... etc...

The same occurs with the sites/happycattech.com/sites/all/themes directory. This recursive process is a bit confusing, and it causes the hosting provider tech support team to scratch their heads, but it does work. As an example, see http://happycattech.com. Three seperate databases control the content of the three sites, which allows for site separation, and PHP does not seem to get confused because of the use of links.

Whether or not this will work on Drupal 8 I can't vouch for, but I'm going to be experimenting soon. An issue I can already see is that an install of a new extension module in the root Drupal installation won't create a link to the module in the corresponding multi-site directory. Nor would the install of a module on one of the multi-sites cause the module to install in the root Drupal installation. These are things that will have to be worked out in practice...