What Is Multi-Tenant Architecture?

SaaS products are often associated with multitenancy, or a multi-tenant architecture. And as the interest in, popularity of, and profitability of SaaS products increases, interest in multitenancy-related concepts is on the rise too.

What is a multi-tenant architecture? How does it differ from a single-tenant model? Which is better for a SaaS solution?

And what should non-tech product founders know about this topic?

In this article, we shed light on complex tech concepts, explain the strengths and weaknesses of architecture models, and provide you with tips on how to choose the right tenancy model for your SaaS application.

Multitenancy explained in simple words

To explain the concept of multi-tenancy, we’re going to use a simple analogy.

Say you need to visit your bank. You open a huge wooden door in a 19th-century building, tell a receptionist about your appointment, and go to your manager’s office. There, you ask for a cash withdrawal, credit, insurance, or any other service your bank provides.

You don’t interact with other customers. You may not even meet any. You don’t know who these customers are, how much money they have in their bank accounts, or what banking services they use.

You and other customers store your money in one bank, but your assets are fully isolated. All customers use the same bank and the same infrastructure but their data, money, and family relics are kept separate and secure.

This is pretty much how a multi-tenancy works.

In a cloud, users have access to the same server but their access level and set of available features may differ. At the same time, their data, business logic, usage history, and any other information are fully separated.

To get some more information about this, you can check our article on cloud vs saas topic.

The concept of a tenant and the case of Atlassian

Atlassian was launched in 2002. You may have tried some of their products: Jira, Confluence, Trello, and Bitbucket are the four most popular.

Telling the story of Atlassian would be the perfect way to start our journey in multi-tenancy application development.

Initially, Atlassian was a server company. The team built and bundled tools; the customers purchased these tools, extracted them from archives, and set them up on their devices.

That went well for many years until customers started complaining about the complexity of the setup processes and further maintenance challenges. The Atlassian team addressed those issues rapidly: they decided to take over the maintenance challenges and let customers simply access and enjoy the functionality.

To do this, they migrated their server products to the cloud, moving to a so-called _single-tenant architecture. _Each tenant became a cloud customer, while a single computer node served the single tenant’s needs.

Wait… but who’s a tenant? In the case of banks and customers, a tenant is a customer. In a SaaS application, a tenant is a user, an account, a workplace, or a team. A SaaS founder can consider tenants to be businesses they provide their services to. In the case of Atlassian, a tenant is a company or team that uses Atlassian products for their own purposes. For example, if a development team uses Jira for Agile project development, this team is a tenant.

A tenant is a single entity with defined permissions, features, and settings.

Let’s go back to the story of Atlassian.

The Atlassian team moved to a single-tenant architecture, and their user base kept growing.

As it scaled, new problems emerged. Outages led to downtime of the entire system; upgrades were time-consuming, complex, and problematic; maintenance was costly, and keeping in mind that the Atlassian user base was growing, the expenses were multiplying.

To solve this problem, the Atlassian team decided to take another innovative step and migrated to a multi-tenant architecture.

This migration brought multiple advantages to all products, as it allowed the team to unlock horizontal product scaling, keep on track even if some of the nodes were down, ensure smooth zero-downtime upgrades, and optimize maintenance costs.

What is multi-tenant architecture? And why was it so useful for Atlassian?

What is a multi-tenant architecture?

A multi-tenant database architecture is a type of software architecture that allows for isolating tenants while letting them use the same infrastructure, database, or computing resources. Although the tenants share the same software, they know nothing about each other, they can’t access someone else’s data, and their own data is fully confidential.

While the level of access for each tenant may differ, the functionality may differ too. In this way, each tenant may set up custom functionality and use the same app with different features.

Long story short, Atlassian started to provide the same cloud-based app to all its users, and a single computing node served all customers. Tenants were isolated, but at the same time they used the same app, just like they continue doing to this day.

What are examples of SaaS apps using a multi-tenant architecture?

A multi-tenant data architecture is used in cloud computing for developing SaaS, PaaS, and IaaS products. You may already use some multi-tenant apps:

• Cloud storage services like Google Drive and Dropbox
• Communication apps like Slack and Zoom
• Task management apps like Jira and Trello
• Marketing software like HubSpot

This is far from a complete list of enterprise and startup SaaS companies. According to the Healthcare Information and Management Systems Society, in the US, 67% of IT healthcare organizations employ software as a service in their operations. Natural Resources Canada has also migrated petabytes of geospatial data to the cloud, implementing cloud multi-tenant architecture principles and specific AWS tools.

Single-tenant vs multi-tenant SaaS architecture: specifics and details you should know

If you want to offer your SaaS product to multiple users, you need to choose either a single-tenant or multi-tenant architectural model.

Single tenancy doesn’t mean your app will be used by just one single user; it just means that one entity of your app will be used by one user.

Meanwhile, with a multi-tenant app, a single version of the app will be used by multiple tenants.

Now, let’s dive deeper. What’s the difference between the concepts behind single-tenant and multi-tenant apps?

Single tenancy model — a rustic cottage with maximum isolation

According to the single tenancy model, all customers, users, or organizations use a separate instance of the same application. One of the main specifics of this model is full isolation: everyone has their own app, database, resources, and entire infrastructure.

Data is stored in separate cells, so no tenants can access, view, or somehow manage other tenants’ data.

A single-tenant architecture lays the perfect grounds for fully customizable and private software environments. Customers may choose whether and when to update the app, and can do it manually.

A single-tenant app is like a cottage in the woods. You and your family use it entirely for your own purposes. You have no neighbors, and you decide to do renovations when you have enough time and money. If the roof leaks after a summer storm, there’s no one to fix the issue for you.

Let’s take a closer look at the specifics of a single-tenant architecture.

Full control

If your app is based on the single-tenant model, you can integrate any third-party services as long as a development team finds it possible to add them to your app. You can upgrade your app anytime you need and customize it in the way you want.

Infrastructure safety

A single-tenant architecture means that users have isolated databases, exclusive access to their backups, and dedicated servers. Security best practices enhanced with role-based access and multi-factor authentication can make a single-tenant app almost unhackable.

User onboarding and app maintenance

The challenges for a SaaS app founder come with user onboarding, as you need to create an entire app infrastructure around users’ needs. Each user requires a separate onboarding process. They need to be guided through the entire setup process, and you may need to hire dedicated support specialists to respond to their inquiries.

Cost to develop a website and time to market

Designing a single-tenant architecture may be relatively simple for an experienced software engineer. It may take from several weeks to several months to create a single-tenant app, get people to use it, and validate your idea.

However, in the future, as new users join your single-tenant app, you may notice problems with deployments, slower app performance, scaling issues, and time-consuming user onboarding. Thus, you may need to migrate to a multi-tenancy, just like Atlassian did.

Time-consuming onboarding combined with individual approaches, scalability challenges, and multiple upgrades for multiple apps may require more financial investments than multi-tenant app in the long run. Still, a single-tenant architecture may be the right choice for early stage startups.

Multi-tenancy model: a classy apartment overlooking the Brooklyn Bridge with noisy neighbors

Tenants in a multi-tenant cloud architecture use the same computing resources. Just like tenants that rent apartments in a residential building, these users rent an app by paying a subscription fee for its use.

Apartment security depends on the security services a landlord provides.

App security is based on the isolation strategy the development team implements.

What about the rest of the features?

Painless upgrades and maintenance

Migrating to another technology stack, fixing bugs, carrying out planned upgrades, and releasing new product versions shouldn’t be an issue in a multi-tenancy, as a vendor makes these changes simultaneously for all tenants. At the same time, it’s rather convenient for tenants, as there’s no need to manually download and configure updates.

Load balancing

In a single-tenant architecture, as tenants need more resources, the vendor should provide more storage and capacity and increase the subscription fee. All of this is done manually depending on a certain tenant’s needs. Multi-tenancy allows for balancing the load: with a certain amount of available resources, data is allocated between databases and servers in an optimized way. Some tenants use more and pay more, others use less and pay less, while the total amount of available resources is fixed.

Scalability

Typically, multi-tenant applications consist of default functionality and resources available for all users in addition to premium features and extra storage that users can access by paying a higher subscription fee.

In this way, users can easily scale their apps and add and remove features from their subscription plans, while you as the software provider won’t need to invest your time in extending functionality or adjusting resources for particular needs.

Scalability is the strength of the multi-tenancy model. Compared to the single-tenant model, it’s easier to extend an app, add features, or remove features and effectively manipulate resources.

Investments and long-run potential

A multi-tenancy model requires investments. Compared to a single-tenant architecture, multi-tenancy is a more complex solution that requires more time, financial resources, and engineering effort.

Multi-tenancy requires a deep understanding of AWS or similar cloud solutions as well as experience with designing complex applications with multi-level access.

Typically, multi-tenancy is the choice of enterprises and companies who have already ensured their products’ viability and are about to scale rapidly.

Seven key differences between single-tenant and multi-tenant models

For your convenience, we’ve collected seven main differences between a single-tenant and a multi-tenant model in a table:

Single-tenant vs multi-tenant architecture: more things to keep in mind

Above, we likened a single-tenant architecture to a picturesque rural cottage and a multi-tenant architecture to a gorgeous NYC apartment. But at the same time, single-tenancy may be like a run-down barn, and multi-tenancy may look like a shared room in the cheapest hostel in Rio.

The quality, security, level of isolation, simplicity, design, and UX of your app, either single-tenant or multi-tenant, fully depends on the development team. Working with software development professionals is the way to provide your potential tenants with error-free solutions, a positive experience, and functionality they like and are willing to pay for.

So, if you want to lease a stylish apartment instead of a room in a favela (i.e. if you want to provide value and demonstrate quality to your users), choose a cloud service provider and a development vendor wisely and focus on long-term cooperation with IT experts.

Migrating from a single-tenant to a multi-tenant model: Whitelance case

As we’ve mentioned, if you run a single-tenant app, there’s a possibility you may need to migrate to a multi-tenant architecture as your user base grows and the app scales.

The founders of Whitelance, a white-label marketplace app, came to us with this need.

Having established a successful web platform, the Whitelance founders decided to release a white-label solution. That’s when a multi-tenant approach came into play.

Our skilled AWS architect together with an entire team of backend engineers looked under the app’s hood, clarified how every component of the app worked, rebuilt the app’s structure, and developed its parts from scratch to enable multi-tenancy.

Tenants can now access a customized front end and individual database while sharing the app’s back end.

What did we use for that?

As you can see, migration from a single-tenant to a multi-tenant app is possible, but there are several things to keep in mind:

• You may need a skilled engineering team experienced in multi-tenancy, and you need to be sure they’re not going to break the existing application.
• You may need to invest extra resources, as migration may be a complex and time-consuming process.

Meanwhile, if you build a multi-tenant app from scratch, it eliminates future scalability issues; you won’t need to rewrite the entire web app architecture and migrate somewhere else.

How to choose the right architectural model

A multi-tenant architecture is almost synonymous with a SaaS product. But is it really something you should go with?

Most leading cloud service providers deliver most of their offerings—everything other than dedicated hosting service—based on the multi-tenant model, which allows providers to maximize utilization of their data center hardware and infrastructure and, consequently, offer cloud services to customers for the lowest possible costs.

— IBM Cloud

The choice of architectural model is based on two decisions.

• Technical decision — Is it feasible to implement a multi-tenant model in your product?
• Commercial decision — Is there a real business need to implement a multi-tenant approach?

Even though it may seem like multi-tenancy is a perfect cost-effective approach, as well as one of the SaaS trends, you may still need to consult with a tech professional and business analyst to make the final decision.

To choose the right model, answer these questions:

• Do you have an existing business or an MVP?
• What are your business goals?
• Have you defined the business metrics that will play a crucial part in your success?
• What data privacy regulations should you comply with?
• Do you plan to scale rapidly?
• Do you have a product roadmap?
• Do you plan frequent releases?
• Which tenancy model may be more attractive for your future customers and why?
• How many tenants do you expect to use your app?
• Would you like to fully isolate a database, offer advanced backups, or provide exceptional restoration functionality to premium clients?
• How big is your operational team? Do you expect to have enough time for manual infrastructure management, monitoring, and performance management?

Typically, the app’s architecture has three main layers:

• Presentation layer visible to your customers
• Application layer, or app’s back end, which defines core business logic and handles critical functionality
• Data layer that collects, manages, and processes customer data

When deciding on the tenancy model, you may pay close attention to the data layer, as it’s responsible for data security and customer isolation, and see the application layer as a single entity.

Let’s refocus and think about the application layer.

What if you could cut it into pieces and offer each customer a different app? The database layer would remain shared and untouchable, while functionality for each tenant might change.

At this step, align your business objectives with solutions of how to implement multi-tenant architecture.

Do your tenants demand exceptional security and full data isolation?

Is there a necessity to provide more customization for tenants?

Here’s a handy tip from Microsoft Azure:

If you expect that your business is only going to have a few customers, it might be worth considering to have single-tenant resources that are dedicated to each customer. Similarly, if your customers’ isolation requirements are high, a single-tenant infrastructure might be appropriate.

Still, you may want to engage a business analyst and a software architect in a discussion to choose what is best for you and your SaaS product.

If there’s a lack of expertise in architecture development in your team, you may choose to outsource web development to experienced multi-tenancy specialists.

In conclusion: which architecture is better for your app?

There is no one-size-fits-all answer to the question of which tenancy model is better. Actually, neither is better or worse. They may fit different needs and accommodate different functionality. They are built in different ways, but if they’re built correctly, you can move from one to the other at any time.

So what are your needs?

• Fast launch and idea validation

At the initial stages of startup development, timing may be the decisive success factor. You need to act fast, test your idea swiftly, and either improve it or pivot and discover other ways to meet users’ demands.

To launch an MVP of a SaaS app quickly, choose a single-tenant architecture. It’s faster and more affordable in comparison to multi-tenant development. This means it may be the best choice for bootstrapped or early stage startups.

A single-tenant app is a solution for a fast result.

• No rush and full-feature app development as the priority

If you’re the founder of a successful startup with enough funds for high-quality, complex solution development and upgrades, take a closer look at multi-tenancy.

A multi-tenant architecture is also a good choice for enterprise SaaS and white-label applications.

Although it’s more expensive to develop than a single-tenant development, a multi-tenant architecture allows you to build a scalable solution from scratch and cut maintenance, customization, and user onboarding costs.

A multi-tenant app is your investment in the future.

To make the right choice, start slow and implement one of the architectural models in your technical proof of concept to make sure it can work correctly by measuring performance indicators and analyzing critical metrics. Then proceed with MVP development to let real tenants test your SaaS app. This data-driven approach may help you optimize development resources and cater to users’ needs.