| Table of Contents 01 Why product search decides revenue 02 How an e-commerce search engine works 03 Algolia vs Elasticsearch: the honest choice 04 Designing the search index 05 Faceted search: how filters really work 06 Building faceted filters step by step 07 Relevance ranking: BM25 to learn-to-rank 08 Autocomplete, typo tolerance, and synonyms 09 Hybrid and vector search for discovery 10 Search for large catalogs and peak load 11 On-prem, free tier, or managed: what it costs 12 How to hire for a search build 13 Questions buyers ask |
As the Backend Lead at Acquaint Softtech, a custom software product development partner, I get one question from almost every store scaling past a few thousand products: why does our search miss things customers can clearly see in the catalog?
The answer is usually that the store is searching a database instead of a real search engine. This guide shows how to build an e-commerce product search engine with Elasticsearch or Algolia, from index design and faceted filters to relevance ranking and cost.
Search is not a nice-to-have. Industry research consistently finds that a large share of visitors go straight to the search bar, and shoppers who search convert far more often than those who only browse, which is why weak search quietly bleeds revenue. Getting started with Elasticsearch or a managed alternative is the pressure valve that turns that lost intent into sales. The concepts here follow the official Elasticsearch documentation.
This is the companion to the Complete Guide to E-Commerce Software Development. It draws on real commerce platforms Acquaint Softtech has built as an Official Laravel Partner, with 1,300+ projects, 70+ in-house engineers, and clients across the USA, UK, Europe, Australia, and New Zealand who deploy dedicated teams within 48 hours of a brief.
Why product search drives revenue
Product search drives revenue because it is where high-intent shoppers tell you exactly what they want to buy. A visitor who types a query is closer to purchase than one who browses, so every failed or irrelevant search is a lost sale you already paid to acquire. When ecommerce search returns nothing for a product that exists, the shopper assumes you do not stock it and leaves.
Database search is not search
A SQL LIKE query cannot handle typos, synonyms, relevance ranking, or fast faceting across millions of rows, which is why a dedicated engine exists. Moving discovery onto a proper index is a core part of any serious product engineering services effort, because it changes conversion, not just page speed.
How an e-commerce search engine works
An e-commerce search engine works by copying product data into an inverted index, a structure that maps each word to the products that contain it, so lookups are near-instant. When a shopper types a query, the engine analyzes the text, matches it against the index, scores every candidate for relevance, and returns a ranked page with facet counts, all in milliseconds.
Three stages matter: indexing, where products are analyzed and stored; querying, where the shopper’s text is parsed and matched; and ranking, where results are ordered by relevance and business rules. Elasticsearch online store setups and Algolia both follow this shape, and the difference is mostly who operates the machinery.
Algolia vs Elasticsearch: the honest choice
The honest answer to Algolia vs Elasticsearch for a store is a build-versus-buy decision. Algolia is a managed, hosted search API that is fast to launch and tune with little ops burden. Elasticsearch is an open, self-operable engine that gives total control and lower per-query cost at scale, in exchange for engineering and operations effort. Neither is best in the abstract, only best for your team.
| Factor | Algolia | Elasticsearch |
| Model | Managed SaaS API | Self-hosted or Elastic Cloud |
| Time to launch | Days | Weeks |
| Relevance tuning | Dashboard, low-code | Full control in query DSL |
| Ops burden | None, vendor runs it | Cluster ops, or pay for managed |
| Cost shape | Per search and record | Infra plus engineering time |
| Best for | Small teams wanting speed | Large catalogs, custom logic, scale |
A simple rule
Choose Algolia when speed to market matters more than control, and the catalog is moderate. Choose Elasticsearch when the catalog is large, relevance logic is bespoke, on-prem is required, or per-query economics matter at high volume. The Acquaint Softtech team recommends the engine that fits the team you will actually have, not the one with the flashiest demo. On-premises Elasticsearch is the right call when data residency or cost control rules out a hosted API.
Designing the search index
A search index is a denormalized copy of your catalog shaped for reading, not writing. The golden rule is to separate product master data from variable SKUs so a change to one variant does not force a rewrite of everything, which prevents the mapping explosions that slow large indexes. Index the fields shoppers search and filter on, and store the rest for display only.
A minimal product document
{ id, title, brand, category, description,
price, in_stock, rating, popularity,
attributes: { color, size, material },
variants: [ { sku, price, stock } ] }
Reindexing strategy matters as much as the mapping: plan for zero-downtime reindexing with aliases so you can rebuild the index without taking search offline. A public e-commerce product search engine Elasticsearch GitHub project or the best e-commerce product search engine Elasticsearch starter can seed the mapping, and the Acquaint Softtech team adapts it to the catalog rather than shipping a generic template. The search layer is wired to the catalog database through solid software development outsourcing when an in-house team is stretched.
Read Also: How Technology Is Reshaping Educational Technology Platforms
Faceted search: how filters really work
Faceted search is the filter sidebar that lets shoppers narrow results by brand, size, color, price, and rating, with a live count next to each option. Under the hood, it is powered by aggregations: the engine groups the current result set by each attribute and counts the matches, so the facets always reflect what is actually available. That live count is what stops a shopper from hitting a dead-end no-results screen.
OR within a group, AND across groups
The rule that makes faceted search e-commerce feel right is simple: values inside one facet combine with OR, while separate facets combine with AND. Selecting red and blue shows red or blue shirts, then adding a size filter narrows to those also in that size. Showing counts and hiding zero-result options keeps the interface honest and fast.
Building faceted filters step by step
A faceted filter implementation follows five clear steps, and getting the query structure right is what keeps it fast on a large catalog. The pattern below is the same whether you build a faceted search module on Elasticsearch or configure it in Algolia.
- Mark facetable fields. Set brand, size, color, and price as keyword or faceted attributes at index time.
- Query with a bool filter. Put the search text in the query and each selected facet in a filter clause, which is cached and fast.
- Aggregate for counts. Add one aggregation per facet to return the count beside every filter value.
- Apply OR and AND logic. Combine values within a facet with OR, and combine different facets with AND.
- Cache and lazy-load. Cache stable facet counts and defer lower filters on mobile to cut initial load.
Handled this way, a faceted filter implementation returns results and counts in milliseconds even on a catalog with millions of items, because filters run as cacheable, non-scoring clauses.
Relevance ranking: BM25 to learn-to-rank
Search relevance ranking is the logic that decides which matching products appear first, and it is where most stores leave money on the table. The baseline is BM25, a text-scoring model that rewards rare, well-matched terms. On top of that, business signals like stock level, margin, popularity, and rating should nudge the order, so the best commercial result wins, not just the closest string match.
When to add learn-to-rank
For large catalogs, learn-to-rank on Elasticsearch trains a model on real click and purchase data to order results the way shoppers actually behave, going beyond hand-tuned weights. It is worth adding once you have traffic to learn from. The routing and scoring models behind this are delivered with Acquaint Softtech’s AI development services, so relevance improves as the data grows.
Autocomplete, typo tolerance, and synonyms
These three features quietly close the gap between what a shopper types and what they meant. Autocomplete predicts the query as the shopper types using edge n-grams or a completion suggester, typo tolerance catches misspellings with fuzzy matching, and synonyms map trainers to sneakers or telly to television so intent is not lost to vocabulary.
- Autocomplete: index edge n-grams or use a completion suggester for instant typeahead.
- Typo tolerance: enable fuzziness so laptp still finds laptop.
- Synonyms: maintain a synonym analyzer for brand names, slang, and category terms.
Hybrid and vector search for discovery
Hybrid search combines classic keyword matching with vector search, where products and queries become numeric embeddings so the engine can match by meaning, not just words. It is what lets a search for a warm waterproof jacket surface the right coats even when those exact words are not in the title. Keyword search handles precision, vector search handles intent, and blending them covers both.
Vector search is now native to modern Elasticsearch, so a store can add semantic discovery without a separate system. Whether it is worth it depends on catalog size and how descriptive shopper queries are, and the Acquaint Softtech team scopes that honestly rather than adding complexity for its own sake. Technical direction across the search architecture is available through a virtual CTO.
Search for large catalogs and peak load
Building search for large catalogs is a problem of sharding, caching, and query discipline. Elasticsearch scales horizontally by splitting an index into shards across nodes, so a catalog of tens of millions of items stays fast when the cluster is sized correctly. The goal is steady low latency during a sale, not just on an average Tuesday.
- Shard for the catalog, not by guesswork, and add replicas for read-heavy peak traffic.
- Filter, do not query, for facets, since filter clauses are cached and skip scoring.
- Cache hot queries and precompute stable facet counts to cut repeated work.
Keeping search fast through a peak is the same discipline as keeping a whole platform stable, and ongoing tuning is handled through support and maintenance once the store is live.
On-prem, free tier, or managed: what it costs
The product search development cost depends on the model you pick and who runs it. Elasticsearch itself is open and has a free tier for self-hosting, so the cost is infrastructure plus engineering time. Algolia and Elastic Cloud are managed, trading a per-search or per-record fee for near-zero operations. On-premises Elasticsearch suits data-residency and cost-control needs at scale.
| Option | What you pay for | Typical range (USD) |
| Elasticsearch, self-hosted | Servers plus engineering and ops | Infra from ~$150/mo plus build |
| Elastic Cloud, managed | Hosted cluster, usage-based | From ~$95/mo, scales with data |
| Algolia, managed API | Records and search operations | Free tier, then usage-based |
| Custom build (one-time) | Index, facets, relevance, tuning | $6,000 to $30,000 |
Where the real savings are
The engine fee is rarely the big number; the build and tuning are. A custom search engine India-based build delivers the index, faceted filters, and relevance work at up to 40% cost savings versus Western agencies, with blended rates of roughly $20 to $45 per hour. When you plan to build a faceted search module or hire Elasticsearch developers, judge them on index design and relevance reasoning, not on how fast they can spin up a cluster. A full domain-ready pod is delivered as a dedicated development team.
How to hire for a search build
The right hire for a search build understands three things: how to design an index for reading, how to tune relevance with both BM25 and business signals, and how to keep facets fast at scale. A generic backend developer can stand up a cluster, but relevance is a craft, and it is what separates search that converts from search that merely returns rows.
Look for engineers who have shipped search on a real catalog, because tuning is learned from production traffic, not tutorials. Teams that hire Python developers with search experience get both the indexing pipeline and the relevance model from one team. Scoping the work correctly first is the job of a short discovery workshop.
Proof: what better search changed
Search quality is easiest to understand as a before-and-after. Acquaint Softtech rebuilt product discovery for Lampoo, a Milan-based luxury fashion marketplace with a large, fast-moving catalog across many sizes, colors, and sellers. This account is drawn from the client’s verified 5.0 out of 5 Clutch review, and the scorecard below shows what changed.
| What shoppers experienced | Before | After |
| Typo like “jaket” | No results | Finds jackets via fuzzy match |
| Filter by size and color | Slow, sometimes wrong counts | Instant facets with live counts |
| Search on a busy drop | Laggy under load | Milliseconds on peak traffic |
| Relevance of top results | Newest, not best | Ranked by match, stock, and demand |
| Finding by description | Exact words only | Semantic matches by meaning |
The build followed the same path this guide describes: a clean index separating products from SKUs, aggregation-driven facets, BM25 plus business-signal ranking, and fuzzy matching for typos. Order processing was moved onto a Laravel asynchronous queue so heavy work never blocked the shopper. The lesson is that better relevance, not a prettier search box, is what turns searches into sales.
Questions buyers ask
Elasticsearch or Algolia for e-commerce?
A: Choose Algolia when you want a fast launch and low ops burden on a moderate catalog. Choose Elasticsearch when the catalog is large, you need custom relevance or on-prem control, or per-query cost matters at scale. Algolia is buy, Elasticsearch is build; the right pick depends on your team and catalog, not on which is best in the abstract.
How does faceted search work?
A: Faceted search groups the current result set by attributes like brand, size, and price, then counts the matches to build a live filter sidebar. Values within one facet combine with OR, and separate facets combine with AND. Search engines power this with aggregations, returning results and counts in milliseconds even on huge catalogs.
How do you improve product search relevance?
A: Start with BM25 text scoring, then layer business signals like stock, margin, popularity, and rating so the best commercial result ranks first. Add synonyms, typo tolerance, and autocomplete to catch intent. For large catalogs, learn-to-rank trains a model on real click and purchase data to order results the way shoppers actually behave.
How do you build search for large catalogs?
A: Use a dedicated engine, not SQL. Design a denormalized index, separate products from SKUs, and split the index into shards across nodes so it scales horizontally. Run facets as cached filter clauses, cache hot queries, and add replicas for peak traffic. Sized correctly, a catalog of tens of millions stays fast.
What are the best search engines for e-commerce?
A: The common choices are Elasticsearch and OpenSearch for open, self-operable control, Algolia for a fast managed API, and Typesense or Meilisearch for lightweight needs. Elasticsearch and Algolia dominate serious stores. The best one is the engine that fits your catalog size, relevance needs, and the team that will run it.
Do people still use Elasticsearch?
A: Yes, widely. Elasticsearch remains one of the most deployed search engines in the world, used across e-commerce, logging, and analytics. Its open model, mature ecosystem, native vector search, and horizontal scaling keep it a default choice for large catalogs and custom relevance, either self-hosted or through Elastic Cloud.
Does Netflix use Elasticsearch?
A: Yes. Netflix has publicly described using Elasticsearch at large scale, primarily for operational visibility such as logging, monitoring, and analytics across its infrastructure. Many large technology companies adopt it for search and observability because it scales horizontally and handles high-volume data in near real time.
Which big companies use Elasticsearch?
A: Elasticsearch is used by many large organizations, including companies like Netflix, Uber, and Slack, across search, logging, and analytics workloads. Its ability to index huge volumes and return ranked results in milliseconds makes it a common backbone for both product search and operational data at enterprise scale.
