Elasticsearch and site search
Search that copes with misspellings, synonyms and partial words — which a database LIKE query never will.
Search engine
Chosen per project
Maintainable handover
On a catalogue of any size, search is the primary navigation. When it fails to find a product the customer knows exists, the sale is usually lost quietly — and a SQL LIKE query fails at exactly that point: a transposed letter, a plural, a brand written two ways.
A search engine indexes text for retrieval instead of storage. It tolerates typos, understands stems and synonyms, ranks by relevance, and returns facet counts alongside the results so filters can be built without a second query.
What we build with Elasticsearch
E-commerce product search with filters and facet counts
Document and knowledge-base search across large archives
Log and event search for operations teams
Autocomplete and suggestion behaviour on large catalogues
Where it fits — and where it does not
Good fit when
Free-text search over thousands of records or more
Faceted filtering where counts must be accurate
Relevance that has to be tuned against real behaviour
Consider something else when
Small catalogues where database full-text search is sufficient
Use as a primary store — it is a search index, not a source of truth
Why a typo still finds the product
Each stage is a place where a plain database query would return nothing.
Analyse
Lowercase, strip punctuation, reduce to stems.
Expand
Apply synonyms and known local spellings.
Fuzzy match
Tolerate a transposed or missing letter.
Rank
Score on field weights and business boosts.
How we work with Elasticsearch
Index from the source of truth
The database stays authoritative; the index is rebuilt from it and can be thrown away without data loss.
Analysers for the content
Stemming, synonyms and fuzziness configured for the actual vocabulary, including local brand and product spellings.
Relevance tuned on real queries
Boosting decided from what people search for and click, not from assumptions about the catalogue.
Rebuild without downtime
Aliases and reindexing so mapping changes never take search offline.
Our typical Elasticsearch setup
| Concern | What we use |
|---|---|
| Engine | Elasticsearch or OpenSearch, self-hosted or managed |
| Indexing | Rebuildable from the primary database, incremental updates on change |
| Language | Analysers, synonym lists and fuzziness tuned to the catalogue |
| Facets | Aggregations returning filter counts with the results |
| Operations | Alias-based reindexing, snapshots, cluster monitoring |
Frequently asked questions
Below a few thousand records with simple matching, PostgreSQL or MySQL full-text search is usually enough and much less to run. Above that, or once typo tolerance and facets matter, a dedicated engine pays for itself.
The database wins, always. The index is derived and can be rebuilt, which is why it is never the only copy of anything.
Yes — boosting in-stock items, promoting margin, weighting title over description. That tuning is where most of the commercial value sits, and it is driven by your search logs.
Topics people search for
Services built with Elasticsearch
E-commerce Development
Online stores where the checkout works, the stock figures are real and the order data reaches your operations team intact.
Web Application Development
Applications that run in the browser, handle real workloads and hold up when several departments depend on them at once.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Enterprise Software Development
Systems for organisations where several departments, sites and approval chains all have to work from the same data.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.