Multisite Drupal

Multisite Drupal

Multisite Considerations

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, let's also consider disk space in detail, and let's 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.


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 represent 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.


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.


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 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.