What Multi-Tenancy Actually Means
A multi-tenant application serves multiple customers (tenants) from a single codebase, with each tenant’s data kept isolated. The two dominant approaches are a shared database with tenant-scoped rows, or separate databases per tenant — and the right choice depends heavily on your scale and isolation requirements.
Single Database, Shared Schema
The simplest approach adds a tenant_id column to relevant tables and scopes every query by it. Laravel’s global scopes make this manageable — define a scope that automatically adds a where tenant_id = ? clause to every query on a model, so individual developers can’t accidentally forget it. This approach is cheap to run and easy to maintain, but requires discipline: a missing scope is a data leak.
Database-per-Tenant
For stronger isolation — often required for enterprise customers or regulatory reasons — each tenant gets a separate database, and the application switches connections based on the current tenant. Packages like stancl/tenancy handle the connection-switching and migration-running mechanics, but this approach adds real operational complexity: running migrations across hundreds of tenant databases, backing them up individually, and managing connection pool exhaustion.
Identifying the Current Tenant
Most applications resolve tenancy from the subdomain (acme.yourapp.com), a custom domain, or a header for API requests. Middleware that resolves and binds the current tenant early in the request lifecycle keeps the rest of your application blissfully unaware of the mechanics — controllers and services just ask for “the current tenant” without knowing how it was determined.
Testing Considerations
Multi-tenant bugs are uniquely dangerous because they can mean one customer seeing another customer’s data. Write tests that explicitly assert tenant isolation — create two tenants, seed distinct data for each, and verify queries never cross the boundary. This is worth the investment; it’s the class of bug you cannot afford to ship.
Practical Recommendation
Start with shared-schema multi-tenancy unless you have a concrete reason not to — it’s simpler to build, test, and operate. Move to database-per-tenant only when you have specific isolation, compliance, or per-tenant scaling requirements that shared schema genuinely can’t satisfy.