What is Meilisearch? Fast Search for Websites and Shops, Honestly Assessed

Meilisearch is an open-source search engine you place next to your existing application: your product or content data goes into a search index, and your website queries that index instead of the database. You know the result from the big shops: hits appear while you are still typing, typos are forgiven, filters respond instantly.

Behind the project stands the French company Meili SAS. The software is written in Rust, runs as a single binary, and promises response times under 50 milliseconds according to the vendor documentation, regardless of data volume (meilisearch.com, retrieved September 4, 2026). The current version 1.53.1 was released on August 13, 2026 – the project ships at a high cadence.

A side aspect that regularly matters in our projects: Meili SAS is a European company. If you are aligning your search infrastructure with EU vendors anyway, you get tool and vendor from the same legal space – and with self-hosting, no search query ever leaves your servers.

Meilisearch is used where people search structured collections: shop catalogs, documentation sites, real-estate and job boards, internal knowledge bases. It does not replace your database. It adds what databases do badly: instant, error-tolerant, faceted search.

Up front, the assessment this guide delivers: what Meilisearch does better than your database search, what the 2025 license change really means, what running it and the cloud cost – and the cases where you are better off with Elasticsearch, OpenSearch, or plain PostgreSQL.

Most website searches are database queries with pattern matching: they find «gasket ring» when someone types exactly «gasket ring». They fail on «gaskt ring», on «sealing ring», and on the question whether a hit in the headline matters more than one in a footnote. And they deliver no facets: no «category X only», no «in stock only», no hit counts per filter.

This is not a cosmetic problem: whoever searches has buying intent or a concrete need. A search with zero results is a silent exit – and it shows up in no error log.

A look at real search logs shows the pattern – as an experience value from our projects: a substantial share of queries contains typos, abbreviations, or manufacturer spellings that do not exist in the data in that form. With an exact database search, every one of these queries ends with zero results, even though the product sits in the catalog.

Honesty demands the first remedy here too: PostgreSQL ships a full-text search that is good enough for simple cases. If your website has a few hundred pages and nobody needs faceted filtering, first check whether the database you already pay for is enough. Meilisearch is the second stage: instant search, typo tolerance, and filters the way users know them from shops. What a good site search needs in detail, we cover in website search.

Typo tolerance: «gaskt ring» finds the gasket ring without you maintaining synonym lists. How strict it should be is configurable – down to fields that are searched exactly, such as article numbers.

Search as you type: results update with every keystroke. That is the reason for the 50-millisecond promise: instant search only works if every single query is fast enough.

Facets and filters: category, price range, availability, manufacturer – including hit counts per facet. For catalogs and knowledge bases this is the real value, not the search bar itself.

Relevance by rules: seven ranking rules determine the order of results, and you can rearrange them or add your own criteria, such as stock level or margin. On top of that come SDKs for more than ten programming languages and an API that integrates into any modern website.

The operational advantage over the incumbent Elasticsearch: Meilisearch is a single binary with one configuration file. No cluster, no Java runtime, no dedicated ops team. That is exactly why it sits on our tech-stack page as the more pragmatic choice for small and medium data volumes.

For orientation, the neighbors, one sentence each. Elasticsearch and OpenSearch: the heavyweights for large data volumes and analytics, with matching operational overhead – OpenSearch is the Apache 2.0 fork that emerged from the 2021 license dispute around Elasticsearch.

Typesense: the most direct competitor, also lean and open source, with a very similar profile. Algolia: the SaaS pioneer of instant search, technically mature, but priced by volume – and your data sits with a US vendor. PostgreSQL full-text search: the built-in zero-cost option that is enough for simple cases.

What stands out in this landscape: between the built-in database search and the cluster heavyweights, a gap yawned for a long time, and that is exactly what Meilisearch and Typesense fill. That is why both have appeared in the same recommendation lists for years whenever someone asks for a lightweight Elasticsearch alternative.

The selection logic is the same as with any infrastructure decision: use case first, then operational load, then the tool. We go deeper, with a decision matrix, in Elasticsearch alternatives – for quick orientation this is enough: end-user search at small and medium data volumes is the territory of Meilisearch and Typesense.

Precision pays off here, because since 2025 the sentence «Meilisearch is MIT-licensed» is only half true. The LICENSE file in the official repository shows a dual structure: the core remains under the MIT license – free to use, commercially too, in production too, self-hosted too (github.com/meilisearch, retrieved September 4, 2026).

Alongside it exist enterprise modules under the Business Source License 1.1. For them: testing, development, and evaluation are allowed; production use requires a contract with Meili SAS. Every release of these modules automatically becomes MIT after four years (LICENSE-EE in the repository, retrieved September 4, 2026). Affected are in particular the distributed features – there are separate enterprise binaries for them.

For your records, the three-point check we document before every deployment: which license does the deployed binary carry? Does the setup use features from enterprise modules? And if so: is there a contract? For a standard setup on one server, the answer is uncritical three times over – but it belongs in writing anyway, at the latest when a customer or auditor asks about the license situation of your software supply chain.

Meilisearch follows a pattern you know from other successful open-source tools: Elastic changed its license in 2021, n8n uses a Sustainable Use License, Sentry and others went similar ways. The driver is always the same: hyperscalers and competitors should not resell the product as their own service. What matters for you as a user is WHERE the line runs – and here it is drawn in a user-friendly place.

What does that mean in practice? For a website or shop search on a single server, you use the standard binary under MIT: no cost, no contract obligation. Only those who want to scale horizontally across several search nodes end up with the enterprise modules – and should read the LICENSE-EE or talk to Meili SAS before going to production.

For a few versions now, Meilisearch can do more than keywords: with a configured embedder, it converts documents and search queries into meaning vectors. Hybrid search then merges both approaches (keyword hits and meaning hits), and you control the blend with a single parameter, the semanticRatio (Meilisearch documentation, retrieved September 4, 2026).

As embedding sources, Meilisearch supports OpenAI, Mistral, Cohere, and HuggingFace, among others – and, via a REST embedder, any embedding API. That is the connection point for EU setups: the embedder can also be a self-hosted model on your own server. These capabilities live in the free standard binary, not in the enterprise modules (as of v1.53, retrieved September 4, 2026).

This way, «replacement part for a leaking tap» also finds the cartridges and sealing kits whose descriptions never mention «tap». For B2B catalogs with specialist vocabulary, this is the lever – how big it is, we describe using the example of semantic product search in B2B. How meaning-based search works underneath is the subject of semantic search.

Two things to know before you switch it on. First, the cost: every document and every query has to pass through the embedding model – API providers charge fees that grow with catalog size and search volume.

Second, the benefit: with well-maintained titles and clear categories, keyword search with typo tolerance often already delivers almost everything; hybrid search pays off mainly where users speak differently than your catalog writes. Measure that with real queries before you budget permanent embedding costs.

One boundary, so the terms do not blur: hybrid search in Meilisearch is end-user search – someone types, hits appear. A RAG system that formulates answers from your company knowledge is a different construction site: for that we use pgvector on PostgreSQL, and what such a setup looks like is described in Supabase as an AI backend. In short: Meilisearch finds documents, RAG answers questions.

Self-hosting is free. Meilisearch runs as a Docker container on an ordinary server – for typical website and catalog indexes, a small EU instance is enough, at a monthly price in the single-digit to low double-digit euro range. In return, you manage updates and backups yourself; with a single, largely stateless container, that stays manageable, because the index can be rebuilt from your source data at any time.

Meilisearch Cloud starts at 20 US dollars per month. The vendor's cost calculator puts 100,000 documents and 50,000 searches per month at around 30 US dollars (meilisearch.com/pricing, retrieved September 4, 2026). In exchange, operations and updates disappear; your search index then sits with the vendor, though – for personal data, the data processing agreement and the hosting-region question belong on the table.

The calculation for your case, as a formula instead of a fixed number: count your documents and estimate monthly searches, then compare the cloud price from the calculator with the rent of a small EU server. For small collections the cloud often wins (no operations, no update calendar); with growing search volume the math flips – server rent stays constant while usage-based prices grow with you.

The honest full-cost calculation has a third line item, though: person-days. Setting up, building the index sync, tuning relevance – that is the same for both variants and clearly exceeds the server costs in the first year. The difference between self-hosting and cloud therefore rarely decides the project; data quality decides it, more on that in a moment.

For context against the best-known SaaS vendor: Algolia bills per search and per record, which gets expensive as traffic grows – the price list changes constantly, which is why we deliberately give no number here: run your search volume against the current pricing page before you sign. A self-hosted Meilisearch server costs the same at ten times the traffic.

So that self-hosting does not stay a black box, the three operational tasks in concrete terms. Updates: Meilisearch releases new versions at a high cadence. You do not have to take every one – but a planned update rhythm once per quarter belongs in the calendar, including a look at the release notes.

Backups: the search index is derived state. The most pragmatic safeguard is therefore often no index backup at all, but the ability to rebuild the index from your source data at any time – one run of your sync. For fast restores of large indexes, Meilisearch additionally offers snapshots.

Monitoring: two metrics are enough at the start: search response time and success of the last sync. Plus the analysis that delivers the most value and happens most rarely: regularly reading the queries with zero results. That list is your free product manager – it shows which words your customers use and your catalog does not.

Log analysis and analytics: Meilisearch is a search engine, not an analytics tool. If you want to search log data, aggregate metrics, or build dashboards, Elasticsearch or OpenSearch is the right place – that is their home turf, and there the higher operational effort is worth it.

Complex queries across many joins: analyses like «revenue per region per quarter» belong in the database or the BI tool, not in the search index.

Very large, distributed setups: as soon as a single server is no longer enough and you have to distribute across several search nodes, you are in enterprise territory – with a contract license. At that scale, OpenSearch under the Apache 2.0 license is also a serious alternative, especially if your team has AWS experience anyway; we compare the two in Elasticsearch vs. OpenSearch.

When the database is enough: a handful of pages, no facets, search as a side feature – then PostgreSQL full-text search is the honest recommendation. A search index is a second system that wants to be kept in sync; that complexity has to earn its keep.

The B2B catalog: tens of thousands of articles; customers search with article numbers, manufacturer codes, and technical terms. Field configuration pays off here: exact search on numbers, typo tolerance on descriptions, facets for manufacturer and availability. The most common surprise: the search mercilessly exposes where product data is patchy.

The content platform: a blog, a documentation site, a help center with a few hundred to a thousand posts. The index is small, the setup is quick, and the win lies in the findability of older content that nobody reaches through the navigation anymore. For exactly this case, the site search of this blog is itself a candidate.

The internal knowledge base: guidelines, meeting notes, project documents: searchable for the team, with access control in front of the search. Here begins the gray zone toward AI-generated answers: if employees should FIND documents, Meilisearch is enough. If they should GET answers, you are looking at a RAG system – the pgvector setup linked above is the starting point for that decision.

All three patterns share one thing: the search index is never the project, only its most visible part. The work sits in connecting the source systems and in the question of which data may go in.

The integration has three parts, and none of them is research. First, operations: a Docker container on an EU server, with HTTPS and an API key in front. Second, index maintenance: a small sync process pushes changes from your database, your CMS, or your PIM into the search index – for us, typically a workflow or a lean pipeline that runs on every content change.

Third, the frontend: the search bar and the facet filters talk to Meilisearch directly, with a read-only key. Ready-made component libraries exist for React and the common frameworks – the path from «server running» to «search live» is measured in days, not weeks. That is an experience value from our projects: the effort rarely sits in the search itself, but in the question of how good your source data is.

Part of the sync is a deliberate frequency decision: prices and availability want to reach the index promptly (via webhook or on a minute-by-minute schedule), description texts tolerate a nightly run. Sync everything instantly and you pay in complexity; sync everything nightly and you show customers sold-out goods as available. The mix is the normal case.

The underrated part is index design: which fields go in, which become searchable, which facetable? Rules of thumb from practice: description texts searchable but not facetable; categories, manufacturers, and availability as facets; article numbers with exact search instead of typo tolerance. One hour of thinking about these questions saves weeks of relevance patching later.

Which brings us to the real lever: a search is only as good as the data in the index. No search engine can compensate for missing attributes, empty descriptions, and inconsistent categories. This is where enriching catalog data with AI comes in. And if your search requirement grows into a larger project (a portal, a catalog, a web application), you will find the entry points at custom software development and web app development.

If the search on your website or in your shop is a known annoyance, the path can start small: look at your source data, set up a test index, measure with real queries from your users. After that, you know whether Meilisearch, the database search, or a bigger tool is the right stage – before budget flows.

The order matters more than the tool: first understand your users' search queries, then check data quality, then choose the technology. Reverse it, and you optimize a search for queries nobody ever makes. One afternoon with your real search logs delivers more insight than any feature list.

This assessment is exactly what we are happy to take on: we review your data situation, recommend the right stage, and build it, on your infrastructure or on EU servers. Book a free initial consultation – 30 minutes, and at the end you have a reasoned recommendation with a stage classification and a rough cost frame. Even if the recommendation is simply «your database is enough».