Full-text search
Search that indexes the words inside your content, matches word stems, and ranks by relevance instead of a literal 'LIKE %cat%' match.
See it
What it is
Full-text search builds an index of the individual words inside your content, not just the raw strings. Text gets tokenized, lowercased, and stemmed (so 'running' matches 'run'), stop words like 'the' get dropped, and the result is stored in an inverted index: word to list of documents. Queries hit that index and come back ranked by relevance.
Reach for it the moment 'WHERE body LIKE %cat%' stops being good enough: you want plurals, multiple words, phrase matching, and best-match-first ordering. Postgres does it natively with tsvector plus a GIN index, which is plenty for most apps. Dedicated engines like Elasticsearch, Meilisearch, and Typesense add typo tolerance, facets, and instant-as-you-type speed.
Gotcha: full-text search matches words, not meaning. Search 'cheap laptop' and a document saying 'affordable notebook' scores zero. That is what a vector database and semantic search are for, and the strongest setups run both and blend the scores. Second gotcha: the index is only as good as its language config, so indexing English text with the wrong dictionary quietly kills stemming.
Ask AI for it
Add Postgres full-text search to the articles table. Create a generated tsvector column combining title (weight A) and body (weight B) using the 'english' config, index it with GIN, and query it with websearch_to_tsquery so users can type quoted phrases and OR. Order results by ts_rank_cd descending, return ts_headline snippets with the matched terms highlighted, and add a pg_trgm similarity fallback on title so typos still return something. Keep it to one query, no extra service.