Multi-tenancy is an architecture where a single application, running from a single codebase, serves multiple customers ("tenants") while keeping each tenant's data strictly separated. Instead of deploying a fresh copy of the software for every customer, one deployment serves everyone, invisibly to each of them.
How multi-tenancy is typically built
There are a few common approaches, each with different tradeoffs:
A single database with a tenant identifier on every relevant table, the simplest and most common approach
Separate database schemas per tenant, giving stronger isolation with a bit more operational overhead
Fully separate databases per tenant, the strongest isolation, usually reserved for tenants with strict compliance needs
What multi-tenancy is good for
Multi-tenancy is the backbone of most SaaS products. It lets you maintain and improve one application while serving many customers, instead of maintaining a separate installation per client, which becomes unmanageable past a handful of customers.
What to get right
Data isolation has to be airtight; a bug that lets one tenant see another's data is the worst-case scenario for this architecture. Beyond that, you need to plan for per-tenant customization, scaling as tenant count grows, and how a tenant's data gets exported or deleted when they leave.
Vulpo and Multi-tenancy
We build SaaS platforms and back-office systems that serve multiple clients from a single codebase. Multi-tenancy is something we design in from the start of a Laravel project, not something bolted on after the fact once it becomes a problem.
