TL;DR
For simple queries (e.g. “find by name”) database search (LIKE, PostgreSQL FTS) is enough. When you need full-text search, fuzzy match, filters (facets), relevance sorting or millions of documents – consider a dedicated engine like Elasticsearch or OpenSearch. That requires indexing data and running extra infrastructure.
Who this is for
- Developers building catalogs, shops, panels with advanced search
- Architects of systems with large searchable datasets
- Anyone looking for an alternative to LIKE / simple FTS in the DB
Keyword (SEO)
elasticsearch search, full-text search, when to use elasticsearch
When is the database enough?
- Simple search – one field, exact or prefix (e.g.
WHERE name ILIKE 'John%') - PostgreSQL FTS – up to a few hundred thousand rows, language stemming, ranking; no faceting or advanced analytics
- Small volume – up to ~100–500k documents, FTS in Postgres often suffices
When to consider Elasticsearch / OpenSearch?
- Large volume – millions of documents, fast responses (< 100 ms)
- Fuzzy search – typos, “John Smith” vs “Smith John”
- Facets and filters – price, category, date – without slowing the query
- Multi-field search – title, description, tags with different weights
- Highlighting – snippets in results
- Aggregations – stats, “similar” recommendations, autocomplete (suggestions)
Elasticsearch vs OpenSearch
- Elasticsearch – mature ecosystem, part of Elastic Stack (Kibana, Beats). From 8.x license changed – check terms.
- OpenSearch – fork of ES 7.10, open-source (Apache 2.0), compatible API. Often chosen over license/cost concerns.
Both suit full-text search; choice depends on licensing, hosting (e.g. AWS OpenSearch) and team familiarity.
How it works in short
- Index – data is analyzed (tokenization, stemming, synonyms) and stored in a search-optimized structure.
- Query – user types a phrase → analyzer tokenizes → query to index (match, bool, filter) → ranking → results.
- Sync – data from the main DB (Postgres, MySQL) must reach the index: on write (event, trigger) or batch job. Latency depends on strategy (realtime vs periodic).
Simple query example (Elasticsearch)
GET /products/_search
{
"query": {
"bool": {
"must": [
{ "multi_match": { "query": "laptop", "fields": ["name^2", "description"] } }
],
"filter": [
{ "term": { "category": "electronics" } },
{ "range": { "price": { "gte": 1000, "lte": 5000 } } }
]
}
},
"highlight": { "fields": { "name": {}, "description": {} } }
}
Alternatives
- PostgreSQL FTS –
to_tsvector,to_tsquery, GIN index; no extra infrastructure - Meilisearch, Typesense – lighter, easy to run, good search quality for medium-sized datasets
- Algolia – SaaS, great UX (instant search), cost at scale
- CMS search – e.g. Strapi, Contentful – often enough for site content
Pre-implementation checklist
- Define requirements: volume, fuzzy, facets, languages
- Assess whether DB FTS isn’t enough
- Choose engine: Elasticsearch / OpenSearch / Meilisearch / SaaS
- Indexing and sync strategy with main DB
- Hosting and cost (self-hosted vs managed)
- Backup and index recovery plan
FAQ
Does Elasticsearch replace the database?
No. Usually the DB (Postgres, MySQL) stays the source of truth; Elasticsearch is the search layer. You replicate data into the index.
How often to update the index?
Depends: critical data (prices, availability) – on every change (event-driven). Less critical – every few minutes or hours (batch). Handle latency in the UI (“results may be up to 5 min old”).
Meilisearch instead of Elasticsearch?
Yes, if you don’t need advanced aggregations and complex mappings. Meilisearch is simpler to run and maintain, good search quality out of the box.