Hstore Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (verdict: build). The functional surface here is tiny — a Doctrine DBAL type that maps PostgreSQL's hstore column to a PHP array. If hstore support is genuinely required, the equivalent is roughly 50–100 lines of in-house code (a Type subclass plus convertToDatabaseValue/convertToPHPValue). Owning that code is strictly cheaper than owning a dependency that has been marked deprecated and has not shipped since 2014.
• Data-model / roadmap decision: standardize on jsonb, not hstore. hstore predates jsonb and only supports flat string→string maps. It cannot store nested structures, numbers, booleans, or nulls natively. Any new feature that needs flexible attributes should use jsonb (indexable with GIN, queryable with the full JSON operator set) and be modeled in the application layer. This package existing in the codebase is a signal of an aging schema, not a capability to extend.
• Tech-debt triage and migration sequencing. If hstore columns exist today, this becomes a tracked migration workstream: dual-write or backfill into jsonb, then drop the type dependency. That is a scoped, plannable task — not an open-ended refactor — which makes it easy to slot into a roadmap.
• Dependency-risk register. Last release 2014, 5 stars, 0 dependents, "Deprecated" in the package name. As a PM, this goes on the "do not adopt, plan to remove" list. Zero dependents also means no upstream community will fix it for you, and no security patch will ever arrive.
• Correcting a scoping assumption. This is a Symfony bundle built on Doctrine DBAL, not a Laravel/Eloquent package. It is not usable from a standard Laravel application. If the roadmap is Laravel-based, this package is out of scope entirely and the decision collapses to "use JSON columns with Eloquent casts or raw Postgres expressions." Worth flagging before anyone spends discovery time on it.

When to Consider This Package

Consider it only under a narrow, legacy set of conditions:

• You are maintaining an existing Symfony 2.x/3.x application on Doctrine DBAL 2.x (roughly PHP 5.6–7.x era) that already has hstore columns in production and needs to keep reading/writing them with minimal change.
• The work is short-lived maintenance, not new feature development, and the migration to jsonb is already scheduled.
• You need a stopgap to unblock a bug fix, and the team accepts the code will be vendored, patched locally, or forked — because no upstream support exists.

Look elsewhere (or build in-house) when any of the following is true:

• New project or new feature. Use jsonb and Doctrine's json/jsonb types, or Laravel JSON columns. There is no reason to introduce hstore in 2024+.
• Modern runtime. PHP 8+, Doctrine DBAL 3.x/4.x, or Symfony 5+. DBAL 3 reworked the Type interface and removed several legacy methods; a 2014-era type will not load or will fail unpredictably. Treat "does it even install?" as a hard gate, not a nice-to-have.
• Laravel. Wrong ecosystem — this is Doctrine, not Eloquent. Use $casts = ['meta' => 'array'] against a json column.
• You need maintained dependencies. Deprecated, abandoned, no security response path, no issue triage. In a regulated or audited environment this alone disqualifies it.
• You need nested or typed data. hstore's flat string map will force serialization hacks into and out of the column; jsonb avoids that entirely.
• You need indexing flexibility. hstore has GIN/GiST support, but the query operators are narrower and less familiar to engineers than JSON path operators — a real onboarding and hiring cost.

How to Pitch It (Stakeholders)

Recommendation: do not adopt; treat as legacy debt to remove.

For executives: this is an abandoned, ten-year-old open-source component — officially marked deprecated, five GitHub stars, zero projects depending on it, last release November 2014. Adopting it would create a permanent maintenance obligation with no upstream support and no security patch path. The underlying capability (flexible key-value attributes in Postgres) is now available natively and better via jsonb, which is built into the database and supported out of the box by every modern framework. Cost of the recommended path is small and bounded: if hstore columns exist, migration to jsonb is a scoped, estimated task; if they don't, the decision is simply "use jsonb," which costs nothing and removes a future liability. There is no scenario where adding this dependency is the cheaper option.

For engineering: the package's entire value is a DBAL type mapping hstore ↔ PHP array. That is a small, well-understood piece of code we can write and own in under a day if we ever truly need it — and we probably don't, because jsonb is the correct target. Two caveats to internalize: (1) this is a Symfony/Doctrine bundle, not a Laravel package, so it's inapplicable if we're on Eloquent; (2) it targets Doctrine DBAL 2.x and will not work cleanly on DBAL 3+ or PHP 8+, so "just install it" is not a viable shortcut even as a stopgap. Proposed next step: inventory any existing hstore columns, size the jsonb migration, and add this package to the do-not-adopt list in our dependency policy.