Multitenant containers: system and tenant databases

When people say "the HANA database of CMQ", they usually mean one specific thing: a tenant database inside an SAP HANA system. Since SAP HANA 2.0 SPS 01, every SAP HANA system is installed in multiple-container mode. Knowing the difference between the system and its databases avoids confusion in incidents, backup discussions and refresh plans.

The system database

The system database exists exactly once per SAP HANA system. It keeps landscape information (which tenants exist and where they run), holds system-wide configuration and provides system-wide monitoring. It runs the name server. It is not where business data lives: it does not support full SQL, cannot scale out, and can see monitoring data from tenants but not their content. Administrators connect to it to create, start, stop, rename and drop tenants, which requires the system privilege DATABASE ADMIN.

Tenant databases

A tenant database is a full database: it has its own index server that stores and persists its data, its own users and catalog, its own parameter settings, and its own backups. Tenants are isolated from each other by default; users of one tenant cannot connect to another unless cross-database access is explicitly enabled. All tenants of a system share the same SAP HANA software version and the same high-availability and disaster-recovery setup, so patching the SAP HANA system patches every tenant at once.

Isolation can be tightened. By default all database processes run under the operating-system user <sid>adm. In high isolation mode, each tenant's processes run under their own operating-system user and group, so even <sid>adm cannot read a tenant's data volumes, log volumes or backups. Whether a platform needs that depends on how many parties share it.

How it looks in an SAP S/4HANA landscape

An SAP S/4HANA ABAP system connects to one tenant database. A common pattern is one SAP HANA system per SAP system, with a single tenant whose name matches the ABAP SID, but other layouts exist, so always check your own landscape documentation rather than assuming. Ports follow the instance number: SAP's training material gives 3<nn>13 as the SQL port of the system database and 3<nn>15 as the SQL port of the initial tenant, where <nn> is the SAP HANA instance number.

Versions: SPS and revisions

Because all tenants share one software version, it pays to know how that version is named. SAP HANA 2.0 ships as support package stacks (SPS) with numbered revisions inside each stack, written like 2.00.08x. SPS08 reached customers in November 2024, and SAP S/4HANA 2025 requires an SPS08 revision at or above the minimum named in its release information note and the Product Availability Matrix. SAP's revision and maintenance strategy (SAP Note 2378962) moved, from SPS08, to a new stack roughly every two years with a longer maintenance period per stack, so most change during the life of Contoso's systems comes as SPS08 revisions. The SAP HANA cockpit and the M_DATABASE view show the running version. Treat every revision change as a regression trigger, update CMQ before CMP, and confirm the revision is listed for your SAP S/4HANA release before anyone schedules it.