You’re building software for financial companies and wondering what architecture to use. You’re a SaaS tech startup looking to hit the market hard and scale fast. You’re a sales manager for a construction materials supplier looking for productivity software to enhance your team.

All three of these come back to the same debate; multi-tenant vs single-tenant.

While we’ve touched on multi-tenant architecture before, this post will get into the finer details of the topic and tell you which of these architectures you should be using both as a software provider and as a customer.

We will cover:

• What multi-tenant and single-tenant architecture is
• Pros and cons of multi-tenant architecture
• Pros and cons of single-tenant architecture
• Multi-tenant vs single-tenant (and how to make the most of them)

Let’s get started.

What multi-tenant and single-tenant architecture is

While we covered the topic in-depth in our last blog post, let’s recap what multi-tenant architecture is to set the scene for the rest of the discussion.

Multi-tenant architecture is a setup where one or more servers are running a single instance of software for multiple customers. This has the potential to provide a single instance experience for each customer, even if multiple users are active within each customer account. These users will also be unable to see or access the data of other customers, and are typically managed as to the data from their own customer account they can access via customizable permission levels.

This multitenancy setup is one which many SaaS companies utilize, as it allows their users to remain active at the same time without affecting the performance of the application for other users. It can also reduce costs by letting server resources react to the current demand, and retains most of the security and privacy benefits of a siloed experience.

Single-tenant architecture works instead by providing each customer with their own server(s) or database(s). It’s a much bigger resource commitment, and will generally be the choice of anyone looking to have an onsite setup. Cloud-hosted single-tenancy is popular though, and it certainly doesn’t suffer in such a situation.

Due to the nature of each of these, both have their own pros and cons. Let’s dive into them now!

Pros and cons of multi-tenant architecture

Since we covered this recently, let’s start off with a brief overview of the pros and cons of multi-tenant architecture for software. These will cover aspects of software set up this way from the perspective of customers and the software providers alike.

Remember, if you want more information, check out our in-depth dive into multi-tenant architecture!

Pros of multitenancy

Multi-tenant architecture typically incurs lower costs than single-tenant. This is because multitenancy requires much less server space and dedicated resources for each customer.

Remember that multitenancy allows for server resources to be shared between customers and users based on their needs, rather than reserving a certain amount for each. This means that you won’t have to spend as much on getting enough servers for everybody to use at full capacity all the time - you need to be able to handle peak loads, but that doesn’t mean you have to be running with those costs 24/7.

Multitenancy is also great for pushing updates to your customers, as everything is still centralized enough to simply update the software on your servers to push those changes to all of your users. There’s no way that anyone can be left on an old version of the software, because you’re updating everyone at the same time.

Onboarding new users (for the software provider and for customers) is also easy. Since all instances of the software are largely going to be identical aside from customer data, it’s possible to create a universal onboarding flow and to optimize your software to facilitate that.

Cons of multitenancy

The first drawback of multitenancy is that you’ll need to have the architecture in place to deal with peak loads even when usage isn’t at those levels. This isn’t the end of the world, and thanks to tools like AWS Auto Scaling you can let your systems automatically scale up and down again depending on your current needs.

In other words, it’s an issue, but there are simple ways around it. The same can’t be said for the security of a multi-tenant setup, as there are many extra points of access and failure to protect.

As a software provider, you’d need to make sure that your software and servers in general are secure from outside access and from your own customers. Since multiple customers could be sharing the same server there are a huge number of extra checks and balances that need to be implemented in order to satisfy any standards of data protection that you need to comply with (such as HIPAA, GDPR, etc). That’s on top of needing to keep customer data secure from other customers and from users within the same customer who shouldn’t be allowed to access certain data.

Having multiple customers on the same servers can also result in it being much more difficult to isolate their data if a backup or rollback is required. It’s not impossible, but it will require significantly more work to enact than on a single-tenant setup.

The final main drawback is more on the side of the customers, as multi-tenant software will inherently be less customizable than single-tenant setups. Multi-tenant architecture means that the software has to be the same for every customer, and the lack of dedicated resources means that there will be less overall space and resources dedicated to individual users. You’re limited by the fact that any customization options have to be available (even if they’re not unlocked) for everyone using the software, rather than just a specific instance of it, otherwise mass updates will either not work or be exponentially more difficult to create.

Pros and cons of single-tenant architecture

While the benefits and drawbacks to single-tenant architecture are fairly self-apparent once you know the pros and cons of multitenancy, it’s worth going through these with a view toward software providers and customers once more.

Pros of single-tenancy

Single-tenancy solutions are much easier to secure than their multi-tenant counterparts, as there are fewer points of entry into each system by their very design.

This isn’t to say that security isn’t important in single-tenancy - it’s just as vital to meet universal security standards and to ensure that users aren’t open to malicious attacks as a result of their usage. However, being a closed environment that caters to a specific customer naturally means that there are fewer chances for data to be visible or accessible to someone outside of that customer’s organization. There’s still every chance of a user in that organization causing a security breach, but that’s not the responsibility of the software provider to enforce (other than providing suitable user permission levels to allow effective self-governance of customer accounts).

There’s also the benefit of having more dedicated resources for each customer which, in theory, means that software performance remains much more consistent even at peak usage times. However, the effect of this is lessened somewhat by the availability of techniques for multi-tenant solutions to flexibly increase resources to enable better performance. It’s a nice thing to have, but it’s not really a justification for using one over the other.

Customization, however, most certainly is.

Single-tenant architecture may run on the same rough template as the software provided to other customers, but because it’s entirely limited to being for one customer there are far more opportunities to have it customized. We’re talking about everything from color schemes and language to entirely new features, interactions, and integrations depending on what the customer needs.

Think of it this way; when you have a product that has to be the same for everybody, there’s only so much that you can allow customers to do to adapt it to their needs without it being an extremely sunk cost.

However, with each instance being provided to customers separately the shackles are suddenly off! The only limitation on what kind of customization is viable is the cost of the feature versus the gain from the customer(s) requesting it. As a provider you could even negotiate separate deals with customers who have specific requirements.

Finally, with customer data being separately handled it’s much easier for that data to be isolated and backed up should something bad happen. Migrating data is much easier for the same reason, meaning that a single customer which branches out or expands its operations can be more readily accommodated.

Cons of single-tenancy

Single-tenant architecture mainly falls where costs are concerned, as having to host software on multiple, siloed and dedicated environments can be much more expensive, both monetarily and in terms of unused memory.

Think of it as the difference between On-Demand instance pricing and Reserved Instances in AWS. Single-tenancy will comparatively cost more than multi-tenancy because the customer won’t always be using 100% of the server’s capacity, but they will still be paying for it.

Setting the system up for a customer can also take longer and be much more costly, as each customer requires their own instance and database to be siloed from all of the others.

Software maintenance is also much more complex with single-tenant architecture, as this prevents the software provider from automatically updating everything all at once. Customers will generally either have to install updates themselves, or make sure that the provider has a way to access their setup to perform the update for them.

Closing out this section, single-tenancy software can be more difficult to onboard new users with. This is due to a combination of aspects, although namely the customizable nature of the software means that it can vary wildly from customer to customer - creating a universal onboarding flow doesn’t work.

Multi-tenant vs single-tenant (and how to make the most of them)

The choice of multi-tenant vs single-tenant comes down to a few key factors:

• Are you a software builder/provider or customer?
• What industry are you part of?
• Do you need to be compliant with strict security regulations?
• What is the size of your company?

As a software builder or provider, the main things to keep in mind are what industry you’re part of, what the security guidelines and requirements are for you to operate, and the size of your team and customer base.

If you’re in, say, healthcare, financial, or legal industries, then you’re going to need to use single-tenant architecture as the basis for your software due to the relative lack of security issues. If you’re instead a productivity-related SaaS company that’s aiming to scale fast, multi-tenant architecture will be better suited because it will allow you to more easily grow the product to meet demand.

As a customer you instead need to think about your budget, whether your industry allows for data sharing, and how much customizability you need.

A multi-tenancy product will almost always be cheaper to purchase or subscribe to, but if you aren’t allowed to share your data due to security regulations then that simply isn’t an option for you. Similarly, if your company needs to customize a product to its very specific needs, a single-tenant setup will more easily accommodate this.

The choice is ultimately yours, but with everything we’ve highlighted you should have everything you need to make the best decision for your company.

‍Want to keep up with the latest Aimably posts for more great insights or tell us what topics you’d like to see expanded? Let us know over on our Facebook and Twitter pages!