Does Drupal support Multitenancy?
One of the strengths of Drupal is that it's not just a tool for building a single website. It can be used equally well for managing multiple companion sites together. This capability has existed for many years, but is not always well understood. 

And in true Drupal fashion, modern Drupal has several different options available for users looking to run a series of Drupal sites together, each with its own trade-offs.


Separate installs
Features-based installs
Multi-site
Domain Access
Organic Groups
Mix and match




Separate installs :
Sometimes the best strategy is to not unify sites at all. In this case, any similarity between different sites is largely coincidental. If there will be a large number of sites then some automation tools such as Drush or Aegir may make spinning up new sites easier, but from a site building perspective they are different sites.

Features-based installs :
As a slight variation of separate installs, it's possible to run multiple installs with the Features module. For those not yet familiar with it (and you should be), Features is essentially an automation tool for those pieces of configuration that Drupal allows to be mirrored to code so that they may be checked into version control. These days much (but sadly not all) of Drupal's configuration can be feature-ized. The most effective configuration components to manage this way include content types, views, panels, and image styles.

Multi-site :
For years Drupal has had the ability to run multiple sites off of a single install base. In this case, there is a single copy of Drupal's code base but each college or department has its own settings.php file, which points to a different database. From a site builder perspective, this is almost the same as having separate installs. Every site must be configured independently, but every site may also be configured independently. Each site may also live on its own domain or in subdirectories, although the latter requires some symbolic link trickery and editing the Apache .htaccess file to make work.

Domain Access :
Domain Access (DA) is actually an access control module that uses the node grants system. With DA, a site administrator can point multiple domains to a single Drupal install. Drupal will then self-filter any nodes in the system to display only on specific domains. There is still a single database, single code base, single user base, and single content pool.

Organic Groups :
With OG, each node (any entity, really) can be made into a "group", and then other nodes can be associated to one or more groups. Depending on the configuration, that could impact navigation, path aliases, theme selection, and so forth, to give the impression of different "sites".

Mix and match :
When planning a large-scale Drupal rollout, it's also possible to consider combining strategies. For instance, both Domain Access and Organic Groups can run on their own Drupal instance that just so happens to be multi-site... and have other Drupal sites hosted on it as well. Workbench can be used for administration of content on a single Drupal instance independently of whether it uses DA or OG, and can easily be enabled on multiple instances on the same install as well. As of this writing Workbench does not integrate with either module, so for instance Organic Groups or Domains cannot be used to define "sections" in Workbench, but such integration is possible.



Conclusion

Drupal offers a variety of solutions to address multiple sites with shared and separate content. As with all things Drupal there is no right solution — just options for your specific needs. Evaluate your goals and make decisions based on them; you may find that Domain Access is a better fit for your content editors or a multi-site setup is much easier to manage for your system administrators.