Doctrine Full Text Postgres Laravel Package

Product Decisions This Supports

• Build vs. buy for search: This package is the cheapest credible path to native PostgreSQL full-text search (tsvector/tsquery, ts_rank, ts_headline) from a Doctrine ORM codebase. It informs whether we ship search as a Postgres feature or fund a separate search service (Elasticsearch, OpenSearch, Algolia, Typesense).
• Search roadmap sequencing: Enables a "good enough search now, relevance platform later" roadmap. We can ship keyword search, stemming, and ranked results in a sprint or two instead of a quarter, and defer the dedicated search infra decision until volume or relevance requirements justify it.
• Scope of the first search release: Helps define MVP boundaries — single-language keyword search, relevance ordering, highlighted excerpts — versus what we explicitly defer (faceting, synonyms, typo tolerance, cross-field boosting, multilingual analysis).
• Total cost of ownership comparison: A native Postgres approach avoids a new managed service, a second datastore, index sync pipelines, dual-write consistency problems, and on-call surface area. This is a materially smaller operational and infra bill than standing up a search cluster.
• Data model and migration decisions: Mapping a generated tsvector column with a GIN index is a schema-level commitment. This package affects whether search lives as a first-class column (indexable, transactional, always consistent) or as an external index (eventually consistent).
• Vendor/exit risk planning: With ~17 stars, 0 dependents, and a last release in October 2021, adoption is a small-bet decision requiring a fork-and-own contingency rather than a strategic platform bet.
• Use cases it credibly serves: internal admin search, back-office tooling, content/document search over modest corpora, MVP customer-facing search, and filtering on already-relational data where relevance tuning is not yet a differentiator.

When to Consider This Package

Adopt (or, more precisely, spike) when all of the following hold:

• The stack is Laravel/PHP on Doctrine ORM with PostgreSQL — the package is a Doctrine type/function extension, so it delivers value only inside that combination.
• Search requirements are keyword-oriented: lexical matching, stemming via a Postgres text search configuration, relevance ranking, and snippet highlighting.
• The corpus is modest to moderate (roughly low millions of rows or fewer) and query latency targets are sub-second, not sub-100ms at high concurrency.
• Data consistency matters — you want search results to reflect writes immediately, transactionally, without a sync pipeline.
• The team accepts fork-and-own: you or your engineers will vendor the package, verify compatibility with current PHP/Doctrine versions, and maintain it.
• You want time-to-market over relevance sophistication, and can articulate the migration trigger to a dedicated search engine later.

Look elsewhere when any of the following apply:

• Active maintenance is a hard requirement. No release since 2021 means PHP 8.2/8.3 and Doctrine ORM 3 compatibility are unverified; expect breakage and budget a spike to confirm.
• Ecosystem validation matters. Zero dependents and single-digit stars mean no community safety net, no CVE response, and thin documentation.
• Requirements include faceting, fuzzy/typo tolerance, synonyms, custom analyzers, multilingual stemming beyond Postgres dictionaries, or learning-to-rank. These are where Postgres FTS and this wrapper stop being competitive.
• Very high write throughput — a tsvector column plus GIN index adds write amplification and vacuum pressure.
• The stack is Eloquent-first; you would be introducing Doctrine solely to use this package, which is a poor trade.
• You need sub-100ms latency at high QPS with complex relevance, or search across non-Postgres data sources.

Also note: implementing the underlying Postgres FTS directly with raw SQL or a lightweight custom Doctrine type is a realistic alternative — the package's value is convenience, not unique capability, so "build a 200-line internal equivalent" is a genuine competing option.

How to Pitch It (Stakeholders)

Executive summary: We can deliver working, ranked full-text search on our existing PostgreSQL database without procuring a new search service, without a second datastore, and without an index-sync pipeline. That translates to weeks rather than a quarter, and near-zero incremental infrastructure spend — the primary trade-off is relevance sophistication and a small long-term maintenance obligation.

For engineering: vertigolabs/doctrine-full-text-postgres provides Doctrine mapping and DQL function support for Postgres tsvector/tsquery, giving us generated columns, GIN indexing, ranking, and headline extraction through the ORM instead of hand-rolled SQL. It is small, narrow, and easy to reason about — but it is effectively unmaintained (last release October 2021, no dependents), so we should vendor it, run a compatibility spike against our PHP and Doctrine versions, and treat it as internal code we own. Exit cost is low: the schema-level artifacts (column, index, queries) are plain Postgres and survive any ORM-layer replacement.

Risk framing, stated plainly: Low adoption and stale releases mean no support channel and no security response — acceptable for a convenience wrapper, unacceptable as a load-bearing platform dependency. Recommendation: time-boxed spike, vendor the code, document the migration trigger (relevance complaints, faceting requirements, or latency at scale) that would move us to a dedicated search engine.