Laravel Schemify Laravel Package

Product Decisions This Supports

• Schema-per-tenant ("layer") architecture on Postgres. The package's core value is running Laravel's DB lifecycle per isolated schema via a --layer flag on migrate, migrate:fresh, migrate:install, migrate:status, migrate:reset, db:seed, and db:wipe. This release confirms the abstraction covers the full migration surface, not just the happy path — relevant if you're deciding between schema isolation and row-level tenancy.
• Build vs. buy for multi-tenant provisioning. The fix history shows real cost concentrated in framework-integration plumbing (getOptions() vs configure(), Symfony constructor semantics, search_path session reuse, Laravel 11/12 vs 13 schema resolution). Buying means inheriting that maintenance; building means owning it. This release is evidence for buying if you're on Postgres and staying on Laravel.
• Upgrade planning as a roadmap input. The --layer regression was caused by Laravel 13.21 migrating its own commands to $signature. Any Laravel minor can silently break command overrides. Budget a per-minor-version regression pass for migration/seed/wipe commands in your release plan, and treat Laravel upgrades as coupled releases rather than routine dependency bumps.
• Release-gating for migration tooling. layers:migrate failing from the second layer onward on Laravel 11/12 is an environment-provisioning outage, not a cosmetic bug. Treat patch versions of this package as change-managed deploys with a staging tenant rollout, and pin explicitly (>=3.4.2 if you're on the 3.4.x line).
• Feature/use-case fit: multi-tenant SaaS with per-tenant schema isolation, staging/preview environments as sibling schemas, or regulated data separation where physical schema boundaries aid audit narratives.

When to Consider This Package

Consider it when:

• You are on PostgreSQL and want schema-per-tenant (or per-environment) isolation with Laravel's native migration tooling preserved — php artisan migrate --layer=tenant_acme rather than a parallel command vocabulary.
• You need the whole DB lifecycle per layer: install, migrate, status, reset, seed, wipe — not just migrate.
• You want in-place layer switching without reconnecting (3.4.0+ behaviour), which matters for request-scoped or job-scoped tenant resolution.
• You are on Laravel 11, 12, or 13 — this release explicitly reconciles behaviour across all three.
• Your team would rather not maintain command overrides against Laravel internals.

Look elsewhere when:

• You are on MySQL/MariaDB or SQL Server — the design is built on Postgres schemas and search_path.
• You need row-level tenancy with a single schema (e.g. tenant_id scoping, RLS) — this package solves a different problem.
• You require connection-per-tenant isolation (separate databases/hosts, distinct credentials, cross-region placement) — that's a connection resolver concern, not a schema concern.
• You need managed/DBaaS support where CREATE SCHEMA or SET search_path is restricted.
• You want a stable, framework-agnostic abstraction. This package's correctness depends on how Laravel declares command parameters internally; that surface changes without notice. If your org cannot absorb frequent patch upgrades, prefer a tenancy layer with a narrower coupling.
• You expect the package to own tenant lifecycle (provisioning, billing, onboarding, data residency routing) — it manages schema context and migration execution, not tenant management.

How to Pitch It (Stakeholders)

For executives: This is a patch release (v3.4.2) with no new features and no breaking changes — but it fixes two defects that would have caused production-visible outages for anyone already running it. The first: on Laravel 13.21+, the --layer option silently vanished from overridden commands, so any command specifying a tenant layer aborted. The second: on Laravel 11 and 12, schema introspection reported the previous layer after an in-place switch, which caused layers:migrate to fail from the second layer onward — i.e. new tenants' migrations would not run. Both are fixed. The strategic read: the package does real work for us (per-tenant Postgres schema isolation using standard artisan migrate semantics), but it is tightly coupled to Laravel's internals. Recommendation: adopt with an explicit version pin and a standing item in each Laravel upgrade to re-verify the migration, seed, and wipe commands against a non-primary layer.

For engineering: Upgrade to 3.4.2 if you are on 3.4.0 or 3.4.1 — 3.4.1 and earlier are unsafe for multi-layer migration workflows on Laravel 11/12, and 3.4.1 and earlier are broken on Laravel 13.21+. If you are below 3.4.0, this release also carries the in-place layer-switch optimisation (connection reuse via SET search_path), so read the 3.4.0 notes alongside this one for behavioural change. Verify in staging: run migrate:install and migrate against a second layer, confirm Schema::hasTable() resolves to the active layer, and confirm --layer appears in help output for all six overridden commands. Expect future breakage risk from Laravel's continued migration to $signature-declared commands; treat Laravel minor upgrades as requiring a regression pass on these commands rather than a routine composer update.