Doctrine Multi Schema Bundle Laravel Package

Product Decisions This Supports

• Tenancy architecture (shared schema vs. schema-per-tenant). The core decision this pattern serves: do we isolate customer data with one schema per tenant, or with a shared schema and a tenant_id discriminator? This package only exists to enable the former inside Doctrine, so it's evidence that "schema-per-tenant" is a viable, low-ceremony option on Symfony — not a reason to choose it.
• Roadmap: enterprise / regulated tiers. Schema-level isolation is a common checkbox for security questionnaires, data-residency asks, and per-tenant backup/restore or "delete my data" SLAs. If an enterprise tier is on the roadmap, this is the architectural fork in the road to resolve before the data model hardens.
• Build vs. buy (leaning build). With 0 stars, 0 dependents, and no community validation, this is not a procurement decision — it's a "borrow the pattern, own the code" decision. Budget for a small internal abstraction over Doctrine DBAL's connection/schema APIs rather than a dependency.
• Per-tenant migrations, backfills, and noisy-neighbor mitigation. The operational payoff: run migrations or heavy backfills against one tenant's schema without locking everyone else out, and cap blast radius of a bad migration.
• Stack constraint (important): this is a Symfony bundle for Doctrine ORM, not a Laravel package. For a Laravel/Eloquent codebase this is inapplicable and should be logged as "not a fit," not as a backlog item. If we're Laravel-first, the equivalent decision is a tenancy library (e.g., stancl/tenancy) or connection-switching, and this package informs the comparison, not the build.

When to Consider This Package

• Only if all of the following are true: Symfony + Doctrine ORM, an existing or committed schema-per-tenant requirement, and appetite to vendor/fork the code.
• Then treat it as a reference implementation, not a dependency. Read the source (it's a thin configuration/integration layer), extract the approach, and write it in-house. Roughly a day of engineering, and you own the upgrade path.
• Validate before any consideration: last commit date, supported Symfony and Doctrine DBAL versions (DBAL 3/4 changed schema APIs materially), license file, CI, tests, and a security policy. Absence of any of these is disqualifying for production.
• Look elsewhere if:
  • You're on Laravel/Eloquent — use native connection switching or a maintained tenancy package.
  • Postgres is the target — row-level security with a tenant-scoped session variable often beats schema sprawl, and avoids the migration-N-times problem.
  • You need per-tenant connection pooling, cross-tenant reporting, or sharding — schema-per-tenant makes cross-tenant analytics and connection counts painful.
  • You require commercial support or a maintained upstream.
• Cost to be aware of: schema-per-tenant multiplies migrations by tenant count, complicates local dev and CI fixtures, and complicates any global/aggregate query. That cost is real and usually underestimated; the package does not reduce it.

How to Pitch It (Stakeholders)

Executives (one paragraph): We evaluated a small open-source Symfony bundle for running one application against multiple database schemas. It is the mechanism behind "one database schema per customer," which is a strong isolation story for enterprise and regulated buyers. However: it is not a Laravel package and does not apply to our stack, and it is unmaintained with effectively zero adoption. Our recommendation is do not adopt it as a dependency — note the architecture pattern as an option, and if we pursue schema-per-tenant, fund a small internal implementation instead. No roadmap change is requested today; a decision on tenancy model should precede the enterprise tier's data model.

Engineering (summary): Symfony bundle, Doctrine-only, low complexity surface. Zero stars, zero dependents, no visible CI or release cadence — assume abandoned. A spike to read the code is ~30 minutes; reproducing its behavior over Doctrine DBAL is ~1 day. Do not add it to composer.json; if the pattern wins, we own a fork with tests and a DBAL upgrade watch item. For Laravel, this is a non-starter — evaluate stancl/tenancy or Postgres RLS instead and bring a comparison back.