A search box is almost always a single sentence in a brief: "and it should be searchable too". In reality it's one of the parts of an application where what the client imagines differs the most from what can realistically be built, and where it's most commonly underestimated that search itself is only half the job. The other half is knowing whether it worked well.
When a plain query is enough
Not every application needs a dedicated search tool. If a table holds hundreds to low thousands of records and you're searching for exact or near-exact text — a customer name, an order number, a product code — a plain database query (SQL LIKE or its equivalent) is enough and is the simplest thing to maintain.
The problem shows up when any one of three things is true:
- volume — tens of thousands to millions of records, where
LIKEstops being fast, - typos and word forms — a user types "invoic" and expects to find "invoice", or a form in an inflected language,
- relevance — with several matches you need to know which one matters most, not just that it matches.
What full-text search actually solves
Full-text search (Postgres tsvector, Elasticsearch, Meilisearch, Algolia) splits text into words, ignores common connectors, understands word forms, and can rank which document matches best. That's exactly what LIKE can't do — it matches a literal string, not meaning.
The difference is noticeable the moment there's a typo, or when searching free text like a product description or a document's contents. For structured fields — a date, a status, a category — full-text search solves nothing; that's what a filter is for, not search.
| Situation | The right tool |
|---|---|
| An exact ID, code, order number | a database query |
| A name with typos or inflected forms | full-text search |
| Date, status, category, a price range | a filter |
| Free text in descriptions or documents | full-text search |
| "Find me contracts similar to this one" | semantic search (embeddings) |
A filter and search solve different problems
A common design mistake is trying to solve both with one field. A filter narrows precisely — "orders from the last month with status completed" has an unambiguous answer, and the user knows what they'll get. Search answers an uncertain, imprecise question — the user isn't sure of the exact wording, only roughly what they're looking for.
Good design combines both: filters as separate, clearly labelled controls, and a search field for free text alongside them, not instead of them. When a filter gets hidden inside the search field ("status:completed date:2026"), the user has to know a syntax nobody explained to them.
How you know search is working well
Relevance can't be estimated at design time, only measured after launch. Three signals worth tracking:
- Queries with no results. If the same thing gets searched repeatedly and the system finds nothing, either the data is missing or search doesn't understand how people phrase it.
- Repeating a search with a different term. If a user searches "invoice", doesn't find what they want, and immediately tries "bill" or "receipt", that's a signal the first attempt failed — even if it formally returned results.
- What gets clicked. If people almost always click the third or fourth result instead of the first, the relevance ranking is set up wrong.
Without this measurement, search gets tuned by feel, and the builder's feel systematically differs from an ordinary user's experience — the builder knows what they're looking for and phrases it differently.
Where AI fits in
Semantic search and RAG (retrieval-augmented generation) answer a different question from classic full-text — not "find this exact string" but "find things that are similar in meaning, even if they used different words". That's useful when searching documentation, or for a question like "which contracts have similar terms to this one", where an exact text match solves nothing.
But it isn't a replacement for ordinary search — it's a complement for a different category of query. A system that needs to find order number 48213 exactly doesn't need semantic search, it needs an index on a column. We covered the principle and the limits of semantic search over company data in our article on RAG and company documentation.
What to settle before designing it
- What volume of data will be searched, and how fast it's growing.
- What kinds of queries are actually expected — exact IDs, free text, or both.
- Which fields belong in a filter and which in free-text search.
- How you'll measure whether search is working — without this, tuning can't be verified.
- How often the data changes, since a full-text index needs updating continuously as data changes, not building once.
Summary
Search in a business application isn't one feature — it's a choice between three tools, a database query, full-text search, and filters, depending on the kind of question the user is asking. Quality can't be estimated at design time, only measured after launch, through empty results and repeated searches.
Which specific tool to pick depends on data volume, query types, and maintenance budget. If you're working through search in your own application, we'll go through your specific situation in a no-obligation consultation, or take a look at our development solutions.