Mandantenfähigkeit

What is multi-tenancy?

Multi-tenancy describes an architectural feature of software in which a single instance of a system can operate multiple independent organizational units – the tenants – in parallel, without their data or processes affecting one another. A tenant can be a business division, a legally independent company, a location, or, in contract logistics, an external customer. The physical infrastructure (servers, database, application) is shared, while strict separation is maintained at the logical level.

In intralogistics, multi-tenancy is particularly relevant for warehouse management systems (WMS), warehouse management software, and ERP systems. Contract logistics service providers, for example, operate the same warehouse for multiple customers and therefore require a system that cleanly separates inventory, orders, documents, and key performance indicators by client. Large corporations with multiple subsidiaries also benefit, as they can operate a central platform without having to forgo tenant-specific processes.

How does multi-tenancy work in practice?

Vendors implement multi-tenancy using various technical approaches. Common methods include:

• Separate database schemas per tenant within a single database instance – high data isolation, but greater administrative overhead.
• Shared schema with a tenant ID as a distinguishing feature in each table – efficient, but requires careful permission management to prevent data leaks.
• Separate database instances per tenant – maximum isolation, highest resource consumption.

Regardless of the technical model, permission concepts, workflows, document layouts, billing logic, and reporting structures must be configurable per tenant. Updates or system changes must be tested in a way that accounts for all affected tenants – which significantly increases testing effort.

What matters when making a selection?

When evaluating multi-tenant systems, you should specifically examine the following aspects:

• Data isolation: How strict are the technical boundaries between tenants – is a logical separation sufficient, or is physical separation required, for example due to data protection or compliance requirements?
• Process flexibility: Can workflows, forms, and rules be individually configured per tenant without destabilizing the shared core?
• Operations and updates: How are system updates deployed – do they roll out automatically for all tenants, or can the timing and scope be controlled per tenant?
• Scalability: How does performance behave as the number of tenants or the volume of data grows?
• Distinction from multi-warehouse capability: Multi-tenancy separates organizational units; multi-warehouse capability separates physical locations. Both can occur in combination, but are conceptually distinct.

Whether a system is truly multi-tenant or merely manages multiple user accounts within a shared environment depends on the vendor and should be concretely demonstrated as part of a tender process or proof of concept.