Postgres Schema Bundle Laravel Package

Product Decisions This Supports

• Multi-tenancy architecture (build vs. buy vs. fork): The core decision this package informs is how we isolate tenant data. If we're considering schema-per-tenant Postgres (a middle ground between shared-schema tenant_id columns and database-per-tenant), this bundle is the shortest path to a working search_path-switching layer on Doctrine/Symfony, and lets us defer or avoid a custom implementation.
• Feature feasibility for tenant-scoped products: Enables roadmap items that depend on per-tenant isolation — tenant-specific migrations, per-tenant extensions/indexes, per-tenant backup/restore, and "export my data" or hard-delete-on-churn (drop schema) capabilities that are painful in a shared-schema model.
• Isolation tiering / enterprise plan packaging: Schema-per-tenant is a defensible story for security questionnaires and enterprise procurement ("your data lives in its own namespace"), and it maps cleanly to a higher-priced tier or on-prem/BYOC offering.
• Migration and release-process design: Forces an explicit decision about how schema changes roll out across N tenants (fan-out migration, canary tenants, rollback). This package's existence implies that workflow is solved-ish; not choosing it means we own that pipeline.
• Vendor-internal code risk (strengthened by v2.0.8): Still 0 stars, 0 dependents, one publisher, and a low 2.0.x release cadence. The v2.0.8 patch — "fix: reset schema on transaction rollback" — is a direct confirmation of the risk we flagged: through v2.0.7, a rolled-back transaction could leave a stale search_path on a reused connection. That is exactly the cross-tenant leak class we care about. The upside is that the maintainer is actively fixing isolation-correctness bugs, not just features; the read is reference implementation / vendor-internal code made public, now demonstrably patching safety-critical behaviour. That's a decision input: pilot/fork-and-own (with the fix included) vs. adopt as a dependency.
• Use cases where it earns its keep: B2B SaaS with a small-to-moderate number of large tenants (tens to low thousands), per-tenant customization requirements (custom fields, extensions), regulated customers needing stronger isolation without full DB-per-tenant ops cost, and internal platforms where a handful of brands/domains share one codebase (MacPaw's own pattern — brands/domains mapped to schemas).

When to Consider This Package

Consider it when:

• You are on Symfony + Doctrine ORM/DBAL + Postgres and tenant identity is derivable from the request (host/subdomain, header, or auth claim) — the bundle's value is wiring that resolution to search_path for you.
• You have already decided schema-per-tenant is your model, or you're explicitly running a 2–4 week spike to evaluate it against shared-schema and DB-per-tenant.
• Your tenant count is bounded and your migration fan-out is manageable (a background job per schema, not a per-request concern).
• You have engineering capacity to read and patch the source — treat it as a vetted starting point you own, not a black box.
• You want a reference for the hard parts: connection/session search_path hygiene in long-lived processes, Doctrine metadata caching per schema, transaction/rollback unwinding, and migration tooling.
• You pin to v2.0.8 or later. Any evaluation, spike, or fork should baseline at ≥2.0.8; if you already forked from v2.0.7 or earlier, backport PR #23 (schema reset on transaction rollback) before doing anything else.

Look elsewhere (or build in-house) when:

• You're not on Symfony/Doctrine. The value is the framework integration; in Laravel you'd be re-implementing it against Eloquent, and a Laravel-native multi-tenancy package with Postgres schema support is the better comparison.
• You need vendor support, SLAs, or a security review trail. Zero stars, zero dependents, and a single maintainer means no ecosystem signal, no CVE-watching community, and no guarantee of a next release. The v2.0.8 rollback fix is evidence the maintainer is responsive — but also evidence that isolation-correctness bugs in this package surface as patch releases, so you must track the changelog yourself; there is no advisory feed doing it for you.
• You run long-lived workers, queues, Octane/RoadRunner, or connection pooling. search_path is session state; a leaked or stale search_path is a cross-tenant data exposure bug. v2.0.8 closes a concrete rollback-path hole here, but it does not retire the risk — the rollback path was broken in production-shaped code until very recently, so assume other unwind paths (failed jobs, killed workers, nested transactions, savepoint behaviour) are under-tested. Audit before adoption.
• You need cross-tenant reporting/analytics. Schema-per-tenant makes "sum across all customers" queries awkward; if that's a core product surface, reconsider the isolation model first.
• Tenant count is very high (10k+) — shared-schema with row-level security or Citus-style sharding is usually the better fit; per-schema DDL fan-out stops scaling operationally.

How to Pitch It (Stakeholders)

To executives (one paragraph): macpaw/postgres-schema-bundle is a small open-source Symfony bundle from MacPaw that gives each customer their own Postgres schema instead of mixing all customers in shared tables. Strategically it buys us a credible data-isolation story for enterprise deals and per-customer customization, without the operational cost of a database per customer. The catch is maturity: it has effectively no public adoption (0 stars, 0 dependents) and appears to be MacPaw's internal tooling published openly — so I'd frame this as "adopt the pattern, own the code" rather than adding a dependency we can't support. The latest patch (v2.0.8) fixes a real isolation bug where a rolled-back transaction could leave the previous customer's schema selected on a reused connection — good news that it's fixed and that the maintainer is on it, bad news that a bug of that class shipped at all and that there's no advisory feed to warn us next time. Recommended path: a time-boxed spike against our real tenant model pinned to ≥2.0.8, then a decision to vendor/fork it or build the equivalent in-house. Cost of finding out is low; cost of discovering a search_path isolation bug in production is not.

To engineering (the ask):

• Time-box: 2–3 weeks, one engineer, on a throwaway branch with a representative tenant model. Baseline at v2.0.8+; if you start from an existing fork, cherry-pick PR #23 first.
• Prove these six things: (1) search_path is set and reset correctly per request and per job — including failures and exceptions; (2) transaction rollback explicitly covered — assert search_path after ROLLBACK, after nested/savepoint rollback, and after a rolled-back job in a worker, since that was the v2.0.7 hole; (3) Doctrine metadata/query caches don't bleed across tenants; (4) per-tenant migration fan-out is scriptable and idempotent; (5) connection reuse in queues/workers is safe; (6) performance is acceptable for our tenant mix.
• Explicitly audit for cross-tenant leakage — this is the only risk that matters. A fix in the changelog is not a proof; write the failing test that would have caught the rollback leak and confirm it passes on 2.0.8. Any remaining doubt is a stop.
• Then decide: fork-and-own (likely, and now with a concrete reason to pin a version), build a thinner in-house version informed by it, or drop schema-per-tenant for now.
• Set expectations with the business: we are not betting on this package's community. We're using it as a well-informed head start on a design we'd otherwise spec from scratch — and we accept that we, not the maintainer, are responsible for watching for the next isolation fix.