Multi-tenancy in Laravel: where to start

Three workable models

1. One database, tenant_id column — fastest start, simpler migrations. Works for dozens or hundreds of clients with strict Eloquent scopes.
2. Schema per tenant — stronger isolation, harder DevOps.
3. Database per tenant — maximum isolation, higher infrastructure cost.

In practice most MVPs start with tenant_id + global scopes, then add Spatie Laravel Multitenancy or a custom TenantResolver when separate domains and billing appear.

What to build into the MVP

• Middleware that resolves tenant from subdomain, header, or session.
• Block queries without tenant context on "shared" models.
• Separate queues or job prefixes per tenant for heavy tasks.
• Audit trail: who changed critical settings and when.

A typical mistake

Mixing "global" and "client" entities in the same tables without clear rules. Six months later that becomes an expensive refactor. Document boundaries once and cover them with tests.

Ready to design multi-tenancy for your case? Contact us.