How to Add Search to an AI-Built App
Search is not one feature, it is three: exact filters, full-text search, and semantic search. Picking the wrong one is why search feels broken.
Search feels like a small feature until you build it. The actual decision is not whether to add a search box, it is which of three genuinely different technologies sits behind it, and that choice depends entirely on what your users are searching for: exact values, loose text, or meaning and intent.
Three kinds of search, and they are not interchangeable
Type | Good at | Bad at | Backing tech |
|---|---|---|---|
Exact match / filter | Status = "active", price < 50, exact SKU lookup | Anything fuzzy or typo-tolerant | Plain SQL WHERE clauses |
Full-text search | Finding documents containing specific words, typo tolerance, ranking by relevance | Understanding meaning or synonyms it wasn't told about | Postgres full-text search, or a dedicated engine like Elasticsearch or Algolia |
Semantic / vector search | "Find me something like this", meaning-based matches, synonyms it was never told about | Precise exact-value lookups, and it is the most expensive to run | Embeddings plus a vector index, like pgvector |
Most apps that get search wrong picked one of these when they needed a different one, usually because they defaulted to whatever was easiest to bolt on rather than what the query actually was. A product catalog where users type partial names needs full-text. A support tool where users describe a problem in their own words and expect it to find the relevant help article, even when they used different words than the article, needs semantic search. Most real apps end up needing a mix, not one universal answer.
Start here: do you even need more than a filter
Before reaching for a search engine, check whether the real need is filtering, which is much simpler and already sitting in your database. "Show me orders from this customer over $100" is a filter, not a search problem, and building semantic search for it is solving a problem nobody has. Reserve real search for free-text queries, where the user is typing words, not selecting from known fields.
Full-text search: the default for most apps
If your app has a database with the content you want searchable already living in it, Postgres full-text search is usually the right first move, because it requires no new infrastructure and covers the large majority of real search needs: articles, products, tickets, comments, anything where users search by typing words that are likely to actually appear in the content.
Add a `tsvector` column to the table holding the searchable text, generated from the columns you want indexed.
Create a GIN index on that column so lookups stay fast as the table grows.
Query with `to_tsquery` or the simpler `plainto_tsquery` for raw user input, and use `ts_rank` to order results by relevance rather than just returning an unordered match list.
This covers typo-light, keyword-based search well. It does not understand that "cheap" and "affordable" mean the same thing unless you configure a thesaurus dictionary for it, which is more setup than most apps need on day one.
Semantic search: when meaning matters more than exact words
Semantic search works by converting text into embeddings, numeric vectors that place similar meanings near each other in space, then finding the nearest vectors to a query. This is what lets a search for "lightweight laptop for travel" match a product described as "thin, portable notebook" with no shared words at all. See what is an embedding in AI for how the underlying representation works.
The practical setup: generate an embedding for each searchable item using an embedding model API, store the vectors in a database with vector support, most simply pgvector if you are already on Postgres, then at query time embed the user's search text the same way and find the nearest stored vectors. The extra cost is real: an API call per item to embed it, storage for the vectors, and slightly more complex infrastructure than a plain SQL query. Reserve it for cases where meaning-based matching is the actual point, like support search or recommendation, not for a straightforward product catalog where users mostly know what they are looking for.
A practical default: combine both
A common, effective pattern is hybrid search: run both full-text and semantic search on the same query, then merge and re-rank the results. Full-text catches exact terms and specific model numbers reliably, semantic search catches the queries where the user's words do not match the content's words. Neither alone covers both cases well, and most production search systems that feel "smart" are running some version of this combination rather than pure semantic search on its own.
What to actually build, by app type
App type | Start with |
|---|---|
Internal admin tool, small dataset | Plain SQL filters, add full-text only if users ask |
Content site, blog, docs | Full-text search, it is usually sufficient on its own |
Support or knowledge base | Hybrid: full-text plus semantic, since users phrase problems differently than the docs do |
E-commerce catalog | Full-text for product names and SKUs, semantic as a secondary "similar items" feature |
This same reasoning extends what is covered in do I need a backend for my app: search is a backend-and-database decision before it is a UI decision, and picking the UI first tends to produce a search box that does not match what it is searching.
Once search is working, the rest of the build follows the same shape as how to add an admin dashboard to an AI-built app and the other feature guides under how to build an app with AI: scope the one feature clearly, pick the right underlying technology for the actual use case, and let an AI coding agent implement it against that decision rather than against a vague "add search" prompt.
FAQ
Can an AI coding agent set up pgvector and embeddings for me?
Yes, once you have decided that semantic search is actually the right tool. Give it the specific decision, not just "add search," and it can scaffold the embedding pipeline, index, and query correctly.
Is semantic search always better than full-text?
No. It is better for meaning-based queries and worse for precise exact-value lookups, and it costs more to run per query. Picking it by default for everything is a common and expensive mistake.
Do I need a separate search service like Algolia or Elasticsearch?
Not usually, for small to mid-size apps. Postgres full-text and pgvector cover most real workloads without adding a new service. Reach for a dedicated search engine once you have scale or relevance-tuning needs that outgrow what the database can do directly.
How do I handle typos in full-text search?
Postgres full-text search has some built-in tolerance through stemming, but for real typo-tolerance add a trigram index (`pg_trgm`) alongside it, which matches on partial character overlap rather than whole words.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
