Postgres Search Bundle Laravel Package

Product Decisions This Supports

• Search backend selection — the "already own it" fork in the road. The real decision this package surfaces isn't "should we use this bundle" but "do we run a dedicated search engine (Elasticsearch/OpenSearch/Meilisearch/Algolia) or lean on PostgreSQL full-text search in the database we already operate?" PostgreSQL FTS via tsvector/tsquery and GIN indexes is the cheapest viable search tier: no new service, no data-sync pipeline, no second source of truth, and search results that are automatically consistent with your Doctrine/Eloquent entities. That comparison is worth running regardless of what you decide about the package itself.
• Build vs. buy vs. already-owned. This package represents the "already-owned" option at the small end of search requirements. A PM can anchor cost/benefit analysis on it: versus managed search (Algolia, Typesense Cloud — typically hundreds to low thousands per month plus integration), versus self-hosted (Elasticsearch — real on-call surface), versus a few days of in-house SQL.
• MVP scoping and the search-definition conversation. Whether search is launch-blocking or fast-follow, and critically what v1 search must do. If the requirement is "find the record containing this word, ranked sensibly," Postgres FTS covers it. If it is typo tolerance, faceting, synonyms, per-tenant isolation, or relevance tuning as a competitive differentiator, Postgres FTS does not cover it without substantial custom work. Forcing that conversation early is the highest-value output of this evaluation.
• Roadmap tiering with an evidence-based trigger. A defensible progression: ship Postgres FTS for v1 → instrument p95 query latency, zero-result rate, and search-session conversion → migrate to a dedicated engine only when the data justifies it. This package is the "v1" end of that spectrum.
• Use cases it maps to: internal admin/back-office search, catalog or document search at modest scale (hundreds of thousands to low millions of rows, read-heavy, low concurrency), and keyword filtering over structured data already living in Postgres.
• What it explicitly does not support for us: anything in a Laravel codebase. This is a Symfony 2 bundle targeting Doctrine 2, and Symfony 2 reached end-of-life in 2018 (full EOL November 2019). It cannot be dropped into a Laravel application; adopting it means adopting an unmaintained, EOL framework dependency. The package is a reference implementation for the pattern, not a candidate dependency.

When to Consider This Package

Consider it only if every one of the following holds:

• You maintain a legacy Symfony 2.x application on Doctrine 2 that is not migrating in the near term.
• Searchable content already lives in PostgreSQL, and you want a thin annotation/mapping layer over tsvector columns rather than hand-written DQL.
• You accept vendor-and-fork ownership, because the project has 0 stars and 0 dependents — no community, no issue triage, no security-response path, no meaningful maintenance signal.
• Relevance requirements are modest: exact or stemmed keyword matching with basic weighted ranking (setweight/ts_rank). No faceting, no typo tolerance, no synonyms, no multilingual analyzer story.
• Your supply-chain review permits an unsupported, effectively abandoned dependency (most will not).

Look elsewhere if:

• You are on Laravel — the framing of this evaluation. The framework mismatch alone is disqualifying. Use raw query-builder SQL (whereRaw("to_tsvector(...) @@ plainto_tsquery(?)") with bound parameters), a generated tsvector column plus GIN index migration, an Eloquent local scope or SearchRepository, or a maintained option — Laravel Scout with a Postgres-compatible driver — rather than a Symfony bundle.
• You are on Symfony 4/5/6/7. The bundle targets Symfony 2 and Doctrine 2 bundle conventions; expect breakage. Prefer maintained alternatives or a small owned service around doctrine/dbal.
• Search quality is a product differentiator (e-commerce, marketplace, content discovery). Postgres FTS hits a relevance ceiling fast; budget for Meilisearch, Typesense, OpenSearch, or Algolia.
• You need scale headroom, faceted navigation, or per-tenant index isolation.
• Your org requires maintained dependencies with a named owner upstream. Zero stars, zero dependents, and an EOL framework fail this test by definition.

Verdict: Not adoptable as a dependency. The pattern — PostgreSQL native full-text search — is worth a short design spike. This package is a reference implementation to read, not install.

How to Pitch It (Stakeholders)

To executives: We evaluated a package for adding full-text search on top of PostgreSQL. The strategic takeaway is favorable on cost: if our search needs are simple keyword matching, we can ship search on the database we already run — no new vendor contract, no new infrastructure, no new operational burden, no second copy of our data to keep in sync. That is a meaningful line-item saving versus managed search services, which typically run from hundreds to thousands of dollars per month before integration work, and versus self-hosted Elasticsearch, which carries real on-call cost.

The specific package reviewed, however, is not viable for our stack. It is a Symfony 2 bundle built for Doctrine 2 — Symfony 2 has been end-of-life since 2018 — and it has zero stars and zero dependents, meaning no community, no maintenance, and no security-patching path. Recommending it would introduce an unmaintained, unpatched dependency into our application in exchange for roughly a few days of code we can write and own ourselves. Recommendation: reject the package, retain the architectural option. Proceed with the PostgreSQL approach implemented natively in Laravel behind a thin, owned SearchService abstraction, and set a measurable trigger — p95 latency or relevance complaints — for revisiting a dedicated engine with real data rather than speculation.

To engineering: Don't take the dependency. Its value is a mapping layer over tsvector columns plus DQL helpers — a small surface we can replicate with a generated tsvector column (Postgres 12+), a GIN index migration, an Eloquent scope using parameterized to_tsvector/plainto_tsquery (or websearch_to_tsquery on 11+), and ts_rank_cd as a select alias for ordering. Treat the repository as a reference implementation: read it for SQL patterns, do not install it, and avoid copying source verbatim without checking its license — a clean reimplementation from documented PostgreSQL patterns avoids that obligation entirely. Flag for the spike: dictionary/regconfig selection (pin per column if multilingual), weight classes (title vs. body), index bloat and VACUUM/REINDEX hygiene, work_mem tuning under realistic load, and query-plan validation at production-like data volume. Add a fixed query corpus as a CI regression test so relevance degradation after Postgres upgrades is caught rather than discovered by users. If the spike shows requirements exceed Postgres FTS, fall back to Scout plus a dedicated driver — and we'll then have the latency and quality baselines needed to justify that spend.