Explain HANA Multitenant Database Containers (MDC) in SAP

47 / 65

HANA DBintermediate

HANA Multitenant Database Containers (MDC)

Running multiple isolated tenant databases on one shared HANA system infrastructure using Multitenant Database Containers.

MDC is a foundational HANA administration topic that comes up whenever an interview touches system landscape design or HANA-as-a-service scenarios, and interviewers ask about it to confirm a candidate understands the modern standard HANA deployment model rather than the older single-container architecture that predates it.

MDC is like a large apartment building where each unit (tenant database) has its own locked door, its own utilities meter, and its own lease terms, while all units share the same building foundation, plumbing infrastructure, and physical address (the underlying HANA installation) - far more efficient than building a separate standalone house for every tenant, while still keeping each unit's affairs fully private from its neighbors.

Key Concepts

A HANA system consists of exactly one system database (used purely for system-wide administration - creating/dropping tenants, managing system-wide configuration - and never holding actual application data) plus one or more tenant databases, each of which is fully isolated with its own set of schemas, users, and even its own backup/restore and recovery point capability, while all tenants share the same underlying HANA installation, memory pool (governed by configurable per-tenant memory limits), and host infrastructure. This isolation-with-shared-infrastructure model is precisely what makes MDC suitable for consolidating multiple SAP systems (e.g., separate DEV, QAS, and a couple of smaller side-by-side application databases) onto one physical HANA installation rather than requiring completely separate hardware/installations for each, without those systems' data or user administration bleeding into each other.

MDC has actually been the mandatory default HANA deployment topology since HANA 2.0 - the older single-container mode (one database per system, no tenant separation) is effectively legacy at this point, so any new HANA installation is multitenant by design even if it currently only has one tenant database provisioned; a candidate should know this is the standard architecture now rather than an optional advanced feature. Managing tenants (creating, starting/stopping, resource-limiting) is done through HANA cockpit or SQL commands against the system database, and each tenant database is addressed on the network via its own distinct SQL port, letting applications connect to a specific tenant precisely as if it were a fully separate HANA instance.

A senior-level answer covers resource governance specifics - configuring per-tenant memory allocation limits (ALTER SYSTEM ALTER CONFIGURATION) so one noisy or oversized tenant workload can't starve other tenants sharing the same physical HANA installation of memory or CPU - and mentions tenant-level backup/recovery granularity (each tenant can be backed up and restored to a specific point in time independently of other tenants on the same system), which is a meaningful operational advantage over the pre-MDC single-container model where backup/recovery operated at the whole-system level only.

ALTER SYSTEM ALTER CONFIGURATION