At some point you’ve shipped a product with a search bar that didn’t work. Maybe it returned nothing for “recieve” when the correct spelling was in the database. Maybe it showed results for “blue shirt” that had nothing to do with blue or shirts. Maybe it just timed out under mild load and you quietly added “search is coming soon” to the roadmap. Bad search is one of those things users notice immediately and developers dread building. Meilisearch is what I reach for now when a project needs search that actually works without a six-week implementation.
This Meilisearch review pulls from actual projects I’ve shipped with it. Fast? Yes. Genuinely easy to set up? Embarrassingly so. But I also hit some walls nobody warned me about. So here’s the version that includes both.
It runs on Rust, it’s open source, and the philosophy behind it is basically “search should not require a three-day Elasticsearch configuration session.” You deploy it yourself or you use their cloud. Both paths work. Both paths take hours rather than weeks. I’ve set it up on a fresh server faster than I’ve ever set up anything involving Elastic, and I say that as someone who has lost entire afternoons to Elasticsearch cluster configurations that should have taken 30 minutes.
Features
Typo tolerance is the feature that sells most developers on Meilisearch, and it earns that reputation. It handles single-character typos by default, scales to two-character tolerances for longer words, and doesn’t require you to set up fuzzy matching rules manually. Someone searching “recieve” finds “receive.” Someone typing “macbook” finds “MacBook Pro.” That sounds obvious but the number of search tools that get this wrong is embarrassing. Meilisearch gets it right, and it does it fast, usually returning results in under 50 milliseconds even on datasets with millions of records.
Faceted search is built in and it’s one of the better implementations I’ve worked with. You define your filterable attributes when you index your data, and Meilisearch handles the facet counts automatically. Building a product filter with price ranges, categories, and availability used to mean a pile of custom query logic. With Meilisearch you configure the attributes and write one filter query. The implementation is genuinely clean. Not “clean for a search engine” clean. Actually clean.
The ranking rules are configurable and follow a sane default order: typo count, number of matching words, proximity of matching words, exact matches, document ranking. You can reorder these or add custom attributes to the ranking. This matters when your product has specific business logic that generic relevance scoring doesn’t capture. An e-commerce site might want to weight inventory availability. A content platform might want to weight recency. Meilisearch supports that without requiring you to write a custom scoring function from scratch.
Semantic search landed in version 1.6 and it’s a bigger deal than the release notes made it sound. Hook up an embeddings provider and you get hybrid search, keyword plus vector, in the same query. What that means in practice: a user typing “comfortable chair for sitting all day” will find ergonomic office chairs even if your product data never uses those exact words. Needs OpenAI or HuggingFace to work, but wiring it in is maybe an afternoon. Not every project needs it. For anything where users search in natural language rather than exact terms, though, it’s worth the setup time.
How to Use
Setup is fast. Embarrassingly fast for something this capable. Download the binary, run it, search engine is live at port 7700. From there you send JSON to the REST API and you’re indexing documents. I had curl queries running in under ten minutes the first time I tried it. SDKs cover JavaScript, Python, Ruby, Go, PHP, Rust and more. I mostly use the JavaScript one. TypeScript support is solid and doesn’t feel like an afterthought.
Indexing works by sending documents as JSON arrays to the API. Meilisearch handles the rest: it builds the index, figures out the document structure, and makes everything searchable. No schema definition required upfront. You can add documents with new fields and Meilisearch incorporates them without rebuilding from scratch. That flexibility is useful during development when your data model is still changing.
The dashboard at localhost:7700 is a nice touch. You can browse your indexes, run test queries, tweak settings, and see real-time performance metrics without building anything custom. For debugging search relevance issues during development, having a visual interface right there saves a lot of back-and-forth between code editor and Postman.
Most people pick this up fast. The query syntax doesn’t have a lot of sharp edges, the docs are actually readable, and when something breaks the error messages tell you what broke. Ranking rules and semantic search have a steeper curve, but here’s the thing: you don’t touch those on day one. They’re optional depth. Basic implementation? Most developers are shipping something real within a day.
Pros and Cons
Pros:
- Sub-50ms search on large datasets. Not marketing copy. Consistently reproducible in production.
- Typo tolerance works correctly out of the box. No configuration required to handle common user input errors.
- Developer experience is one of the best in this category. Clean API, good SDKs, actually useful documentation.
- Faceted search built in without needing a separate aggregation query. Saves significant implementation time on filtered search UIs.
- Self-hostable and free. The open-source version has no feature restrictions, just your own infrastructure costs.
- Semantic search support with version 1.6 opens up natural language queries for projects that need them.
Cons:
- It’s a search engine. Not a database. Aggregations, GROUP BY, SUM queries — wrong tool entirely. Don’t make it do things it wasn’t built for.
- Index rebuilds on large datasets are slow and block writes during the process. Plan your update strategy carefully at scale.
- Horizontal scaling requires a paid plan or significant self-hosted infrastructure work. The single-node architecture hits limits before some other engines do.
- Multi-index search (searching across multiple indexes simultaneously) is possible but the implementation is less elegant than some competitors.
- The cloud offering is still maturing. Self-hosting is more battle-tested than Meilisearch Cloud for high-traffic production use.
- No built-in analytics on search queries. You have to instrument this yourself if you want to understand what users are searching for and what’s returning poor results.
Pricing
Self-hosted costs nothing. Zero. The open-source version is fully featured, no paywalled capabilities, no enterprise tiers hiding the good stuff. You cover your own server. On a cheap VPS that might be $5 a month. A lot of teams run it that way forever and never feel the need to upgrade.
Cloud starts at $30 a month. Build tier, 100k documents, reasonable throughput. Step up to $300 for the Grow tier when you need more. Enterprise is custom pricing with actual SLAs and dedicated infrastructure for teams that can’t afford surprises.
The comparison worth making is against Algolia, which is the default choice for a lot of teams that want managed search without the self-hosting complexity. Algolia charges $0.50 per 1,000 search requests on their standard plan. At any meaningful traffic volume, that adds up faster than the Meilisearch Cloud flat rate, and Algolia’s free tier is significantly more restrictive. If you’re choosing between the two, Meilisearch wins on cost at almost every scale. It loses on managed reliability, global CDN distribution, and the sheer breadth of the Algolia ecosystem.
Who’s It For
Developers building search for SaaS products or e-commerce. Product catalogs, documentation search, content libraries. Meilisearch covers everything those use cases need: fast keyword search, typo tolerance, faceted filtering, relevance tuning. Setup time is a fraction of what Elasticsearch demands. A two-person engineering team can maintain it without a search infrastructure specialist on retainer.
Startups and indie developers who want Algolia-quality search without Algolia pricing. The self-hosted option is genuinely production-ready and the documentation is good enough that you don’t need a search infrastructure specialist to run it. I’ve seen two-person teams run Meilisearch in production on a $20 VPS for over a year without incident. That kind of reliability at that price point is hard to find.
Skip it if you need enterprise-scale distributed search or analytical capabilities. Teams running billions of documents across distributed clusters, or needing complex aggregations and real-time analytics on search data, will outgrow Meilisearch’s architecture. Elasticsearch or OpenSearch is the better fit for those requirements. Meilisearch is excellent at what it’s designed to do. It’s not designed to replace a data warehouse with a search frontend bolted on.