Tenancy Laravel Package

Product Decisions This Supports

• Tenancy model / data architecture: This is the decision the package most directly enables. Choosing between shared-schema (tenant_id on every row), schema-per-tenant (Postgres), and database-per-tenant is usually a one-way door — stancl/tenancy reduces the cost of that door by handling connection switching, tenant-aware cache/storage/filesystem, and queue context automatically, so a DB-per-tenant or hybrid model becomes a configuration choice rather than a rewrite. It also lets you start shared-schema for self-serve and offer dedicated databases as a premium tier without a second codebase.
• Build vs. buy for tenancy plumbing: Everything a team would otherwise hand-roll — tenant resolution by hostname (including second-level domains), migration orchestration per tenant (tenants:migrate, migrate-fresh --step), connection bootstrapping, queue worker context reverting, tenant asset serving, impersonation for support — ships in the box under MIT. That is typically weeks of senior engineering plus indefinite maintenance for a non-differentiating capability.
• Roadmap sequencing: Makes isolation-dependent commitments plannable for the next one to two quarters — "dedicated database per enterprise customer," "tenant-controlled custom domains," "data residency in EU/US," "per-tenant backups/restore." These are contract-winning features that become feasible without a platform team.
• Packaging and pricing: Per-tenant database cost becomes a measurable COGS line, which informs tier design (shared pool vs. dedicated instance) and the margin math on enterprise plans. The alternative — discovering isolation cost mid-negotiation — is far worse.
• Support and onboarding economics: Built-in impersonation and tenant-scoped console commands lower the cost per support ticket and make white-glove onboarding scriptable.
• Non-decisions: It does not decide billing, metering, feature flags, tenant provisioning UI, or analytics. Budget for those separately rather than assuming the package covers them.

When to Consider This Package

Adopt when:

• The product is a Laravel 10–13 app on PHP 8+ and tenancy is a business requirement, not a nice-to-have.
• Customers, contracts, or compliance regimes demand data isolation (per-tenant database is a clean answer to "where does my data live?").
• You expect noisy-neighbor problems or per-tenant scale variance that a shared schema can't absorb.
• Tenant count is in the tens to low thousands — per-tenant migrations and connections remain operationally sane.
• Subdomain or custom-domain identification matches your intended signup UX, and you can provision wildcard DNS and TLS.
• You can live with a community-maintained dependency and are prepared to pin versions, run your own integration tests, and be fork-capable.

Look elsewhere when:

• Shared-schema with a tenant_id and global scopes is sufficient. The package's core value is connection-level isolation; if you don't need it, a scoped-model approach is simpler and cheaper to reason about.
• The architecture is polyglot or multi-service. The package only governs the PHP app — tenancy for your search index, warehouse, and event bus is still your problem, and a central tenancy service may be the better investment.
• Tenant counts reach the tens of thousands with per-tenant databases; connection and migration overhead dominates, and a shared database or schema-based model wins.
• You require vendor indemnity, an SLA, or a support contract. This is a single-primary-maintainer MIT project — mitigate with a fork plan, not a procurement negotiation.
• Analytics and cross-tenant reporting are the primary workload; database-per-tenant makes aggregate queries materially harder and should push the architecture decision first.
• You need tenancy in a serverless or horizontally chatty runtime where long-lived connection bootstrapping assumptions don't hold — validate before committing.

Two signals to discount in the scoring: the "0 dependents" figure is a registry artifact rather than evidence of low use, and the low opportunity score (40.89) reflects a mature, well-served category, not a weak package. Overall score of 63 is consistent with "safe, proven default with maintainer-concentration risk."

How to Pitch It (Stakeholders)

To executives: We can sell to customers who require data isolation — the single most common blocker in enterprise SaaS deals — without building a second product. stancl/tenancy is the de facto standard for multi-tenancy in Laravel: 4,400+ GitHub stars, MIT licensed, actively released through August 2026 with support for current Laravel versions, and a track record of steady patch releases across five major Laravel upgrades. Buying this instead of building it removes an estimated several engineer-months of non-differentiating work and, more importantly, removes it from the critical path of the enterprise tier. The residual risk is concentration: one primary maintainer, no commercial SLA, documentation split between the 3.x and 4.x lines. We mitigate with version pinning, our own integration test suite, and a documented fork path — standard practice for open-source infrastructure and cheaper than the alternative.

To engineering: It's designed to be invisible — no model traits to change connection, no swapping Laravel facades for tenancy-aware variants; tenant identification is hostname-based out of the box and context switching is handled by bootstrappers. It already covers the parts teams usually get wrong: queue workers reverting to central context, taggable cache, tenant-aware filesystem and asset serving, per-tenant migration and seeding commands, MariaDB and Postgres schema managers, and impersonation. Your adoption work is configuration, DNS/TLS for wildcard subdomains, and a migration story for existing tenants — not a refactor. We should still own the cross-tenant reporting layer and the provisioning pipeline, which are out of scope.