Postgres Search Bundle Laravel Package

Product Decisions This Supports

• Search scope for v1. Choosing native PostgreSQL full-text search over a dedicated engine sets a defensible first-release bar: exact and prefix keyword matching, field weighting (title over body), stemming/stop-words via Postgres dictionaries, and relevance ranking through ts_rank. It explicitly does not buy typo tolerance, synonyms, faceting, highlighting, or semantic retrieval — so this package anchors a realistic "search v1" promise instead of an aspirational one.
• Build vs. buy on search infrastructure. The real decision is "Elasticsearch/OpenSearch/Algolia/Typesense vs. the database we already operate." This is the own-the-database option: it removes most of the Doctrine/DQL boilerplate that pushes teams toward a search SaaS by default.
• Roadmap sequencing. It supports tiered search planning — (1) keyword/prefix, (2) weighted ranking and index tuning, (3) typo tolerance/synonyms, (4) semantic/hybrid — with a credible "tiers 1–2 now, tier 3+ later via pgvector/Meilisearch" narrative that doesn't require rewriting the query layer.
• Evidence-based deferral of spend. Shipping Postgres FTS first generates query logs, zero-result rates, and latency data that make a later vendor decision data-driven rather than guessed.
• Fits well: CMS/article search, internal admin and back-office search, documentation search, catalog keyword search at moderate scale, and "filter + rank" over tables you already index.
• Two caveats that shape the decision. First, this is a Symfony bundle built on Doctrine ORM, not a Laravel/Eloquent package — in a Laravel codebase its value is as a reference design to port, not a dependency to install. Second, with no stars, no dependents, and no community, the honest product decision it informs is: "Postgres FTS, yes; this artifact as a maintained strategic dependency, no."

When to Consider This Package

Consider it when:

• Your stack is PHP + Doctrine ORM — realistically Symfony, since this is a Doctrine bundle. Laravel teams on Eloquent are a poor fit unless they have deliberately adopted laravel-doctrine.
• You want generated tsvector columns, GIN indexes, weighted field sets, and to_tsquery/ts_rank query building without hand-rolling custom DQL for every query.
• You're cost- and ops-sensitive: no new cluster, no new on-call surface, no per-search vendor billing.
• Data volume sits comfortably in Postgres FTS territory (roughly low tens of millions of rows with well-chosen indexes) and traffic is read-heavy but modest.
• You need a reference implementation more than a library — the value is seeing how someone else modeled searchable fields, index maintenance, and ranking in Doctrine.
• You are prepared to vendor or reimplement the small surface you actually use (~a few hundred lines) and own it in-repo.

Look elsewhere when:

• Your application is Laravel/Eloquent. Use the underlying SQL patterns (tsvector/tsquery, GIN indexes, setweight, websearch_to_tsquery) inside a thin service layer with DB::raw, or evaluate Laravel-native options such as Scout with a Postgres driver, Meilisearch, or Typesense. Consume ideas from this package, not code.
• You need typo tolerance, synonyms, faceting, highlighting, multi-language relevance tuning, or semantic/hybrid retrieval — go to Meilisearch, Typesense, OpenSearch, or pgvector.
• You require multi-database portability (MySQL/SQLite), which rules out tsvector entirely and breaks common Symfony test setups that run against SQLite.
• You need vendor support, an SLA, or an audit trail. Zero stars, zero dependents, and a single-maintainer bus factor mean you own the fork the moment you adopt it.
• Your search surface is high-QPS or heavily write-amplified; index maintenance cost needs benchmarking before commitment.

Due diligence before any pilot: last commit date, CI status, test coverage, Postgres/Doctrine/PHP version constraints, license, how index creation is handled in migrations, whether the SQL uses safe parsing (websearch_to_tsquery/plainto_tsquery) versus string-concatenated user input, and whether custom DQL functions survive a Doctrine major-version upgrade.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can ship ranked keyword search on the database we already run — no new vendor contract, no new infrastructure to operate, near-zero marginal cost. The approach is standard PostgreSQL full-text search; the package in question is thin Doctrine plumbing that saves boilerplate, and it is unmaintained with essentially no adoption, so we should treat it as a reference design we fork and own (a few hundred lines) rather than a dependency. Net effect: search capability in days rather than weeks, a fully reversible decision, and a clear evidence base if usage later justifies a dedicated search engine.

For engineering: This is a Symfony/Doctrine bundle, not a Laravel package — in our Laravel codebase the deliverable is a port of its tsvector column, setweight field boosting, GIN index, and ranked-query patterns into a small in-house service. Use websearch_to_tsquery or plainto_tsquery for user input (never string-concatenated to_tsquery), store the tsvector in a maintained column rather than computing it per query, wrap nullable columns in coalesce, and prefer DB triggers over Doctrine lifecycle callbacks since bulk updates skip listeners. If we do touch the bundle directly, review its generated SQL, pin versions, and re-test on Doctrine upgrades.

For product/finance: This avoids a search SaaS line item and an ops burden at current scale, and it gives us real query and zero-result data before we commit to anything recurring. The trade-off is a capability ceiling — no typo tolerance, synonyms, or semantic search — and that ceiling must be written into the search feature's acceptance criteria so expectations are set before launch, not after.