Multi-Tenant SaaS Platform (Database-per-Vendor)

A central database holds the tenant registry (names, subdomains, encrypted database credentials, branding settings) and the super-admin accounts. Each vendor gets a dedicated database containing their users, products, and other business data.

On every request, a middleware identifies the tenant (by subdomain, custom domain, or header), looks it up in the central registry, and switches Laravel's database connection to that tenant's database for the rest of the request. A TenantManager service owns this switching, plus provisioning and decommissioning of tenant databases.

Choosing the isolation strategy. I compared three common approaches: a shared database with a tenant_id column, schema-per-tenant (PostgreSQL), and database-per-tenant. I chose database-per-tenant because it gives physical separation rather than relying on every query being written correctly. The trade-off is operational complexity (more databases to migrate, back up, and monitor), which I addressed directly in the DevOps design.

Two layers of protection. Each vendor's data lives in its own MySQL database, and on top of that, tenant models use a global Eloquent scope that automatically filters every query by tenant. Even if a developer forgets a where clause, the framework adds it.

Separating the two kinds of admin. Early on I realized "admin" meant two different things. Tenant admins manage their own company and live inside their tenant's database. Super admins run the platform and live in a separate central database with their own login endpoint. Keeping them in different tables, with different auth flows, makes privilege escalation from tenant admin to platform admin structurally impossible rather than just "checked for."