What Is Multi-Tenant Architecture And How Does It Work

SaaS products are often associated with multitenancy or multi-tenant architecture. As the interest in the popularity and profitability of SaaS products increase, interest in multi-tenancy-related concepts is on the rise too.

What is 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 tips on choosing 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 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 and SaaS topics.

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 rapidly addressed those issues: they decided to take over the maintenance challenges and let customers access and enjoy the functionality.

To do this, they migrated their server products to the cloud, moving to a 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 where they provide their services. In the case of Atlassian, a tenant is a company or team that uses Atlassian products for their 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 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 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 to do to this day.

Multi-tenant architecture examples to consider

A multi-tenant data architecture is used in cloud computing for developing SaaS, PaaS, and IaaS products. Let’s consider such multi-tenant architecture examples:

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

This is far from a complete list of enterprises and startups that use software as a service business model. For example, Natural Resources Canada has migrated petabytes of geospatial data to the cloud, implementing multi-tenant cloud architecture principles and specific AWS tools.

Single-tenant vs multi-tenant 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 just one single user will use your app; it just means that one user will use one entity of your app.

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 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 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, your users can integrate any third-party services as long as their development team finds it possible to add them to the app. They can upgrade their app anytime they need and customize it in the way they 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. However, it may take several weeks to several months to create a single-tenant app MVP, 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 apps in the long run. That is why SaaS multi-tenant architecture is often considered as one of the ways for software development cost reduction. Still, a single-tenant architecture may be the right choice for early-stage startups as it is easier and cheaper to design.

Proceed to read our article about project estimation techniques in software engineering to learn more about the topic.

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

In a multi-tenant environment, tenants 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.

The multi-tenancy model's strength is its scalability. 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 that 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:

Choosing between single- and multi-tenant architecture, you need to consider such risks in software development as security vulnerabilities and data breaches associated with implementing a multi-tenant software architecture, limited scalability, increased infrastructure costs, and potential vendor lock-in associated with single-tenant architecture.

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

Above, we likened single-tenant architecture to a picturesque rural cottage and multi-tenant architecture to a gorgeous NYC apartment. At the same time, a single-tenancy may be like a run-down barn, and a 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, but you need to be sure they won’t 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 something you should go with?

The choice of SaaS platform architecture 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 multi-tenancy may seem like a perfect cost-effective approach and one of the trends in SaaS, 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?

At this step, align your business objectives with solutions for 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:

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

If your team lacks expertise in architecture development, 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. Neither is better or worse. Everything depends on your particular SaaS platform development case. 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 SaaS product development lifecycle, 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 than multi-tenant development. This means it may be the best choice for bootstrapped or early-stage startups.

A single-tenant app is a solution that provides fast results.

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

If you’re the founder of one of the fastest-growing SaaS startups 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 ensure 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.