Postgres Search Bundle Laravel Package

Technical Evaluation

Framing correction (decision-relevant): the request describes this as a "Laravel/PHP package." It is not. alsatian/postgres-search-bundle is a Symfony bundle built on Doctrine ORM/DBAL. The dominant finding of this assessment is that the delivery vehicle — not the search pattern — determines whether this is usable. Any ticket scoped as "evaluate for the Laravel app" should be rewritten before estimation.

Architecture fit

• The underlying pattern is legitimate: PostgreSQL native full-text search (tsvector/tsquery, GIN indexes, setweight field boosting, ts_rank_cd, websearch_to_tsquery) is a credible tier-1/tier-2 replacement for Elasticsearch/Algolia/Typesense at low-to-mid corpus sizes and moderate QPS.
• The bundle's natural extension points (bundle registration, DI service wiring, custom DQL function registration) only activate inside a Symfony kernel with Doctrine.
• In a Laravel/Eloquent codebase, the bundle's classes are inert. You would be consuming the design, not the code — realistically a few hundred lines of SQL and query-builder patterns.
• Net fit: good for Symfony + Doctrine; poor for the stated Laravel context; neutral as a reference implementation for a port.

Integration feasibility

• Laravel, install-as-dependency: near-zero. Not feasible without adopting laravel-doctrine, which is a much larger architectural commitment than the search feature justifies.
• Laravel, port-the-pattern: 3–10 engineering days for a single-table v1 with weighted vectors, GIN index, and ranked queries.
• Symfony, install-as-dependency: hours mechanically — Composer, bundle registration, config — but gated by unvetted-maintainer risk below.

Technical risk

Key questions (gate items before pilot approval)

1. Last commit date, release cadence, CI status, test coverage, license?
2. Declared constraints: PHP, PostgreSQL, Doctrine ORM versions?
3. Does it emit parameterized tsquery predicates, or concatenate user input?
4. Does it manage migrations/GIN index creation, or expect the DBA to?
5. Generated column vs. trigger vs. functional index — which maintenance model does it assume?
6. Who is the named internal owner of the fork, and what is the exit criteria back to a managed engine?

Integration Approach

Stack fit matrix

Migration path

• Symfony target: composer require, register the bundle, configure searchable fields, then immediately move to a stored tsvector column with a GIN index and DB-trigger maintenance. Do not ship on-the-fly to_tsvector in WHERE clauses — it forces sequential scans.
• Laravel target: do not install. Reimplement the narrow surface you need: a search_vector column, a trigger or model observer, a GIN index, and a query scope using whereRaw("search_vector @@ websearch_to_tsquery(?, ?)") with bound parameters. This is the recommended path and is smaller than the integration work to make Doctrine fit.
• Fork path: copy the DQL function classes into app/Doctrine/Functions and own them. This converts an unmaintained dependency into ~200 lines of first-party code with no supply-chain exposure.

Compatibility checks to schedule

• PostgreSQL ≥ 11 for websearch_to_tsquery; ≥ 12 if generated columns are preferred over triggers.
• Doctrine ORM 2.x vs 3.x — custom function base-class signatures differ.
• PHP version floor; ext-pdo_pgsql.

Sequencing (recommended)

1. Spike, 3–5 days. Read the DQL function generators, dump the emitted SQL, run EXPLAIN ANALYZE in psql, and complete the injection review. Output: an ADR — adopt, fork, port, or reject.
2. Vendor or reimplement the minimal surface (week 1–2). Add contract tests that run against real PostgreSQL in CI.
3. Single-table pilot with weighted vector (title = A, body = B), GIN index, trigger maintenance, pagination.
4. Instrument zero-result rate, p50/p95 latency, and top queries — these are the artifacts that fund or kill tier 3.
5. Re-evaluate tier 3 (typo tolerance, synonyms, semantic via pgvector or Meilisearch) against that data, not against intuition.

Operational Impact

Maintenance. The bundle is unmaintained in practice; adoption means the team owns it. Budget a named owner, an in-repo fork, and a quarterly review against Doctrine/PHP upgrades. Realistic ongoing cost is low (small surface, few hundred lines) but non-zero — this is the trade for avoiding a vendor contract.

Support. No vendor, no SLA, no security-review trail, no community triage. Escalation is entirely internal, which means on-call needs PostgreSQL full-text competence, not just Laravel/Symfony competence. Document this in the runbook before launch, not after.

Scaling. Comfortable territory is low tens of millions of rows with well-chosen GIN indexes and read-heavy, modest-QPS traffic. Watch for: GIN write amplification on hot tables, index bloat requiring REINDEX/VACUUM policy, and planner regressions where the index silently stops being chosen (sequential scan latency cliff). Benchmark write paths before committing a high-write entity to a maintained tsvector.

Failure modes to design against

• Language mismatch between column, index, and query → silent empty result sets with no error. Test with fixtures.
• NULL source columns omitted from COALESCE → rows silently dropped from @@ comparisons.
• Bulk createQuery()->execute() bypasses Doctrine lifecycle callbacks → stale vectors. Use DB triggers.
• Malformed user input through to_tsquery → uncaught exception → 500s. Use websearch_to_tsquery for anything user-supplied.
• Doctrine upgrade breaks custom DQL functions at boot, not at query time — pin and test.
• SQLite-based test suites fail or skip silently; require real PostgreSQL in CI or the search branches are never validated.

Ramp-up. An engineer fluent in PostgreSQL FTS needs ~1–2 days; a Laravel-only engineer needs ~1 week plus a reference implementation. The bundle's real value to the org is as that reference — a worked example of Doctrine-side search modeling that shortens a port.

Cost position. Near-zero marginal infrastructure and no search-SaaS line item, offset by a small, permanent engineering ownership cost and a hard capability ceiling (no typo tolerance, no synonyms, no faceting, no semantic retrieval). State that ceiling in the feature's acceptance criteria before launch so expectations are set with stakeholders rather than discovered at demo.