Multi-tenancy means that a single software application can serve multiple customers simultaneously – each with their own data and settings.

In a multi-tenant environment, all customers use the same application but only see their own data. This architecture is particularly popular with SaaS products.

The biggest benefit for you: reduced development and maintenance costs. Updates only need to be deployed once and are immediately available to all users. Your budget stays predictable while your software grows with each new customer.

What is multi-client capability?

Think of it like an office building: each company has their own office with their own key, but they share elevators, heating, and building management. Multi-tenant software works the same way: each customer (tenant) has their own secure space while sharing the technical infrastructure.

Each tenant has their own area with data, settings, and users. This allows you to run a customer portal or CRM system that serves many different companies simultaneously – without them knowing about each other.

What is multi-client capable software used for?

With multi-tenant software, you serve many customers with a single application. Each customer group works in their own protected space – completely separate from others.

This means that different customers can use the same software without their information being mixed together.

Which multi-tenant architecture is suitable?

The right architecture depends on your specific project: How sensitive is the data? Are there legal requirements? How many tenants do you expect? We clarify these questions together before starting development.

There are two main approaches: a shared database for all tenants or separate databases per customer. In most cases, the shared database is the better choice – it's easier to maintain and more cost-effective to operate.

Multitenancy with a shared database

With this approach, all tenants store their data in a shared database. Separation is achieved through a unique identifier – similar to filing folders in a shared cabinet, each clearly labelled.

Technically, each record is assigned an organisation identifier. This ensures that each tenant only sees their own data – the separation happens automatically in the background.

Important to know: the data is physically stored in the same location. This is usually not a problem – as long as no special legal requirements mandate strict physical separation.

A common objection: Isn't a shared database less secure? The short answer: No, if the software is properly developed.

Virtually every online shop works on the same principle: all customer data is stored in a central database. What matters is software quality and thorough test coverage. Separate databases are no substitute for clean development – they just make the project more expensive and complex.

Advantages of multitenancy with a database

With Laravel as the foundation, you benefit from a mature framework that optimally supports multi-tenant systems. Development remains efficient and maintenance straightforward.

Since no deep framework modifications are needed, updates remain straightforward. You can keep your system current and secure in the long term.

You can onboard new customers in seconds – a simple registration process is all it takes. No complex setup, no manual steps required.

Multitenancy with separate databases

With this approach, each tenant receives their own database. The data is physically separated from other tenants. This may be required when strict legal regulations demand it – such as for particularly sensitive health or financial data.

Attention: dead end!

This approach is significantly more complex and expensive. Once chosen, it can hardly be reversed. That's why we carefully examine at the project start whether a separate database architecture is truly necessary. Without compelling requirements, we advise against it.

Using multiple databases with Laravel

When physical data separation is unavoidable, Laravel supports this architecture too. A separate database is created for each tenant. This provides maximum isolation – but comes with significantly higher effort.

For this approach, we recommend the proven "Multitenancy" package by Spatie. It significantly simplifies managing separate databases and provides useful tools for daily operations.

Additional challenges due to a multi-database setup

With multiple databases, the software must always know which tenant is currently active. This affects all areas of the application – an additional layer of complexity that needs careful implementation.

Onboarding new customers

Creating new customers also becomes more complex: a separate database must be set up for each tenant. This can be automated, but means additional infrastructure complexity – and therefore higher costs.

Without automation, new tenants must be created manually – a process that quickly becomes a bottleneck as your customer base grows.

Real advantages of multi-client capable software

The biggest advantage lies in scalability: with each new customer, your revenue grows while operating costs remain nearly constant. At the same time, every tenant benefits from improvements you make in one central place.

Implementation with Laravel board tools

Since separate databases are only needed in exceptional cases, we focus on the proven single-database solution.

Laravel comes with everything you need for a multi-tenant system – no additional packages required. At its core is an "Organisations" table to which all other data is linked.

All application data is linked to this organisation. Through automated testing, we ensure that no tenant can access another's data. Test Driven Development (TDD) is essential for multi-tenant systems – the investment in thorough testing pays off in the long run.

Laracon Talk on the topic of multi-tenancy

As part of Laracon 2017, Tom Schlick gave a presentation on the topic of multi-tenancy.

Our recommendation

A shared database is the right choice for most projects. It enables fast growth, simple maintenance, and keeps costs manageable.

Unless legal requirements mandate physical data separation, we recommend the single-database solution. Want to build multi-tenant software? Get in touch – we're happy to advise you.

Further material:

- Presentation by Tom Schlick on Multitenancy in Laravel, Laracon 2017

- Wikipedia on client-enabled software

- Case Study: Multi-Tenant Architecture with Statamic

- Foto von Joshua Coleman