Postgresql Doctrine Bundle Laravel Package

Product Decisions This Supports

• Postgres-first feature bets. This bundle unlocks Postgres-native capabilities inside Symfony/Doctrine: jsonb, arrays, enums, hstore, citext, inet, full-text tsvector indexes, materialized views, extensions (uuid-ossp, pgcrypto), partial and functional indexes. These map directly to roadmap choices — "do we ship JSONB-backed flexible attributes?" / "do we use Postgres full-text search instead of standing up Elasticsearch?" / "do we use native enums or a lookup table?"
• Build vs. buy for DBAL gaps. Doctrine historically lags on Postgres-specific DDL. The decision this informs: extend DBAL/migrations ourselves (~weeks of engineering, ongoing), wait on upstream, or adopt a thin community shim.
• Migration strategy decisions. If migrations can't express Postgres DDL, teams either hand-write raw SQL (review/lint blind spots, no rollback symmetry) or drift schema out of migrations entirely. This package materially changes that trade-off.
• Multi-tenant / schema-per-tenant architectures, where CREATE SCHEMA, extensions, and per-schema DDL must be migration-managed.
• Buy-side diligence for M&A / vendor reviews: a dependency audit signal — is the persistence layer standard Doctrine, or does it depend on low-signal third-party shims?

Caveat for the record: despite the framing, this is a Symfony bundle, not a Laravel package. It does not apply to Laravel/Eloquent products at all. Confirm your stack before scoping.

When to Consider This Package

Consider it when all of the following are true:

• The app is Symfony + Doctrine ORM/DBAL + Doctrine Migrations, running on Postgres 12+.
• You have a concrete, near-term need for Postgres DDL that Doctrine can't express cleanly (enums, materialized views, extensions, triggers).
• The feature is isolated to schema/migration concerns — not on a hot application path.
• You're mapping json/jsonb columns through this bundle's custom Doctrine types — pin v0.2.2 or later; earlier versions had a defect where the JSON model type override misbehaved on repeated calls (silent type-drift risk in anything that touches the DBAL type registry more than once per process, including workers and test suites).
• Your Symfony/DBAL version is covered by the ConnectionFactoryDecorator compatibility fix in v0.2.2 — this is the release that makes the bundle's connection decorator extend the expected ConnectionFactory parent, i.e. it targets framework-version compatibility rather than new capability. Verify against your pinned Symfony version before assuming it applies.
• Your team is willing to vendor or fork the code (MIT — permitted) and accept ownership of a small, single-maintainer codebase.
• You can pin versions and add integration tests around the migration output.

Look elsewhere when:

• Laravel (or any non-Doctrine stack) — irrelevant.
• You need active maintenance, security responsiveness, or a support contract. The picture has improved marginally — v0.2.2 is a real release with two fixes, not an abandoned tag — but it's still a two-item patch on a four-star, zero-dependent project. One maintenance pulse is not a trend; treat health as unproven but no longer presumed dead.
• You expect feature movement. v0.2.2 adds no capability: no new Postgres types, no new DDL, no Doctrine gap closed. The feature surface is unchanged from the version previously assessed.
• The need is short-lived — if Doctrine has since closed the gap, raw SQL in a small number of migrations is cheaper and lower-risk than a new dependency.
• Regulated/compliance contexts where dependency provenance and CVE response time are gated.
• You rely on managed Postgres features (e.g., pgvector, PostGIS) — verify coverage before assuming; do not assume parity with extensions the bundle predates.
• You're scaling to multiple database engines; Postgres-specific DDL locks you in — make that a conscious, documented bet.

How to Pitch It (Stakeholders)

One line: A small, MIT-licensed Symfony bundle that lets our Doctrine migrations speak Postgres natively, so we can use Postgres features that would otherwise require hand-written SQL or a custom internal fork.

For executives: This is a narrow, reversible utility, not a platform commitment. It removes a recurring source of friction — engineers writing raw DDL migrations that bypass our tooling — and lets us evaluate Postgres-native capabilities (jsonb, full-text search, enums) on their merits rather than being blocked by ORM limitations. The cost is near zero (MIT, no license spend). On risk: the project shipped a maintenance patch (v0.2.2) covering a framework-compatibility fix and a JSON type-mapping bug, which is a modest positive signal against the "dormant dependency" concern — but it's a bugfix-only patch from a single maintainer, so it changes the trend from unknown to not yet proven, not to healthy. We should not read it as a roadmap commitment.

For engineering: Treat it as vendored source, not a trusted dependency. Pin v0.2.2 or later — earlier pins carry the JSON type-override defect, so don't inherit a stale lockfile. Read the full diff (it should be small), wrap it behind our own migration base classes, and add CI that applies migrations against a clean Postgres instance so upstream drift can't silently break us. Confirm the ConnectionFactoryDecorator parent-class change matches the Symfony/DBAL version we're on; if we're ahead of it, that fix won't save us. Budget roughly 1–2 engineer-days to adopt and a standing ~1 day/quarter of fork-maintenance ownership, with a clear exit path: if Doctrine upstreams the capability or the package goes quiet again, we replace it with raw SQL in an afternoon.

Recommendation: Approve for a time-boxed spike on a non-critical schema, not for core tenancy or anything on the hot path. No re-scoping is warranted — capabilities are unchanged — but upgrade the dependency-health line in our risk register from "no releases since 2023" to "sporadic single-maintainer patches; last reviewed at v0.2.2" and re-evaluate before wider rollout.