WordPress SaaS: Multi-tenant vs Multisite vs Standard Sites

There are three deployment strategies you can use when building your SaaS on WordPress.

• Multi-tenant: Some or all code is shared but database and configurations are separate for each customer. Sites are regular sites and you can scale the deployment both vertically (larger servers) and horizontally (more servers) across multiple regions.
• Multisite: WordPress multisite is a core feature of WordPress where all code is shared. A single database is used but each customer site has their own tables inside the database (with the exception of the user table.) Most plugins and themes don’t do specific testing for Multisite and will not offer official support for this configuration. A multisite architecture can only scale vertically.
• Standard sites: No code, database or configuration is shared between customers. Instead, you depend on the features of a central management console to manage the sites in bulk. This deployment architecture can scale both vertically and horizontally.

We cover these three deployment types in our prior article, Planning a WordPress SaaS. However, the comparison between the three deployment options is just part of that article.

In this article we’re just pulling that information out so it can stand on its own. If you have read that article, this one is likely to be a bit redundant for you.

WordPress Multisite

As mentioned earlier, WordPress has a feature called “Multisite”. It allows multiple sites to use the same database with a single copy of WordPress, plugins & themes.

The advantage of using this configuration is the reduction in code duplication. With only a single copy of the code required (WordPress + Plugins + Themes), you only ever have to change things in one place for every customer site to update.

However, there are significant disadvantages.

• Not all plugins and themes are built to be Multisite aware. There are special function calls and initialization calls that plugins and themes need to use when running on Multisite. If not used when they should, information can be shared across sites that should not be allowed. Or data returned by standard function calls will be incorrect and cause hidden bugs.
• All sites share a single user table. This has some ramifications. For example, if a user has accounts with multiple sites on the network, they will be forced to use the same login for both sites. But they might not realize this and will constantly end up resetting passwords, resulting in a poor user experience.
• You can only scale it vertically – i.e.: if you need more resources you need to use a bigger server.
• If you install or update a plugin or theme with bad code, all customers are affected.
• If your server gets compromised, all customers are automatically compromised.
• If you have one or two customers whose resource needs are significantly larger than your other customers, it is not easy to pull them out to a new server. Instead, you will have to get a larger server even though it’s only required for a single customer.

Assuming you configure things correctly and use the right plugins and themes, you still have a single point of failure. A single mistake can take down all your customers.

There is one very significant advantage to using Multisite though – there is a product called WPUltimo that make quickly rolling out a WaaS on a multisite relatively easy. There are still many limitations.

But, for less than $500, you can purchase it, install it on a WordPress site, convert the WordPress site to a Multisite, create a template site, create and assign pricing plans and be up and running.

Though, as with all things related to WaaS deployments, the devil will be in the details since that default basic template will not have a pleasant onboarding experience for customers (among other required features).

Standard Sites

The easiest way to get your customers up on your platform is to give each of them an individual WordPress site.

Individual sites are easy to manage and plugins and themes don’t need anything special to correctly run on them.

Each site will contain a copy of WordPress and all plugin and themes which is a lot of code duplication.

The biggest issue you will encounter with this approach is management of all those individual sites. You need a capable central control panel to help you manage them in bulk.

Other issues include:

• Integrating a template site into a billing platform so that the template is automatically deployed when a user signs up.
• When it’s time to upgrade code, you’ll have more work to do.

But, there are significant advantages if you can get the individual site management and billing integration under control:

• You don’t have a central point of failure so a compromise or bad plugin or theme will not necessarily affect all your customers simultaneously.
• You can do ‘rolling’ upgrades to test out new features without impacting all your customers at the same time.
• You get the ultimate scaling flexibility with both horizontal and vertical scaling available. i.e: you can increase the size of a server or use more servers.
• You can easily use servers from different server providers so that if one provider goes down, not all your customers are affected.
• Its easier to place your sites in the region where your customer(s) are located – why place sites for a customer in France on your servers located inside the United States?
• You can easily scale up an individual customer without impacting others.
• You can move individual sites to a new host or provider anytime since they’re usually not built with any special configuration to tie them tightly to one host or another.
• You can easily build out special mods for a customer without impacting other customers.

Architecture Option #3: Multi-tenant

This configuration is similar to Multisite.

The biggest difference between this configuration and Multisite is that, in this configuration, WordPress appears to plugins and themes as a regular WordPress site (not as a Multisite). Thus, no special code needs to be included in them for it all to work as expected.

You only need a single copy of WordPress and your plugins and themes. Or, if running across multiple servers, a single copy for each server if all the servers are not using a shared disk.

Many of the advantages that apply to standard sites apply here including:

• You don’t have a central point of failure so a compromise or bad plugin or theme will not necessarily affect all your customers simultaneously.
• You can do ‘rolling’ upgrades to test out new features without impacting all your customers at the same time.
• You get the ultimate scaling flexibility with both horizontal and vertical scaling available. i.e: you can increase the size of a server or use more servers.
• You can easily use servers from different server providers so that if one provider goes down, not all your customers are affected.
• Its easier to place your sites in the region where your customer(s) are located – why place sites for a customer in France on your servers located inside the United States?
• You can easily scale up an individual customer without impacting others.
• You can move individual sites to a new host or provider anytime since they’re usually not built with any special configuration to tie them tightly to one host or another.

There are some disadvantages.

• The feature is not easily accessible and generally requires a decent amount of custom infrastructure configuration for it to work. However, folks like wpcs.io (and us, of course) are working to make this more accessible.
• There is going to be a small subset of plugins and themes that will not work because they make assumptions about the WP file structure instead of using the built-in functions to located WP components.
• There is no standard configuration so each host that offer it will use a different architecture – this means you are sometimes locked into a particular vendor with no easy way out.
• As with Multisite, a bad update to a plugin or theme or a compromise of the files can affect all tenants that link to the common code repo. For some configurations that can mean all tenants across all servers; for others it could mean all tenants on a single server.
• Most hosts don’t have customer billing and other customer management functions integrated so you’ll likely have to build out a lot of that. (WPCloudDeploy is one of the very very few vendors that offer integrated billing out of the box for multi-tenant configurations)

Multi-tenant WordPress is a relatively new deployment option outside of wordpress.com. The wordpress.com site has been using a version of it for years. But it’s only recently that others have seriously started to experiment with the architecture.

Which Architecture Option Is Right For You?

To choose the right option you have to ask yourself – are you building your WordPress SaaS for the short term or the medium/long term?

Generally, building for the short-term will cost less to get started but be far far more expensive in the medium and long term.

Once you’ve decided which time frame you’re building for, then you need to estimate the number of customers you’ll acquire within that time period.

When you have that estimate, here are our guidelines for choosing your architecture:

• 100 customers or less: Use Multisite / WPUltimo
• 50 – 300 customers: Standard Sites
• 200+ customers: Multi-tenant

This is our opinion of course. And you’ll notice that there are some overlap in the customer limits. This is because the thresholds for each can vary depending on the complexity of each site.
For example – Multisite & WPULTIMO can probably handle more than 100 sites if each site is a simple ‘brochure’ site. But, you might only be able to handle 50 complex membership sites on that same architecture.

If you have severe budget constraints, here are some additional guidelines that might help:

• Multisite / WPUltimo – you can get started for under $1000 USD and a lot of your own work. If you don’t have development experience you’ll find that there are some things such as upgrades and customized user-onboarding that might be beyond your reach.
• Standard Sites – requires at least $2500 and a lot of your own work.
• Multi-tenant – you really can’t get anything production worthy here for less than $5000 (though you can play around with some things for far less.)

Upgrading Your SaaS

One other item you need to take into consideration is how you upgrade your SaaS. Each deployment type have different challenges. We cover these in a separate article: Updating Your WordPress Based SaaS.

Converting Between Options

Another factor to consider is converting between deployment architectures. You might never need this but it’s good to know whether or not you have options and what those might be.

While converting between deployment architectures isn’t easy, going from Multisite to anything else is ten times as hard as converting between multi-tenant and standard sites (or vice-versa).

And, in the case of WPCloudDeploy, it is possible to build and manage a WordPress SaaS that contain both Multi-tenant and standard sites running side by side.

Wrap Up

Deciding on a deployment architecture for your WordPress SaaS isn’t easy. But we think it’s fair to say that you should consider Multi-tenant or Standard Sites first and only consider Multisite as a last resort.

Did we miss anything in our analysis above? If so, drop us a note – we’d love to hear from you!