Postgres Search Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for search — the "no new infrastructure" option. The core decision this package informs is whether to satisfy search with PostgreSQL full-text search (tsvector/tsquery, GIN indexes, ts_rank) wired into Doctrine, or to add a dedicated engine (Elasticsearch/OpenSearch, Meilisearch, Typesense, Algolia). This bundle is the archetype of the first path: it moves the decision from "do we stand up a search cluster?" to "do we add ~a few hundred lines of Doctrine plumbing?"
• MVP scoping and sequencing. For an early-stage product, this represents the cheapest credible search feature: keyword search, basic relevance ordering, highlighted excerpts, and language stemming via Postgres dictionaries — shippable inside an existing sprint without a search specialist, a new ops surface, or a data-sync pipeline.
• Make vs. adopt for a narrow capability. Given 0 stars, 0 dependents, and a last release of 2016-09-06, the realistic PM decision is not to take the dependency. The value is as prior art: a 1–2 day engineering spike to read how it registers tsvector columns, GIN indexes, custom DQL functions, and tsquery construction, then reimplement the useful 10% internally. This is a fork-the-ideas, not fork-the-repo, decision.
• Legacy platform triage. A Symfony2 bundle last released in 2016 is a proxy signal that the host app predates Symfony 3.4's end of life. If it shows up in a dependency audit, the PM-level action is a platform modernization item, not a feature item.
• Roadmap triggers for graduating off Postgres FTS. Adopting this approach defines the exit conditions worth committing to in advance: cross-language relevance tuning, typo tolerance, faceting, synonyms, per-tenant ranking experiments, or search traffic that competes with OLTP write load. Documenting those triggers now prevents an accidental permanent commitment to a stopgap.
• Dependency-policy precedent. It serves as a concrete case for a written rule: no unmaintained packages for capabilities on the critical path; vendored/adapted code must have an internal owner.

When to Consider This Package

Consider the approach (not necessarily the package) when:

• The application is on Symfony 2.x with Doctrine 2 ORM and PostgreSQL, and is in maintenance mode — the ecosystem match is the only scenario where the bundle's original API surface is even plausible.
• Search requirements are keyword matching with relevance ordering, not semantic or faceted discovery.
• The team has no appetite for a second datastore, and data volume fits comfortably in Postgres with a GIN index.
• Postgres's built-in dictionaries cover the required languages, or the corpus is monolingual.
• You need a reference implementation for a spike and are prepared to own the resulting code.

Look elsewhere when:

• You are on Symfony 3.4+/4/5/6/7, PHP 8, or Doctrine ORM 2.10+/3.x. The bundle's Doctrine and Symfony integration points are from a 2016 toolchain; expect incompatibility rather than a version bump.
• You need typo tolerance, fuzzy matching, synonyms management, faceting, or A/B-tested ranking — these are the features that justify a real search engine, and retrofitting them onto tsquery is where the "cheap" option stops being cheap.
• Search must scale independently of the primary database or absorb heavy query load without impacting transactional latency.
• No one on the team can own forked code, or your policy forbids unmaintained dependencies on a customer-facing path.
• Alternatives to evaluate instead: direct native SQL via Doctrine's NativeQuery/ResultSetMapping (the pragmatic default), a maintained Postgres-FTS Doctrine extension, or a managed engine (Meilisearch/Typesense for low-ops simplicity, OpenSearch/Elasticsearch for scale and relevance control).

How to Pitch It (Stakeholders)

To executives: We evaluated a package for adding search to the product and are recommending against adopting it as a dependency — it targets Symfony 2, has had no release since 2016, and has no downstream users, so any defect or security issue becomes ours to fix. The underlying idea is still the right call for now: PostgreSQL, which we already run, can deliver keyword search with relevance ranking, so we can launch search without a new infrastructure line item, a new vendor contract, or a data-sync pipeline — an estimated 1–2 sprint effort for a small internal implementation based on this package's design. I'm also proposing we decide up front what would make us graduate to a dedicated search engine (multilingual relevance, typo tolerance, faceting, or search load affecting checkout-path latency), so this stays a deliberate stopgap rather than an accidental permanent commitment. Risk is bounded and reversible: the data stays in Postgres, and a future migration to a dedicated engine is additive.

To engineering: Treat this repo as a design document, not a dependency. Read it for the tsvector column and GIN index modeling, the custom DQL function wiring for to_tsquery/ts_rank, and how it handles result highlighting. Then build a thin internal adapter with explicit ownership: parameterized tsquery construction (no string concatenation — injection surface), index-maintenance strategy on write, and tests that assert ranking stability rather than exact scores. Budget 1–2 days of spike plus the sprint to productionize, and capture it as internal code we control.