Doctrine Postgres Types Laravel Package

Product Decisions This Supports

• Data-model choices on Postgres. Whether to use native citext (case-insensitive email/uniqueness), hstore, inet, jsonb, or array columns instead of modelling everything as varchar/text. This package is the enabling layer for those columns inside Doctrine-mapped entities.
• Build vs. buy (really: buy vs. vendor vs. write). The type surface is small and mostly mechanical — a handful of classes mapping a Postgres type to a PHP value. The realistic decision is not "adopt a dependency" but "vendor/fork ~a few hundred lines" vs. "reimplement in-house" vs. "adopt a maintained successor."
• ORM strategy in a Laravel codebase. Only relevant if the product uses Doctrine via laravel-doctrine rather than Eloquent. If the team is Eloquent-first, this package contributes nothing and the equivalent decision is handled by attribute casts.
• Platform upgrade roadmap. Last release 2016-08-31, 68 stars, minimal community. It almost certainly predates Doctrine DBAL 3/4 API changes (type registration, getName() removal, changed getSQLDeclaration signatures). Treat it as a blocker or a to-do item on any DBAL/PHP upgrade plan, not as a forward-looking investment.
• Legacy maintenance vs. new build. For an existing app already using these types, the decision is "pin, fork, or migrate." For a new build, the decision is "pick a maintained alternative or write the types ourselves."
• Risk register / supply-chain. Unmaintained but also low-blast-radius: no network surface, no runtime services, code is pure mapping logic — so audit cost is low even though support risk is real.

When to Consider This Package

Consider it when all of the following hold:

• The application uses Doctrine DBAL/ORM on PostgreSQL inside Laravel (not Eloquent-only).
• You are on, or can pin to, a DBAL version this code actually works with — verify with a timeboxed spike before committing; do not assume.
• You need only a small, stable subset of Postgres types (citext, hstore, arrays, inet/CIDR, maybe ltree), and you're comfortable copying the classes into your own codebase and owning them.
• You want a known-good reference implementation written by a team that used it in production, to avoid rediscovering edge cases (null handling, array parsing, casting back to PHP values).
• The alternative — writing the types yourself — is judged more expensive than auditing this code. Usually it isn't; usually it's a day.

Look elsewhere (or don't adopt) when:

• Eloquent-only stack. Irrelevant; use casts.
• DBAL 3/4 or PHP 8.x+ target without a fork. Expect breakage; budget migration work.
• You need maintenance guarantees, security response, or a support contract. None exist here.
• A maintained Postgres-types package covers your type list — prefer it, and evaluate it on release cadence and DBAL version support rather than stars alone.
• Your need is one type (e.g., citext only). Write one class; don't take on a dependency or a fork for that.
• Non-Postgres or multi-database products — these types are Postgres-specific and will complicate portability.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source helper that lets our Laravel application store certain Postgres-specific data types properly. It was published in 2016 and is no longer maintained — 68 stars, no releases in roughly a decade — so it is not a strategic dependency and we should not treat it as one. The good news is that its scope is tiny and its risk is contained: it's pure data-mapping code with no network or service surface. My recommendation is to use it, if at all, as a reference we copy and own, not as a library we depend on. Cost is measured in hours, not sprints, and it removes a real technical blocker on our database model.

For engineering:

• Treat the repo as source material, not a dependency. Vendor the type classes into our codebase, add tests, and pin nothing to Packagist.
• Spike first (½–1 day): confirm compatibility with our DBAL version and PHP runtime; the 2016 release date makes API drift near-certain.
• Own the upgrade path: whichever types we keep become our code, so DBAL upgrades are our responsibility — that's the trade we're accepting for a small, auditable surface.
• Prefer a maintained alternative if one covers our type list and supports our DBAL version; benchmark it on release cadence and issue responsiveness, not popularity.
• Scope discipline: adopt only the types we actually map in entities today. Don't add hstore because it's there.
• Decide the ORM question explicitly: if the product is heading Eloquent-first, this whole thread is moot and the equivalent work belongs in casts.