Tenanti Laravel Package

Product Decisions This Supports

• Architecture commitment: database-per-tenant or schema-per-tenant. Adopting orchestra/tenanti is not just a dependency choice; it signals isolation strategy. That affects onboarding cost, backups, data residency, migration operations, support burden, and pricing for years. PM should treat it as an architecture decision record with product and commercial consequences.
• Enterprise/compliance positioning. Per-tenant databases make “your data lives in its own database” a concrete claim for security reviews, GDPR/data-residency questionnaires, and enterprise procurement. This is a roadmap capability input, not merely engineering tooling.
• Schema evolution as a product capability. Because migrations run per tenant, the team can fan out schema changes in waves, canary design partners on beta schemas, roll back selectively, and report which customers are on which schema version. That enables staged rollouts and upgrade policy as product features.
• Build vs. buy for tenant lifecycle plumbing. Tenanti covers tenant-aware migrate/rollback/seed/Artisan plumbing. If the roadmap includes tenant provisioning, onboarding automation, or per-tenant upgrades, adopting it narrows remaining build scope to the tenant registry, resolver, provisioning path, observability, and operational controls.
• Roadmap sequencing against scale. Fan-out migration time, connection counts, backup/restore complexity, and per-tenant monitoring scale with the customer base. Adoption should trigger explicit platform work for migration orchestration, canary cohorts, failure recovery, and capacity planning.
• Segment targeting and packaging. A credible enabler for mid-market/enterprise deals requiring isolation. A poor fit for high-volume, low-ACV self-serve tiers where per-tenant databases multiply cost faster than they add value.
• Operational risk budgeting. Low adoption signals—zero dependents, thin ecosystem traction, framework-internal coupling—mean PM should plan for version pinning, source reading, internal abstraction, and fork contingency rather than treating it as a strategic, well-supported dependency.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and multi-tenancy is a committed product direction, not an experiment.
• You need per-tenant database or schema isolation for regulatory, contractual, security-review, or noisy-neighbor reasons—not just logical row scoping.
• You want tenant-aware migrations as first-class tooling: run, roll back, seed, and batch schema operations across tenants through familiar Artisan-style commands.
• You already have, or plan to build, a tenant registry and connection resolver; Tenanti expects to be told how tenants map to connections and databases.
• Your team is small enough that building migration fan-out, batch handling, and per-tenant rollback in-house would cost more than adopting and wrapping this package.
• You can invest in the missing operational layer: per-tenant locks, connection purging, canary cohorts, schema-version reporting, failure re-runs, and tenant-context assertions in jobs/commands.

Look elsewhere when:

• Shared schema with row-level scoping is sufficient. Simpler scoping packages or scoped Eloquent queries are easier to operate and better supported.
• Adoption signals are too thin for your risk tolerance. Zero dependents and limited traction mean you should budget for source reading, version pinning, internal abstraction, and possible fork maintenance.
• You need batteries-included tenancy such as tenant-aware cache, filesystem, queues, sessions, and routing. Tenanti is scoped to schema and connection management; tenant-aware jobs and console commands must be designed separately or they can write to the wrong connection.
• You need database-agnostic tenancy. Validate MySQL/PostgreSQL behavior early; schema-per-tenant semantics and migration behavior differ by engine.
• Your Laravel/PHP version is not explicitly supported. The package extends framework internals (Migrator, DatabaseManager), so major-version alignment is a common failure point and upgrade cost must be planned.

How to Pitch It (Stakeholders)

Executive summary: orchestra/tenanti is a Laravel package for running tenant-scoped database migrations and schema operations. It supports a database-per-tenant or schema-per-tenant isolation model, which can strengthen enterprise/compliance positioning and enable canary schema rollouts. Adopt it only if isolation is already a committed product direction; it is infrastructure plumbing, not a complete tenancy platform.

For engineering: Treat it as a thin, framework-coupled tool behind an internal TenantSchema service exposing migrate, rollback, seed, and schemaVersion. Pin the exact version, keep tenant migrations separate from control-plane migrations, assert tenant context in jobs/commands, purge connections in long-running workers, and add cache locks around fan-out. Budget for framework-upgrade testing and source reading because documentation and ecosystem support are limited.

For product/exec: The decision to adopt is really a decision to operate per-tenant databases. That improves isolation and enterprise credibility but increases onboarding, backup, migration, and support costs as customer count grows. Use it to support mid-market/enterprise segments that require isolation, not high-volume low-ACV tiers. Approve only with explicit investment in migration orchestration, observability, and failure recovery; otherwise the package solves the schema commands while leaving the operational risk with the product team.