Application search is the decision to evaluate
Meilisearch puts full-text, semantic, and hybrid search behind a REST API. Its README lists typo tolerance, filtering, facets, sorting, synonyms, and geosearch, plus SDK integrations. These are useful reasons to shortlist it for application search. Our recorded run establishes a source-build result, not how well those features perform on your data.
The current README describes both self-hosting and Meilisearch Cloud. It says Cloud handles deployment, upgrades, and backups, while self-hosting lets a team operate its own infrastructure. A long source build therefore matters most to contributors and teams producing their own artifacts. It does not measure the time required to deploy a published binary or create a managed instance.
Check the edition before designing around scaling
The README describes Community Edition as MIT-licensed, including the core full-text, semantic, and hybrid engine. Enterprise Edition includes sharding, S3-streaming snapshots, and, in the current README, search rule previews. Its production use requires a commercial agreement; the listed terms are a commercial license or Business Source License 1.1. The pinned README for our measured commit lists sharding and S3-streaming snapshots, so current documentation should not be treated as an exact feature inventory for that commit.
For self-hosting, plan how documents reach the index, where persistent data lives, and who can search or change it. The README describes API keys with fine-grained permissions and points to tenant-token guides. It also says Meilisearch collects anonymized user data and allows collection to be deactivated. We did not test permission enforcement or inspect telemetry traffic.
What our recorded run establishes
Our run began on 2026-10-04 at 04:09:09.224 UTC, using commit a85bd66e9d7ce30e8e33a17db54b3a2de612e086, dated 2026-09-29. The recorded sandbox had 3 CPUs, 12 GB of RAM, and image lab-rust:1. The image label does not establish the actual runtime version.
The dependency-download step completed successfully in 48 seconds, with 783 dependencies recorded. Its tail shows downloaded Rust crates. This is evidence of dependency retrieval, not an installed-binary check.
The build step succeeded in 705 seconds. Its tail identifies meilisearch v1.54.2 and a completed unoptimized dev build. The checkout measurements were 1,746 files, about 269,102 source lines, and 33.4 MB. These describe this source checkout and build environment; they are not production storage or memory requirements.
The cargo test step ran for 846 seconds and exited 101 without timing out. The raw tail identifies the Meilisearch integration target as failed. It includes names such as vector::openai::bad_api_key and vector::rest::bad_response, but names alone do not explain why those tests failed.
The stored parser aggregates are 546 passed, 1,780 failed, and 2,326 total. The log repeats summaries around a replay marker, so those values may double-count suites. We preserve them as historical parser measurements and do not use them to calculate a pass rate or describe unique, exhaustive test totals. The ignored tests are not failures, and their recorded timeout or issue notes do not explain the other failures.
No installed-binary check, live search benchmark, production deployment, or audit is recorded. The run therefore supports neither a production-readiness guarantee nor a conclusion that Meilisearch is broken.
Release notes and issue reports have narrower meanings
The supplied v1.54.3 release page, dated October 1, describes an important stability fix and recommends updating from v1.54.2. Our build tail identifies v1.54.2, so this run is not a test of v1.54.3. The release note also does not establish that its fix explains our test failure.
The supplied issue listing contains reports about stalled request bodies and an S3 snapshot endpoint freezing the scheduler, both opened October 4, 2026. It lists the /similar admission-control report as opened October 20, 2026. These are reported issues, not failures we reproduced, and the later report is not an observation from our October 4 run. Use relevant reports to shape your own validation rather than infer a general reliability verdict.
Compare engines against the same requirement
Typesense's README describes typo tolerance, faceting, filtering, and semantic or hybrid search. That makes it a relevant application-search comparison. Elasticsearch describes itself as a distributed search and analytics engine and lists logs, metrics, full-text search, and vector search among its use cases. Evaluate it when those analytics requirements are part of the job. We did not benchmark either alternative against Meilisearch.
For a useful next step, select your intended Meilisearch release and deployment path, then test representative documents and queries. Check relevance, ingestion completion, permission boundaries, and backup recovery. If building from source is part of your release process, investigate the failing integration target with complete logs before making that command a release gate.
How to read the scores
These are editorial evidence ratings on a 1-5 scale: 1 means substantial documented obstacles; 2 means limited supporting evidence; 3 means a usable path with material validation gaps; 4 means strong evidence across the assessed area; 5 requires broad direct validation. Unknowns do not earn a high score. Setup reflects the recorded source path and documented deployment options; docs reflects the supplied README rather than an end-to-end documentation audit; community reflects visible participation channels and issue reports; maturity reflects release evidence and the limits of our run. None is a performance or security rating.