Pomm Foundation Bundle Laravel Package

Product Decisions This Supports

• Framework fit — the first decision this actually informs, and v0.7.0 does not change it. This remains a Symfony bundle, not a Laravel package. If our codebase is Laravel, this package is out of scope and the real decision is whether to adopt Pomm Foundation directly (pomm-project/foundation) as a standalone data-access layer, skipping the bundle entirely. If we run (or are evaluating) Symfony, this becomes a viable wiring option — and only on Symfony 6+ / PHP 8.0+ after this release.
• Build vs. buy for the PostgreSQL data-access layer. Supports a decision to keep the integration layer thin and vendor-supplied rather than hand-rolling a Symfony service-provider bridge to Pomm. The bundle is a small, MIT-licensed adapter — likely cheaper to adopt or fork than to build in-house for a Symfony app.
• ORM strategy: Doctrine vs. a SQL-first Postgres mapper. Pomm's premise is explicit SQL plus object mapping tuned for PostgreSQL. This bundle is the artifact we'd evaluate if the team's position is "Doctrine's abstraction costs us Postgres-specific capability and developer clarity."
• Feature support for Postgres-native types. Relevant if the roadmap includes JSONB, arrays, hstore, ranges, or geometric types that are awkward under a generic ORM. This is a genuine capability argument, and it's the strongest product reason to look at Pomm at all.
• Platform currency decision (updated by v0.7.0). The release drops PHP 7 and Symfony ≤5 and requires PHP 8.0+ / Symfony 6. That converts an open question ("is this still maintained against modern Symfony?") into a constraint: any Symfony 5 LTS workstream is now excluded unless an upgrade is already on the roadmap. It also is the first evidence of maintenance activity since 2022 — a positive signal, but one data point, not a track record.
• Use cases where it fits: internal/analytics services, reporting backends, or systems sitting on an existing hand-tuned Postgres schema where the team wants SQL visibility and low ORM ceremony.
• Risk/portfolio decision. Still a low-traction artifact (6 stars, 0 dependents). The v0.7.0 bump signals someone is keeping the constraints current, but it is a compatibility bump with no new features, no deprecation plan, and no indication of a support policy. This supports a "proceed only with a named owner and an exit plan" decision, not a strategic platform bet.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony 6 or later on PHP 8.0+. This is now a hard gate, not a diligence item: v0.7.0 removed support for PHP 7 and older Symfony, so Symfony 5 LTS shops must upgrade first or stay on an older bundle tag (and own that divergence).
• The database is PostgreSQL-only and will stay that way; Pomm is not a multi-database abstraction.
• The team is comfortable writing and owning SQL, and sees that as an advantage rather than a maintenance tax.
• The surface area is small enough that vendoring or forking is acceptable — which, for a bundle this thin, it likely is.
• Someone is willing to own the dependency: track Pomm Foundation's release cadence, PHP compatibility, and security posture, since the bundle inherits its upstream risk. Confirm Pomm Foundation itself supports PHP 8.x before committing — a PHP-8-only bundle over an upstream that lags would strand us.

Look elsewhere when:

• You're on Laravel. Use Eloquent or the DB facade; if you specifically want Pomm semantics, integrate Pomm Foundation directly — this bundle adds nothing for you. The v0.7.0 Symfony 6 bump makes this more true, not less.
• You're on Symfony 5 LTS or PHP 7.x and an upgrade isn't funded. v0.7.0 is a breaking change for you; adopting now means adopting an EOL-adjacent older tag.
• Doctrine is already in place and working. The migration cost almost certainly exceeds the benefit at this adoption level.
• You need multi-database support, a vendor relationship, an LTS guarantee, or a large hiring pool. Zero dependents and single-digit stars mean no community safety net and effectively no Stack Overflow corpus.
• You need demonstrated maintenance responsiveness. v0.7.0 is encouraging but singular; validate against commit history, issue response times, and CI status before it enters a roadmap.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a narrow, low-adoption integration library, not a platform decision. Its only strategic value is enabling a SQL-first PostgreSQL approach in Symfony applications, which can reduce ORM friction and unlock Postgres-specific features. The new v0.7.0 release modernizes it to PHP 8 and Symfony 6 — a useful sign of life, but a compatibility bump rather than new capability, and it is a breaking change that rules out Symfony 5 / PHP 7 estates. Adoption risk remains material given negligible community traction (6 stars, 0 dependents). Recommendation: do not treat as a strategic dependency; approve only for a bounded, small-scope use case on a Symfony 6+/PHP 8+ service, with a named owner and a documented fallback to Doctrine or direct Pomm Foundation usage. It is Symfony-specific and irrelevant to any Laravel workstream — state that plainly up front to avoid wasted evaluation cycles.

For engineering: MIT-licensed, thin Symfony bridge over Pomm Foundation. Low integration cost, low lock-in, and realistically forkable if upstream stalls. v0.7.0 is a constraint-only release (PHP 8.0, Symfony 6) — no feature or API additions, but treat it as a breaking change if anything in the estate is still on Symfony 5 or PHP 7, and pin accordingly. The real dependency risk is Pomm Foundation itself, not this bundle — diligence should target its PHP 8 support, test coverage, and maintainer situation before any spike. Timebox an evaluation spike; do not commit to a migration until the Postgres-type-mapping benefit is measured against the current Doctrine setup.