Search has quietly become one of the more confused areas of engineering practice, because the arrival of embeddings convinced a lot of teams that vector similarity had replaced keyword matching. It has not, and the teams that ripped out their inverted index in favour of pure semantic search learned this when users searched for an exact product code and got thematically related nonsense. Keyword search is precise and literal. Vector search understands intent and is vague about specifics.
The correct answer in almost every real application is both, combined with a ranking strategy, and that is exactly what hybrid search means. Meilisearch's documentation treats this as the normal case rather than as an advanced topic, which is the right framing and is more useful than most of the RAG literature. The engine's positioning is Algolia's convenience with an MIT licence and the option to self-host. That comparison is fair.
Algolia is excellent and expensive, with per-query pricing that makes some applications economically awkward, and its academy is a JavaScript shell I have complained about elsewhere. Meilisearch gives you an engine you can run yourself, sensible defaults, typo tolerance that works without configuration, and sub-100 millisecond responses on reasonable corpus sizes. The documentation covers the API surface thoroughly, the SDKs across more than ten languages are genuinely documented rather than listed, and the live demo applications for ecommerce, movie search and SaaS use cases let you see behaviour before writing code. The AI features are integrated rather than appended.
Configure an embedder and Meilisearch generates vector embeddings for your documents automatically, then hybrid search lets you blend keyword and semantic results with a weighting you control. There is conversational retrieval for RAG applications and similar-document lookup. The reason this matters is that the usual alternative involves running a separate vector database, maintaining an embedding pipeline, keeping two indexes in sync, and merging results yourself, which is a meaningful amount of infrastructure to own for a capability most applications want and few need to build from parts. Where the documentation is weak is the thing that actually determines whether a search implementation is good.
Relevance tuning is the discipline of search engineering: deciding what ranking rules apply and in what order, when recency should beat text match, how to weight fields so a title match outranks a body match, how to handle synonyms and stop words for your domain, and how to measure whether a change improved anything rather than trusting a demo query. Meilisearch has ranking rules and the documentation explains what they do. It does not really teach you how to reason about them, and the defaults, particularly around typo tolerance, are opinionated in ways that are not fully explained. A team that ships default configuration will get decent results and will not know why the results are what they are, which is fine until someone complains and nobody can diagnose it.
There is no academy, no course and no certification, which is consistent with the rest of this category and still a missed opportunity. Search relevance is exactly the kind of subject that benefits from structured teaching with worked examples, and a vendor that taught it well would be doing something genuinely differentiated rather than publishing another API reference. The licensing needs attention before you commit. The core engine is MIT, which is as permissive as it gets and is a real advantage over source-available competitors.
Meilisearch has also introduced an Enterprise Edition licence, and anyone planning to build on this should read where the boundary falls rather than assuming MIT covers everything with the Meilisearch name on it. This is the same caution I would apply anywhere an open core company adds a second licence, and it is not an accusation, just the due diligence the documentation does not prompt you to do. Cloud pricing starts at around thirty dollars a month on the entry plan with document count limits, rising through resource-based tiers. That is reasonable against Algolia for most workloads, and self-hosting remains genuinely viable rather than nominally permitted.
Four point zero. Clear, practical documentation with the best free explanation of hybrid search I have found, an MIT core that makes ownership real, and near silence on relevance tuning, which is the skill that separates working search from search that merely responds.