Postgres Full-Text Search

• CategoryDatabase-native FTS
• EnginePostgres
• PricingOpen source
• LicensePostgreSQL License
• Created2008
• GitHub starsclosed
• Vector supportYes
• Edge-readyNo

Postgres has had built-in full-text search since 2008 with tsvector / tsquery. GIN indexes, ranking with ts_rank, multi-language stemming via dictionaries. Pair with pg_trgm for fuzzy / typo tolerance and pgvector for hybrid lexical+vector. Not as fast as dedicated engines but sufficient for most apps.

• Apps already on Postgres where adding a search service is overhead
• Mid-scale workloads (under ~10M rows) where Postgres performance suffices
• Hybrid lexical + vector search via pg_trgm + pgvector + tsvector together
• Cost-conscious teams that want zero additional infrastructure

Skip Postgres FTS for genuine search-product workloads (e-commerce search, content search at scale). Skip if you need typo tolerance comparable to Algolia / Meilisearch.

Postgres FTS is underrated. For most apps with Postgres in the stack, it is a fine default. Graduate to Typesense / Meilisearch when search becomes a real product feature rather than a side concern.

The setup worth copying is a stored generated column: a tsvector built from your text fields with setweight applied per field so a title match outranks a body match, backed by a GIN index, queried with websearch_to_tsquery so user input containing quotes and negation parses without you writing a parser. Rank with ts_rank_cd rather than ts_rank when phrase proximity matters. Add pg_trgm with its own GIN index for fuzzy matching on names and short fields, which is how you get something resembling typo tolerance. For semantic retrieval, pgvector lives in the same table, and you can combine the lexical score with vector distance in a single query using reciprocal rank fusion, no second system involved. On Supabase all of this is available without leaving the project you already have, which is precisely why so many builds never need a search service.

Three things push you off Postgres full-text search. Relevance ceiling first: ts_rank understands term frequency and position, not click behaviour, business rules or field boosting beyond four weight classes, so merchandising requests eventually exceed it. Second, a GIN index on a write-heavy table adds real write amplification, and its pending-list behaviour makes update latency lumpy under load. Third, and usually the actual trigger, search queries and transactional queries compete for the same buffer cache and the same connection pool, so a slow search becomes a slow checkout. The exit is cheap if you plan for it. Keep Postgres as the source of truth and push a denormalised projection into Typesense or Meilisearch through logical replication or an outbox table. None of the modelling work is wasted, you simply stop serving queries from the primary.

• Official homepage →

The 30-min call is where your search choice becomes a real architecture, a relevance-tuning plan, and a price range you can take to your stakeholders.