E-commerce search has a problem that keyword matching cannot solve. A user searches for “light summer dress for beach wedding” and the system returns results matching those exact words. The product catalogue has a “chiffon midi in ivory” that is exactly what the user wants, but it never appears because the words do not match.

Vector search fixes this by matching on meaning rather than keywords. The user’s query and the product descriptions are both converted to embeddings, and the search engine finds products whose embeddings are closest to the query embedding. The “chiffon midi in ivory” shows up because its embedding is semantically close to “light summer dress for beach wedding.”

Three search engines have emerged as serious options for vector and hybrid search in e-commerce: Typesense, Meilisearch, and Elasticsearch with its kNN vector search capabilities. Each takes a different architectural approach, and the right choice depends on your catalogue size, query volume, and how much you value semantic search over traditional keyword matching.

The architectural split

Typesense and Meilisearch are purpose-built search engines. They are designed from the ground up for fast, relevant search with minimal operational overhead. Both started as keyword search engines and added vector search capabilities in their recent releases. They share a philosophy: search should be fast, simple to deploy, and require minimal configuration.

Elasticsearch is a general-purpose distributed search and analytics engine that bolted vector search onto its existing inverted-index architecture. Elasticsearch kNN uses the HNSW (Hierarchical Navigable Small World) algorithm for approximate nearest neighbour search, integrated alongside its traditional BM25 keyword scoring. The integration is real but the architecture was not designed for vector search as a primary use case.

This architectural difference matters. Typesense and Meilisearch treat vector search as a first-class feature with a query engine designed around it. Elasticsearch treats vector search as one capability among many, which means it offers more features but carries the complexity of a system designed for log analytics, full-text search, and operational monitoring.

Catalogue size and scaling

For small to medium catalogues (under 1 million products), Typesense and Meilisearch are the clear winners on operational simplicity. Both can handle this scale on a single node with sub-50ms query latency. You deploy a binary or a Docker container, index your products, and you have search running. No cluster configuration, no shard management, no capacity planning.

At 1 to 10 million products, the picture changes. Typesense supports clustering with automatic sharding and replication, but its cluster management is less mature than Elasticsearch’s. Meilisearch added horizontal scaling through its sharding feature but it is still early. Both can handle this range with careful configuration, but you are approaching the limits of their simple operational model.

Above 10 million products, Elasticsearch’s distributed architecture becomes necessary. Elasticsearch was designed for this scale from the start. It handles shard allocation, rebalancing, and replication automatically. The operational cost is real (Elasticsearch clusters require monitoring, tuning, and a team that understands JVM garbage collection and index lifecycle management) but it handles large catalogues without architectural strain.

Hybrid search: the real differentiator

The most important feature for e-commerce search is hybrid search: combining keyword matching (for exact matches like brand names, SKUs, and model numbers) with vector search (for semantic matching on product descriptions and user queries). Pure vector search misses exact matches. Pure keyword search misses semantic matches. Hybrid search combines both.

Typesense supports hybrid search through a built-in combination of its keyword engine and its vector search engine. You configure a weight between keyword relevance and vector relevance, and Typesense merges the results. The tuning is straightforward: adjust the weight, test with real queries, iterate. The default weights work reasonably well for most e-commerce catalogues.

Meilisearch added hybrid search with its AI search features. It supports vector search alongside its existing keyword search, with configurable ranking rules that let you blend semantic and keyword scores. Meilisearch’s ranking rule system is more expressive than Typesense’s single weight parameter, but it requires more configuration to get right.

Elasticsearch’s hybrid search is the most powerful and the most complex. You can combine BM25 scoring with kNN vector scoring using Elasticsearch’s query DSL, applying custom scoring functions, boosts, and filters. The flexibility is unmatched: you can boost exact brand matches, penalise out-of-stock items, boost products on sale, and blend all of this with semantic similarity in a single query. The cost is query complexity. A well-tuned Elasticsearch hybrid query can be 50-100 lines of JSON.

Faceting and filtering

E-commerce search is not just about relevance. It is about faceting and filtering. Users need to filter by price range, size, colour, brand, availability, and rating. These filters must combine with search results at query time without degrading latency.

All three engines support faceting and filtering, but the implementations differ. Typesense and Meilisearch handle faceting as a built-in feature with fast computation of facet counts. Filtering on structured fields (price, brand, category) is fast and composable with search queries.

Elasticsearch’s faceting is more powerful. It supports nested faceting, date histograms, range aggregations, and custom aggregation pipelines. For complex e-commerce requirements (facets that depend on other facets, dynamic price range buckets, availability filtering by warehouse location), Elasticsearch is the only option that handles the full complexity natively.

The trade-off is that Elasticsearch’s aggregation power comes with query latency overhead. A search query with five faceted filters and a vector similarity component can take 100-200ms on Elasticsearch versus 20-50ms on Typesense or Meilisearch for the same catalogue size.

Operational overhead

Typesense: deploy a binary, configure memory allocation, index your data. Monitoring is basic but sufficient for most deployments. Upgrades are straightforward. You can run a production Typesense instance with part-time DevOps attention.

Meilisearch: similar operational simplicity to Typesense. Meilisearch Cloud adds a managed option that removes even the deployment step. The self-hosted version is a single binary with minimal configuration.

Elasticsearch: requires a dedicated operations function. Cluster health monitoring, index lifecycle management, JVM tuning, shard allocation, rolling upgrades, Elasticsearch demands attention. Teams that underestimate this operational cost end up with slow queries, unstable clusters, and on-call pages at 2 AM.

Decision framework

Use Typesense when your catalogue is under 5 million products, you want fast hybrid search with minimal configuration, and you do not need complex aggregations or nested faceting. It is the best balance of simplicity and capability for most e-commerce search use cases.

Use Meilisearch when you want the simplest possible deployment, when your catalogue is under 1 million products, and when you want strong typo tolerance alongside semantic search. Its developer experience is the best of the three.

Use Elasticsearch when your catalogue exceeds 10 million products, when you need complex faceting and aggregation pipelines, when you already run Elasticsearch for other purposes, or when your search requirements include business rules that go beyond relevance scoring (inventory-aware ranking, geo-distributed results, real-time personalisation).

Do not choose Elasticsearch for operational simplicity. Choose it for capability at scale. If you do not need what Elasticsearch offers, the operational tax is not worth paying.