Composable Commerce

March 31, 2026

Ecommerce Site Search with Meilisearch: Open-Source Speed Without Per-Query Pricing

composable commerceecommerce site searchHeadless eCommerceMeilisearchopen source search

Ecommerce site search is where revenue goes to hide. A customer types “runing shoes” with a typo, gets zero results, and leaves. A B2B buyer pastes a SKU number, waits three seconds for a response, and opens a competitor’s tab. A German shopper searches for “Schreibtisch” and sees English-only results priced in dollars.

Key Takeaways

Last verified: April 2026

The problem: SaaS search vendors charge $0.50 to $1.75 per thousand queries, and you cannot self-host or switch providers without rebuilding your integration.

The open-source alternative: Meilisearch delivers sub-50ms typo-tolerant search with faceted filtering under an MIT license. Self-host it and your per-query cost is zero.

How Spree Commerce fits: Spree ships a built-in Meilisearch provider that handles multi-locale, multi-currency product indexing automatically. One configuration line activates it, and the same REST API works regardless of which search engine you choose.

Who this is for: Teams evaluating ecommerce platforms where search performance, cost control, and the freedom to switch providers are part of the decision criteria.

Every failed search is a lost sale. Most headless ecommerce platforms either ship with slow SQL-based search or push you toward a SaaS vendor that charges per query.

Meilisearch changes that equation. It is an open-source search engine (MIT license) built for speed: sub-50 millisecond responses, typo tolerance out of the box, and faceted filtering that adjusts counts as shoppers narrow their results. Spree Commerce ships Meilisearch as a built-in search provider that you configure in one line. No separate subscription, no per-query billing, no vendor lock-in on your search infrastructure.

Why Does Ecommerce Site Search Fail on Most Platforms?

Search users convert at six times the rate of browsers, yet most ecommerce platforms treat search as an afterthought. The default search on many platforms runs SQL queries with pattern matching against product names. That approach breaks in predictable ways as a catalog grows past a few hundred products.

Typo intolerance is the most visible failure. A shopper searching for “recieving blanket” or “labtop stand” gets an empty results page instead of the obvious match. SQL pattern matching requires exact or near-exact character sequences. It cannot guess what the shopper meant.

Speed degrades with catalog size. A specialty food distributor with 8,000 SKUs might see search responses climb from 200 milliseconds to two or three seconds as the database scans more rows. B2B buyers building bulk orders feel every millisecond. The Baymard Institute has documented that 70% of ecommerce search implementations fail to return useful results for product-type synonyms, leaving shoppers stuck when they use natural language instead of catalog terminology.

Language and currency blindness kills international sales. A platform serving Germany, France, and the US from one instance needs search results in the shopper’s language, with prices in their currency. SQL search has no concept of locale-specific indexing. It returns whatever the database contains, regardless of market context.

These are not edge cases. They are the daily experience of any ecommerce team running a catalog with more than a thousand products across multiple markets.

The conventional fix is to bolt on a SaaS search service. That works, but it comes with a recurring cost that scales with your traffic and a vendor dependency that makes switching painful later. If you are evaluating ecommerce platforms right now, the way a platform handles search reveals its broader architecture: bolted-on versus built-in, locked versus composable.

What Makes Search a Platform Architecture Decision?

When search breaks, most teams reach for a SaaS vendor. They sign up for a search service, build a custom integration, and start paying per query. That fixes the immediate problem, but it introduces a structural dependency that reveals something important about the platform underneath.

How a platform handles search tells you how it handles everything. A platform that forces you to bolt on third-party search is a platform that treats search as someone else’s problem. That same philosophy usually extends to payments, content management, and internationalization. You end up assembling a stack of SaaS subscriptions, each with its own contract, its own API, and its own pricing model that scales unpredictably with your traffic.

A composable ecommerce stack takes a different approach. The platform provides a clean interface for each capability, with a built-in default that works out of the box and the freedom to swap in your own choice when you outgrow it. Search is the clearest test of this philosophy because it touches every product page, every category listing, and every shopper interaction.

Algolia, the most widely adopted SaaS search vendor, charges between $0.50 and $1.75 per thousand search requests on its paid plans (Algolia Pricing, 2026). For a mid-market retailer processing 500,000 searches per month, that is $250 to $875 in search costs alone. During peak traffic events like Black Friday, search volume can spike three to five times, and your bill spikes with it.

The alternative is a search engine you own. One that runs on your infrastructure, indexes your products automatically, and costs nothing per query.

How Does Meilisearch Handle Product Search?

Meilisearch is a search engine built in Rust for speed and relevance. It returns results in under 50 milliseconds, handles typos without configuration, and supports faceted filtering that adjusts available options and counts as shoppers narrow their selection.

Typo tolerance works immediately. A search for “recieving blanket” matches “receiving blanket.” A search for “labtop” matches “laptop.” Meilisearch calculates edit distance automatically and ranks the closest matches highest. No synonym dictionaries to maintain, no custom rules to write.

Faceted filtering shows what is actually available. When a shopper filters by “red” and “size medium,” the remaining filters update to show only the colors, sizes, and price ranges that exist within those constraints. This is standard for dedicated search engines but impossible with SQL-based pattern matching.

Relevance ranking uses multiple signals. Meilisearch combines word proximity, typo count, exact match preference, and custom ranking rules (like top-selling or newest) to sort results. A search for “blue running shoes” ranks products where all three words appear close together above products where they are scattered across the description.

The project is open source under the MIT license, which means the core search engine is free to use, modify, and deploy in commercial applications. Meilisearch also offers a managed cloud service for teams that prefer not to operate their own infrastructure, with both usage-based and resource-based pricing options.

What Does Multi-Language, Multi-Currency Search Look Like?

International ecommerce is where most search solutions fall apart. A product needs to be findable in every language your store supports, with prices displayed in the correct currency for the shopper’s market. SaaS search vendors handle this, but they index your products as flat documents. You build the locale and currency logic yourself.

Spree Commerce solves this at the platform level. When you activate the Meilisearch integration, every product is automatically indexed as one document per market and locale combination. A single T-shirt in a store serving the US (English, USD), Germany (German, EUR), and France (French, EUR) produces three separate search documents, each with the localized name, description, and correct price.

A German shopper searching for “blaues Hemd” sees results in German, priced in euros. An American shopper searching for “blue shirt” sees English results in dollars. The multi-region ecommerce logic handles this automatically based on the request headers, with no custom indexing pipeline to build or maintain.

This matters for B2B ecommerce as well. A parts distributor serving buyers in multiple countries needs search that returns SKU matches with the correct wholesale pricing for each market. The same indexing architecture handles B2B catalogs with thousands of SKUs across multiple price lists and currencies.

How Does Spree Commerce Integrate Meilisearch?

Spree Commerce ships Meilisearch as a built-in search provider, not a third-party plugin or a marketplace extension. The integration is part of the core platform and maintained by the same team that maintains the commerce engine.

Activation is a single configuration line. You set the search provider to Meilisearch, run the product reindex, and your Store API immediately uses Meilisearch for all product search, filtering, and faceted navigation. No separate integration code, no webhook configuration, no data pipeline to build.

The Store API stays identical. Whether your store uses the default database search or Meilisearch, the REST API returns the same response shape: products, facets, sort options, and pagination. A Next.js storefront, a React Native mobile app, or any other frontend consuming the API does not need to change a single line when you switch search providers.

Indexing runs in the background. When a product is created, updated, or removed, background jobs automatically update the Meilisearch index. Bulk reindexing handles the initial import and any full catalog refreshes. The platform takes care of the data pipeline so your team does not have to build one.

Search covers the full product surface. The Meilisearch integration indexes everything a shopper or buyer might search for:

• Product names and descriptions in every supported locale
• SKUs and variant codes for B2B part number lookups
• Option values like “Red,” “Large,” or “Stainless Steel”
• Category names and product tags
• Stock status and price data for filtering

A B2B buyer searching by part number, a consumer searching by product name, and a procurement manager searching by category all find what they need through the same search interface.

What Happens When You Need to Switch Search Engines?

Vendor lock-in is not just a contract problem. It is an architecture problem. If your search integration is tightly coupled to a specific vendor’s API, switching to a different search engine means rewriting your integration, rebuilding your indexing pipeline, and testing every search-dependent feature in your storefront.

Spree Commerce avoids this with a pluggable search provider interface. Every search provider implements the same contract: a single method that accepts a query, filters, sort options, and pagination parameters, and returns products, facets, and metadata. Meilisearch is the built-in default. Typesense, Algolia, Elasticsearch, and OpenSearch are all supported through the same interface.

Switching search engines is a configuration change, not a rewrite. You build a provider class, point it at your preferred search engine, and register it. The Store API, the indexing lifecycle, and every frontend consuming your search results continue working without modification.

This architecture reflects a broader principle in composable commerce. Every major capability, including payments, content delivery, and search, should be a choice you make based on your requirements, not a dependency imposed by your platform. The platform’s job is to provide the interface and the default. Your job is to pick the right tool for your business.

For teams evaluating ecommerce platforms where search performance, vendor flexibility, and predictable costs matter, an open-source platform with a pluggable search interface and a built-in Meilisearch provider offers the strongest architectural fit. You get production-ready search from day one, with the freedom to change course later without rebuilding your stack.

Start Building

Spree Commerce gives you a production-ready ecommerce site search stack with Meilisearch built in, the freedom to swap search engines through a pluggable provider interface, and multi-locale, multi-currency indexing that works automatically with Markets.

If you are evaluating ecommerce platforms and search is on your checklist, explore Spree Commerce with Meilisearch and see how a composable architecture handles the search layer.

Frequently Asked Questions