Doctrine Multibase Bundle Laravel Package

Product Decisions This Supports

• Multi-tenant architecture choice (DB-per-tenant vs. shared schema). This package lowers the cost of the "database per tenant" model by letting a single Symfony app dynamically point Doctrine's base connection at different database instances. That directly informs the roadmap question: can we isolate tenant data without building a separate deployment per tenant?
• Build vs. buy for connection switching. The realistic alternative is a small internal wrapper around Doctrine's Connection/EntityManager (or a custom compiler-pass-driven registry). This package is a ready-made, MIT-licensed implementation of that pattern — useful as a reference design even if you ultimately build your own.
• Legacy or federated data integration. Dynamically swapping the base connection supports use cases like routing a request to a legacy database, a per-region instance, or a partner-specific database without duplicating the app.
• Environment/instance targeting in admin tooling. Useful for internal tools that need to inspect or operate across multiple database instances from one codebase.
• Feature scoping and effort estimation. Because adoption is trivial to prototype (bundle registration + config), it's a cheap spike to validate whether dynamic connection switching satisfies a roadmap item before committing to a heavier multi-tenancy platform.

When to Consider This Package

Consider it when:

• You're on Symfony + Doctrine ORM/DBAL and the need is specifically switching the base connection at runtime, not full tenant lifecycle management.
• You have a small number of well-known database targets (per-tenant, per-region, per-legacy-system) that can be enumerated in config.
• You're comfortable vendoring or forking the code — at 0 stars and 0 dependents, treat this as source you own, not a maintained dependency.
• You need a fast spike to de-risk a multi-database roadmap item before building a first-class solution.

Look elsewhere when:

• You need managed multi-tenancy (per-tenant migrations, schema provisioning, tenant resolution, connection pooling, caching isolation). Evaluate mature multi-tenancy bundles or a platform (e.g., schema-per-tenant tooling) instead — this package does not appear to cover lifecycle concerns.
• Supply-chain risk is a blocker. Zero stars, zero dependents, and a single maintainer mean no community backstop, no CVE coverage, and no guarantee of compatibility with future Symfony/Doctrine majors. If your org requires maintained dependencies with SLA or security review, this fails that gate.
• You're not on Symfony/Doctrine, or you need connection pooling / read-write splitting, which DBAL and dedicated middleware handle better.
• You require observability, retries, or failover semantics across instances — you'd be building that layer yourself.

How to Pitch It (Stakeholders)

For executives: We're evaluating a lightweight, MIT-licensed component that would let one application talk to multiple database instances and switch between them at runtime. This supports a database-per-tenant or per-region model without standing up a separate deployment for each customer — potentially a meaningful reduction in infrastructure and operational cost. The caveat is maturity: the package has essentially no adoption and a single maintainer, so we should treat it as a reference implementation or vendored code, not a strategic dependency. Recommendation: use it to validate the architecture in a time-boxed spike; budget for either forking it or building a small in-house equivalent before it goes near production.

For engineering: It solves a narrow, well-understood problem — dynamically rebinding Doctrine's base connection to different instances in a Symfony app. Integration surface is small (bundle registration plus configuration), so the spike cost is low. The trade-offs are real: no community maintenance, no dependents, unknown compatibility with future Doctrine/Symfony majors, and no coverage of tenant lifecycle concerns like per-tenant migrations, connection pooling, or isolation guarantees. Plan to own the code: pin/fork the source, add tests around connection switching and request scoping, and document the failure modes. If the spike validates the model, decide explicitly between forking this and building a minimal internal replacement — the latter is likely only a few hundred lines and removes the dependency risk entirely.