In-product search usually starts as a LIKE query against a name column, which works for the person who knows exactly what the item is called and fails for everyone else. That gap is the entire problem: users type approximations, synonyms, misspellings, plurals and partial memories, and the database holds precise strings. Search is the work of connecting the two.
The first improvements are the cheapest. Stemming, so that running matches run. Case and accent folding. Tokenisation that handles hyphens and punctuation sensibly. Stop-word handling. A full-text index rather than a LIKE with leading wildcards, which cannot use an index at all and degrades linearly with table size. PostgreSQL's built-in full-text search covers all of this and is enough for a great deal more than teams assume before reaching for a separate search engine.
Then comes ranking, which is where perceived quality actually lives. Two documents matching a query are not equally good answers, and the ordering determines whether users think your search works. Weight fields differently - a match in a title should outrank one in a long description. Boost by business signals: popularity, recency, whether the item is in stock. A technically correct result set in an unhelpful order reads to a user as broken search.
Handle the ways users get it wrong, because they are the majority of failing queries. Fuzzy matching for typos, bounded by edit distance so it does not return nonsense. A synonym list, which is unglamorous manual work and often the single highest-return thing you can do - your users say laptop and your catalogue says notebook. And multi-word queries need a decision about whether all terms must match or some, with the honest answer usually being that requiring all is too strict and requiring any is too loose, so rank by how many matched.
The instrumentation that makes search improvable is a log of queries and what happened next. Specifically: queries returning zero results, and queries where nobody clicked anything. Those two lists are a prioritised backlog written by your users - the zero-result list tells you what vocabulary you are missing, and the no-click list tells you where ranking is wrong. Teams that add this find the first hundred fixes obvious.
Semantic and vector search is worth considering once the above is done, not before. It genuinely helps where the user's words never appear in the document - searching for a concept rather than a term - and it is a poor substitute for correct stemming and a synonym list. In practice the strongest results come from hybrid retrieval: keyword matching for precision, vector similarity for recall, combined and re-ranked. Starting with the vector half alone tends to produce search that feels clever and misses exact matches, which users find more annoying than the original problem.
