Search that finds what people meant
Meilisearch or Elasticsearch, tuned to your catalogue
A database LIKE query is not search, and most sites that feel hard to find things on are running one anyway. We set up Meilisearch or Elasticsearch, tuned for typo tolerance, filters and ranking that matches how your users actually type, not how your schema happens to be structured.
What it is
Search infrastructure is a separate, purpose-built index that answers “find things matching this” far better than a database query ever can: it tolerates typos, understands that “sneaker” and “trainer” might mean the same thing to your users, ranks results by relevance rather than insertion order, and supports filtering by multiple attributes at once without the query getting slow as the catalogue grows. Meilisearch and Elasticsearch are the two tools we use most, chosen based on scale and complexity, not a default preference.
When you need it (and when you do not)
You need this once your site or app has enough items, products, listings, articles, archaeological records, that a simple exact-match query misses what users actually mean, misspells a brand name, searches by a feature instead of a title, or gets zero results for something that clearly exists in the catalogue. It is also the right build once filtering by multiple attributes at the same time, price range and category and availability, starts making your database queries slow or your application code unmanageable.
You do not need dedicated search infrastructure for a catalogue small enough that a simple filtered list or a basic database query already performs well and returns reasonable results, adding Elasticsearch for forty products is solving a problem you do not have yet.
How we build it
We default to Meilisearch for most catalogues and content sites: it is fast to set up, runs with modest infrastructure, and its typo tolerance and ranking work well out of the box, with tuning layered on top rather than built from scratch. For larger scale, millions of records, or where complex aggregations and faceted counts across many dimensions are central to the product, Elasticsearch’s maturity and ecosystem earn the extra operational cost. Either way, the index stays in sync with your source of truth through an update pipeline, a webhook or a queue-based job triggered whenever the underlying data changes, so a new product or a price update is searchable within minutes, not after a nightly batch job. Ranking rules are tuned against actual query logs once real usage exists, not guessed at upfront, synonyms and typo tolerance get adjusted to the specific vocabulary your users use, which is rarely identical to generic defaults. We built exactly this kind of search layer for an archaeological atlas holding close to two million objects, where findability across loosely structured historical records was the entire point of the project.
What to watch
The main ongoing cost is keeping the index fresh and properly sized as your catalogue grows, an index that falls out of sync with the source database is worse than no search at all, because it looks authoritative while quietly missing recent items. We build monitoring on sync lag and zero-result query rates specifically to catch this early. Elasticsearch in particular carries real operational weight, cluster management, shard sizing, and version upgrades are not trivial, which is part of why we only recommend it once scale actually justifies it. Lock-in is low for either tool, both are open source and the data they index is a derived copy, not the source of truth, so re-indexing into a different search engine later is a rebuild of the pipeline, not a data migration.
Query logs themselves are worth treating as a product input, not just an operational artifact: the searches that return nothing useful are usually the clearest signal for what to improve next, more useful in practice than most user feedback forms, and we build the log review into the handover rather than leaving it as an afterthought nobody revisits.
Price and timeline
| Scope | Price | Timeline |
|---|---|---|
| Meilisearch, single catalogue | from $1,500 | 2 to 3 weeks |
| Elasticsearch, complex faceting, large scale | from $4,500 | 4 to 5 weeks |
Related
Built as part of custom development. Often paired with caching and CDN strategy for overall site speed and data migration between platforms when moving a catalogue onto new infrastructure. See it in action in the archaeological atlas with 1.9 million objects and the Telegram and web marketplace with instant delivery. Tell us what your users cannot currently find: get in touch.
FAQ
How much does a search setup cost?
A Meilisearch setup for a catalogue of a few thousand items with filters and typo tolerance starts at $1,500. A larger Elasticsearch deployment with complex faceting and custom ranking runs $3,500 to $8,000.
Meilisearch or Elasticsearch, which one?
Meilisearch is faster to set up, lighter to run and tolerant of typos out of the box, a strong fit for most product catalogues and content sites under a few million records. Elasticsearch handles larger scale and more complex aggregations better, at the cost of more operational overhead.
How long does it take?
2 to 5 weeks. Getting an index running is usually the fast part; most of the time goes to tuning ranking rules against real queries so results actually match intent instead of just text similarity.
Who owns the search infrastructure?
You do. Both Meilisearch and Elasticsearch are open source and run on your infrastructure or a managed instance in your name, with the indexing pipeline living in your own codebase.
Does this replace our database?
No, it sits alongside it. Your database stays the source of truth; the search engine holds a denormalized, search-optimized copy that gets updated whenever the underlying data changes.