Skip to Content
Business Trends

SAP HANA Multitenant Database Containers

When deploying SAP HANA, efficient use of hardware resources is key to achieve better performance and scalability while reducing TCO.

Prior to SPS09, SAP HANA supported multiple schemas in one SAP HANA system and multiple SAP HANA systems on single SAP HANA virtualized hardware. With SPS09, SAP HANA added support for multiple tenant databases in one SAP HANA system for production use. We call this feature, “Multitenant database containers”.


SAP HANA system with multitenant database containers feature can contain multiple tenant databases. All tenant databases in the same system share the same system resources (memory and CPU Cores). However, each tenant database is fully isolated with its own database users, catalog, repository, persistence (data files and log files) and database services so that for example, you can run both SAP Business Suite and SAP Business Warehouse (BW) in one SAP HANA system.

With multitenant database containers, you can assign system resource limits (memory and CPU cores) to each tenant database so that higher workload on one tenant database cannot impact other tenant databases. You can also change the allocated resources at any time, based on changing needs of each tenant database. For example, if an SAP Business Suite and SAP BW run on one SAP HANA system, you can increase the resources for the SAP BW during month-ends when there is a need for more reports out of the SAP BW system. You also get the flexibility to backup and recover all tenant databases at once or single tenant database at a time. This means, by running multiple tenant databases in one SAP HANA system and managing them as one, you can lower capital expenditure with better utilization of system resources and operating expenditure with simplified database maintenance.

Another major benefit of multitenant database containers feature is that it simplifies development and deployment of secure, multi-tenant cloud-based applications. While it is possible to build cloud applications without a multi-tenant database, there are several advantages in using one. When you do not use a multi-tenant database, you typically opt for one of these three common approaches.

1) Store application data with customer ID (add “customer” column in all tables) and select/update data using customer ID.

Result: Complex database authorizations are required to implement security as all customers’ share same tables. One customer’s query can use too many database resources and negatively impact other customers’ performance.

2) Create a schema for each customer

Result: Better data security than the first approach but still require complex database authorizations as schemas in the system are accessible to all database users. Still one customer’s query can use too many database resources and negatively impact other customers’ performance.

3) Create a virtual instance of database, for each customer

Result: Secured. Virtualization causes additional overhead possibly negatively affecting performance.

If you instead use a multi-tenancy at database and create a tenant database for each customer, you archive a high-degree of security as in the virtualization scenario. Since multitenant database containers feature is built into the SAP HANA architecture, there is no virtualization layer overhead, giving multitenant database containers performance and scalability advantages.

That being said, virtualization may be of particular interest for companies following a software defined data center approach. Virtualization provides benefits such as moving productive instances from one hardware system to another and additional HA/DR capabilities. In addition, virtualization provides the ability to run multiple SAP HANA systems with different versions on a single hardware installation. You can use multiple tenant database containers feature in a virtualized SAP HANA system.

High level architecture of SAP HANA multitenant database containers:

SAP HANA system with multitenant database containers feature includes one system database and any number of tenant databases as shown in the following picture.

You use the system database to create, drop, start, stop tenant databases and perform database administration activities (backup/recovery, system replication) for all tenant databases at once.

In a scale out scenario, a tenant database can span across multiple SAP HANA nodes as shown in the following picture.


This means, the size of the tenant database is not limited by the size of a single SAP HANA node. While there is only one system database active at any given time, maximum redundancy is provided. In other words, as long as one SAP HANA node is operational, the system database will be operational.

In summary, multitenant database containers is a new SAP HANA feature introduced in SPS09 that enables you run multiple tenant databases in one SAP HANA system and manage them as one. This feature helps you lower capital expenditure, simplify database management and build multi-tenant cloud applications.

Following are some of the resources to learn more about multitenant database containers:

Please let me know if you have any questions.

You must be Logged on to comment or reply to a post.
  • Hi Saiprashanth,

    Thanks for sharing this information , I have question with regards to MDC.

    We have three separate standalone systems and we want to do DR for these systems, instead of having three separate servers can we have dr for these systems in one HANA appliance with MDC, meaning three tenant databases in one server?

    will there be any issue in replication???

  • Hi,

    You can not replicate a standalone to MDC, it is MDC to MDC and you can not only replicate only one tenant and not the rest - "all or nothing". To test DR, you will have to perform a take-over on the DR MDC and all tenants from Site A tenants will be now be available on Site B.

    Hope this clarifies.


  • HI Saiprashanth,
    thanks for information. Respect a scale out cerfied scenario, with multitenant feature, Could I provide a Business Suite Tenant, Business Warehouse Tenant and BPC Tenant in appliance with 4 CPU and 3TB ram. It's not clear if i need a 8CPU one.
    Thanks in advanced, David.

  • The article is really helpful understanding the multi tenancy in hana db. But now I am wondering about connecting to HANA db using SAP datasource class - DataSourceSAP which comes as part of ngdbc.jar. If I want to connect to a specific tenant database, I must use a database name and pass it to datasource object. Can you please help me figuring out which property of DataSourceSAP should be used?

    Many thanks !

  • Hi Saiprashanth,
    I'm planning my technical architecture for an ECC and BW landscape on HANA.
    I would like to use only 2 HANA Appliance and I’m planning to use the following MDC configuration:

    HANA Appliance 1 :
    ECC (Prod)+ BW (prod) -> 1 Hana system + 2 Tenant DB
    HANA Appliance 2 :
    ECC (Prod standby)+ BW (prod standby) + BW/ECC(DEV, Test) -> 1 Hana system + 6 Tenant DB

    I would like to know if I can activate HSR between the 2 appliance. In the “SAP HANA Tenant Databases - Operations Guide” I found the following:

    The usual SAP HANA system replication principles apply for tenant database systems.
    Before you begin preparing a replication strategy for an SAP HANA system, you should be aware of the following important points.
    ●SAP HANA systems can only be replicated as the whole system. This means that the system database and all tenant databases are part of the system replication. A takeover can only be performed as a whole system. A takeover on the level of a single tenant database is not possible.

    Based on what indicated above I should not be able to replicate the data form Appliance 2 to Appliance 1. Is this correct? Is it possible to define in the second HANA Appliance 2 HANA System like indicated below:

    HANA Appliance 1 :
    ECC (Prod)+ BW (prod) -> 1 Hana system + 2 Tenant DB
    HANA Appliance 2 :
    ECC (Prod standby)+ BW (prod standby) -> 1 Hana system + 2 Tenant DB
    BW/ECC(DEV, Test) -> 1 Hana system + 4 Tenant DB

    In this case I should be able to activate HSR only for PRD systems.