Skip to Content
Technical Articles
Author's profile photo Raja Prasad Gupta

Fundamentals of Multitenancy in SAP BTP


Multitenancy is one of the important architectural concept in cloud. In SAP BTP, we can develop and run multitenant applications, and share them with multiple customers simultaneously.


This blog is targeted mainly for SAP developers, architects and consultants who wants to become expert in multitenancy concepts and build a full-stack multitenant business application.

After finishing this blog, you will have a crystal-clear understanding of multitenancy in SAP BTP. Further, you will also find resources to help you build, deploy, and run multitenant apps in SAP BTP.


Note: If you are new to SAP BTP and looking for a simple explanation of what it is and what problem it solves, see Explaining SAP Business Technology Platform (SAP BTP) to a Beginner


let’s get started!

What is Multitenancy?

Multi-tenancy is an architecture in which:

  • A single instance of an application serves multiple customers
  • Each customer is called a tenant
  • Multiple customers (tenants) use the same computing resources – physically integrated but logically separated
  • Even though customers share resources, customers aren’t aware of each other, and their data is kept totally separate

An Analogy of Multitenancy from Real-life

To understand multitenancy, let’s take a real-life analogy. Think how a bank works.

  • Multiple people can store their money in one bank
  • Their assets are separate even though they’re stored in the same place
  • Customers of the bank don’t interact with each other, don’t have access to other customers’ money, and aren’t even aware of each other


Similarly, in multitenancy, customers use the same application instance, share resources – while keeping their data separate and secure.

Benefits of Multitenancy

Following are the major benefits of multitenancy.

Save Money

Multitenant architecture enables sharing of services, databases, resources, and applications. Hence a cloud vendor can offer their solution to many customers at a much lower cost than if each customer required their own dedicated infrastructure.

More flexibility

If a customer invests in its own infrastructure, it might reach capacity during times of high demand or sit idle during times of slow demand. In multitenancy, resources are shared among customers. Hence as a customer, you can access extra capacity when you need it, and not pay for it when you don’t.

Easy/Efficient Maintenance

Multitenancy reduces the need for individual customers to handle updates and maintenance. The vendor takes care of maintaining and updating the multitenant application, managing infrastructure, thus removing additional overhead from customers.


When You may Prefer Single-tenant Architecture

In some scenarios, you may have to go with single-tenant architecture despite all the benefits from multitenancy.

Some organizations may not be able to store data within shared infrastructure, no matter how secure it is, due to regulatory requirements.

Additionally, security problems or corrupted data from one tenant could spread to other tenants on the same infrastructure. Although in practice these risks are extremely rare and shouldn’t occur if the cloud vendor has configured their infrastructure correctly.


Multitenancy in SAP BTP

SAP Business Technology Platform provides out-of-the-box support for multitenancy. There are services and frameworks which helps us build a multitenant application with minimal effort.

Let’s first see how a single-tenant application differs from multitenant application in BTP.


Use case

An SAP Partner has built an application on SAP BTP. The partner needs to sell this solution to their customers. In this case, SAP Partner is Application Provider. The customer who buys application from the partner is referred as Application Consumer.


Scenario 1: Single-tenant App in BTP

The Application Provider

  • Develops the app in a BTP subaccount (say developer subaccount)
  • Sells the licenses to customer and provides the deployable artifacts to customer


The Application Consumer

  • Procures the deployable artifacts
  • Deploys app in their BTP subaccount
  • Consumes application
  • Pays for BTP resources to SAP


In the single-tenant scenario:

  • It’s customer’s responsibility to deploy and maintain the application on BTP.
  • Each customer has its own BTP resources.
  • There is no resource sharing among customers.


Scenario 2: Multitenant App in BTP


The Application Provider

  • Develops the app in a BTP subaccount
  • Publishes the app to consumers
  • Pays for BTP resources to SAP


The Application Consumer

  • Procures the license to use app
  • Subscribe to the app from a consumer subaccount
  • Consumes the app


In the multitenancy scenario:

  • It’s application provider’s responsibility to deploy and maintain the application on BTP.
  • Application provider pays for the BTP resources.
  • Customers only subscribe and use the app.
  • Resources are shared among customers, but each customer’s data is separated securely


Below image may help you to understand the relationship between application provider and application consumer.


How does Application Consumer Access Multitenant App?

To use a multitenant application on SAP BTP, the application provider must ensure that each consumer:

  • Has a dedicated subaccount in the application provider’s global account.
  • Subscribes to the application using either the SAP BTP cockpit, SAP BTP command-line interface, or a dedicated REST API.
  • Receives a dedicated URL so that its business users can access the application.


The resources consumed by multitenant app in SAP BTP, for example compute units, storage, services are managed by the application providers. The cost of these resources and those of application consumers are billed to provider of the multitenant application.


Let’s have a glimpse of how this works.

I have created a multitenant app called “My Multitenant App”. This app is deployed in a BTP subaccount called “Provider Account” as shown below.


In the same Global Account, there is another subaccount called “Consumer1”.  If we go to Service Marketplace of Consumer1 subaccount, we can view the multitenant app published as a Tile.


To subscribe this app from Consumer1, click on the Create button as shown in image below.

Finally, we will have the subscription created and a unique URL provided to access this multitenant app. Now we can access the subscribed app from Consumer1 using this subscription as shown below.

SAP SaaS Provisioning service

SAP SaaS Provisioning service is the most important SAP BTP service for multitenancy.

Once the multitenant app is developed, application provider needs to make it available for consumer by publishing it.

In the example mentioned before, the multitenant app is available for subscription in Consumer1 subaccount’s Service Marketplace. This is done by using SAP SaaS Provisioning service.


Important points regarding SAP SaaS Provisioning service:

  • SAP SaaS Provisioning service acts as a registry and helps us to publish the multitenant app to consumers.
  • It also enables us to automate the subscription and unsubscription process.
  • The service also maintains a list of all dependencies and subscriptions of an application.


To register the multitenant app with the SaaS Provisioning service, we need to:

  • Create a service instance of the SaaS Provisioning service (aka saas_registry)
  • And bind it to the application

Below image shows an example code snippet on how to register multitenant app with SaaS Provisioning service in case of a CAP Multi-Target Application.

 Note: At this point, you may skip this coding details if seems too complex.


BTP Components/Services Required to Run a Multitenant App

Let’s briefly look into the components that are needed for a multitenant app to run in the Cloud Foundry environment in SAP BTP.

Provider Subaccount

SAP BTP subaccount where multitenant application is deployed.

Consumer Subaccount

SAP BTP subaccount from where we subscribe and use a multitenant application.

The Application Provider (the owner of the multitenant application) owns the global account and the provider and consumer subaccounts.

SAP SaaS Provisioning service

SAP SaaS Provisioning service is where Application Provider registers the multitenant app to publish it for consumers. This service enables us to automate the subscription process.

XSUAA service

The XSUAA service is used for authentication and authorization.

App Router

The application uses tenant-aware App Router service, which is the single point-of-entry for the applications.


Each multitenant application must deploy its own application router, and the application router handles requests of all tenants to the application.


Tenant Onboarding

When a consumer subscribes the multitenant application, the application must be notified that there is a new consumer.

As part of the application subscription, SAP SaaS Provisioning service provides two callbacks:


This provides dependencies to multitenant reuse services


This allows applications to perform the tenant setup in the application. The implementation depends on the approach to separation that you use for your application.


These callbacks help to achieve the tenant onboarding. For example, whenever a consumer subscribes an application, this callback allows the application to perform tenant-specific onboarding steps, e.g. creating a new HANA schema.


The tenant onboarding call flow works as follows:

  1. From the consumers subaccount the subscription is initiated.
  2. Recursively, getDependencies callback is called, first for the application and then for all its dependent services and their dependencies.
  3. After the complete dependency tree is built, the onSubscription callback is called.
  4. After the tenant-specific persistence, if at all needed, and configuration is created, the application returns the tenant-specific application URL

Tenant Offboarding

When a consumer unsubscribes the multitenant application, there must be a notification sent to the application, which allows you to take care of data deletion and other clean-up activities.


Same onSubscription callback is triggered for offboarding, but with the HTTP “DELETE” method to indicate that this tenant must be removed. Once again, the offboarding call is also provided to all the dependent multitenant services that are used by your application.


Tenant Identification by Multitenant App

In SAP BTP, every subaccount has a subdomain and a tenant ID as shown below.


The Subdomain is unique across all subaccounts in the same region.

The Tenant ID is an UUID (Universal Unique Identifier).

When a consumer subaccount subscribes the application, it gets its own URL that follows the below pattern.



Below image shows an example.

For multitenant application, the App Router determines the tenant-specific subdomain out of the URL and then forwards the authentication request to the tenant XSUAA service.

This determination is done by using a regular expression defined in the environment variable TENANT_HOST_PATTERN.


What is the significance of TENANT_HOST_PATTERN?


  • used in mta.yml file (or manifest.yml file)
  • used by App Router
  • to identify the tenant that is accessing the application

Each consumer accesses the SaaS Application through a unique URL. To ensure that these requests come to the target application, we define a tenant host pattern for our app router app.


TENANT_HOST_PATTERN: ^(.*)-${space}${app-name}.${default-domain}


Actual Route for consumer account would be like:




Regex placeholder is required because numerous consumer accounts can subscribe to the application and their subdomain is not known beforehand.


We can use, more specific or more open regex patter also, but not suggested. Below examples would work but is not recommended.






Tenant mode configuration in xs-security.json

To use a multitenant application router, we must have a shared UAA service. Hence, for multitenant apps, we configure the tenant mode in the xs-security.json as “shared”.


    "xsappname": "myapp-multitenant",
    "tenant-mode": "shared",


Data Separation in Multitenancy

There are different ways to achieve data separation in multitenancy. I will use SAP HANA Cloud as an example to explain, however the concepts remain same for any other database.


There are mainly 3 ways to achieve data separation.

  1. Discriminator Column
  2. Schema Separation
  3. Database Instance Separation

Discriminator Column

  • Tables are shared between tenants, so you have one set of tables for the application
  • Simple and straightforward to define
  • A column in each table which effectively identifies the tenant id
  • At the application level you need to filter on tenant id for every CRUD operation. For example, when you are implementing INSERT or SELECT, you need to have a WHERE clause on TENANT ID.
  • Doesn’t cost that much because you’re just using a single schema potentially in a single database instance
  • High risk because it’s very easy for you to make a mistake


Schema Separation

  • A dedicated schema or if it’s HANA an HDI Container.
  • Recommended approach by sap.
  • Very flexible – you can have a single database instance, for example a single HANA Cloud instance. Each tenant will get their own dedicated HDI Container. So effective their own schema and tables.
  • Can easily backup individual schemes or HDI containers.
  • In terms of cost, you’re still working with a single HANA instance or a single database instance so not much effect on cost.


Database Instance Separation

  • Technically, this is true data separation. A completely dedicated HANA cloud instance or whatever database you want to work with instance for each tenant.
  • More expensive.
  • You get a complete level of separation
  • Straightforward and simple backups because you’re taking the entire database instance each time.

There’s no strict right or wrong way, it’s just a question of finding what’s the most suitable and appropriate way for your application.


I believe now you have got clear understanding of multitenancy in SAP BTP.


If you have any queries, let me know in comment or get in touch with me at LinkedIn!


What’s next?

Check the below materials to build your own multitenant applications.

Develop Multitenant Applications in the Cloud Foundry Environment

BTP Multitenant: SAP HANA Academy

Develop and Register Multitenant Application in the SAP BTP Kyma Runtime


If you are looking for a end-to-end guide on SAP BTP and it’s core capabilities, you may look into SAP’s free learning content on SAP BTP. It is made for both integration designers and extension developers from all levels of expertise and will help you stay up to date with the latest SAP BTP innovations.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Jana Subramanian
      Jana Subramanian

      Hi Raja,

      Very informative blog and great work.



      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Thanks Jana Subramanian. Glad you liked it. 🙂

      Author's profile photo Gregor Wolf
      Gregor Wolf

      Hi Raja,

      thank you for sharing this. I hope that the issues addressed by Mustafa Bensan in his blog post Is SAP Business Technology Platform Ready for Developing Industry Cloud SaaS Applications? and the follow up comments will get a high priority.

      Best Regards

      Author's profile photo Ashwani Goyal
      Ashwani Goyal

      This blog is well written and highly informative. Kudos to Raja Prasad Gupta . +1 to Gregor's comments too.

      Author's profile photo Vikram Singh Dasila
      Vikram Singh Dasila

      Hi Raja,

      This blog is very informative and concept of Multitenancy is explained very nicely.




      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Vikram Singh Dasila Thanks for the feedback!

      Author's profile photo Ashish Jain
      Ashish Jain

      Hi Raja Prasad Gupta

      Thanks for this awesome blog, very well written which probably a layman can also understand. Have one question currently in our implementation we use "Discriminator Column" and we intend to migrate to "Schema Separation". Are there any blogs which provides details on Schema Separation approach?



      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Ashish Jain

      Hopefully, this HANA Academy Video will help -




      Author's profile photo Ashish Jain
      Ashish Jain

      Great thanks for this reference.

      Author's profile photo Helmut Tammen
      Helmut Tammen

      Hi Raja,

      thanks for this great summary.

      BR Helmut

      Author's profile photo Pawan Kumar
      Pawan Kumar

      Hi Raja Prasad Gupta

      Great blog, very well articulated!!



      Author's profile photo Igor Rivchin
      Igor Rivchin

      Thanks for that easy understandable blog.
      is there any tutorial or blog on

      • how to monitor the consumption to create a full representative bill for the customers?
      • how to handle different identity providers? For example for customers that are not in out azureAD and not inside our IAS.

      and again! Great stuff!

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Igor Rivchin ,

      For your 1st question, Subscription Management Dashboard  and Monitoring Usage and Consumption Costs in Your Global Account would help.


      For Identity Provider configurations, check Establish Trust and Federation with Any SAML Identity Provider. Check more options on the left side index of this help document as well.



      Raja Gupta

      Author's profile photo Hamza Mujeeb
      Hamza Mujeeb

      How long did it take you to write this blog?

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      approx 2 days. The main time consuming part was simplifying the topic in layman's term 🙂

      Author's profile photo Pavan Chittanpalli Vasudevan
      Pavan Chittanpalli Vasudevan

      Very well articulated Raja and great blog.

      Author's profile photo Velayutham Augustheesan
      Velayutham Augustheesan

      Hi Raja

      another great blog from you. I am able to fully get the fundamentals of Mufti-tenancy in BTP. another complex topic demystified

      Thanks and keep blogging.


      Author's profile photo Rudolf Remsik
      Rudolf Remsik

      Hi Raja Prasad Gupta

      Very informative blog and great reading.

      I understand each Consumer has a dedicated subaccount in the application Provider’s global account.
      Once the multitenant app is developed, application Provider needs to make it available for Consumer by publishing it.

      From the point of view of SAP developer:

      • Who is the Consumer? Is it a customer’s user or customer’s partner or some customer’s administrator? Who could it be?
      • As Consumer has dedicated subaccount, does it mean a Consumer user has access to the dedicated subaccount in BTP Cockpit?
      • Can Consumer see other Consumer’s subaccounts within Provider’s global account?
      • What ‘Role Collection’ Consumer user should have to setup Trust with his/her Identity Provider (IdP), and to subscribe to SAP SaaS Provisioning service instance?
      • How Consumer’s subaccount is sold to the Customer by SAP company, so he/she can go there and subscribe to the SAP SaaS Provisioning service instance?
      • Is there some additional process of multitenant app commercialization needed?

      Thank you.

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Rudolf Remsik,

      We need to understand this from both technical and business perspective.
      From technical perspective - To run a multitenant app, you need a global account and multiple subaccounts inside that. You can deploy the multitenant app in one of the subaccount (let's call it provider subaccount). From other subaccounts (let's call them consumer subaccounts), you can just subscribe this app and consume it. For each subaccounts, you can manage it's users and roles. This is shown in below figure.

      From business perspective, there can be different scenarios. One of the scenarios can be as below.
      An SAP Partner (say XYZ Ltd.) is planning to build and sell a solution to it's customers. XYZ Ltd. bought SAP BTP license from SAP and got a Global account with all the resources. They further created various subaccounts under the same global account. In one of their subaccount (let's call it provider account) they deployed a multitenant app.

      How they market and sell their solution, is a separate topic. Let's assume that they published their solution in SAP Store and sold their solution to 2 customers - customer_1 and customer_2. Once the customers pay license fee, they need the solution. Here is how XYZ Ltd. can provide them the solution:

      1. XYZ Ltd. will create a subaccount (say consumer_1) for customer_1 under their global account.
      2. XYZ Ltd. will subscribe the multitenant app in consumer_1 subaccount.
      3. XYZ Ltd. will add all the business users of customer_1 in an Identity Provider configured with consumer_1.
      4. XYZ Ltd. assign all the role collection required to business users of customer_1.
      5. Finally, XYZ Ltd. share the URL of subscribed app with customer_1.
      Similarly, they do it for customer_2.

      Few points to note:
      In the above example, I simplified few things. In real scenario, there might be additional steps required. For example, a customer may want access to their consumer subaccount and manage their own user. In that case, XYZ Ltd. may give access of consumer_1 subaccount to customer_1 and allow them to handle their own IAS tenant. All these depends on agreements between partner and customer.


      Feel free to revert in case you still have some doubts.

      Author's profile photo Frank Li
      Frank Li

      Hi Raja Prasad Gupta,

      So clear, thanks a lot for your effort and amazing blog. Currently, this is the best blog for the multitenant BTP APP from my point of view. Contains so much useful information and relevant links.

      Author's profile photo Kailash Joshi
      Kailash Joshi

      Thank you Raja for the very informative blog.

      Author's profile photo Jay Adnure
      Jay Adnure

      Thank you for sharing this blog.

      Author's profile photo Sreehari V Pillai
      Sreehari V Pillai

      Thanks a lot Raja. This is informative and helpful to understand for beginners as well . I have a quick one.

      do you have a blog / reference explaining how to implement 2 & 3 in the diagram ?

      I am looking for a setup where a tenant who subscribed to an app has their own HDI Container ( 2 ) or even a separate Hana Cloud instance. How to implement the router and getDependencies() method  ?

      ( if you think its worth posting a separate question ,I would do that )



      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Sreehari V Pillai ,

      For option 2, please refer to the video series -


      You may also look into below blogs to find sample code and full examples.



      Author's profile photo Sreehari V Pillai
      Sreehari V Pillai

      thanks Raja . I must have gone through the comment section before asking for this - 🙂

      I am going through this rn.


      Author's profile photo Shasank Gupta
      Shasank Gupta

      HI Raja,


      Can you also explain how to setup subaccounts based on three-tier architecture provided my S4Hana is on three tier. But we only have 2 tenants for Integration Suite.



      Shasank Gupta