If you've ever priced out Algolia for a side project and quietly closed the tab, you're not alone. Instant, typo-tolerant search is one of those features users notice immediately when it's missing, and most of the "just use Postgres full-text search" advice falls apart the moment someone fat-fingers a query or expects results in under 50ms.
Meilisearch is the open-source answer I keep coming back to. It's a Rust search engine, single static binary, and the defaults are genuinely good — you don't spend a weekend tuning analyzers before it feels usable.
What it actually gets you
- Typo tolerance out of the box. No config, no synonym files to seed before it's useful. Search "akira" or "akria" and you get the same result.
- Sub-50ms responses on reasonably sized indexes, even on modest hardware — it's not chasing Algolia's infra budget, it's chasing Algolia's feel with a fraction of the resources.
- A real search API, not a vector DB pretending to be one. If you're building RAG retrieval and don't want to stand up a dedicated vector database just to keyword-filter before an embedding search, Meilisearch's hybrid search (keyword + vector) covers a decent chunk of that need without adding another moving part to the stack.
- Official SDKs for JS, Python, Ruby, PHP, Go, Rust — it's not a bare HTTP API you're gluing together yourself.
The part people get wrong: production mode
Meilisearch ships with a dev mode that has no auth by default. Fine for localhost, a real problem if you deploy it to a public host and forget to flip MEILI_ENV=production + set a MEILI_MASTER_KEY. Without that, your index (and whatever data it's indexing) is wide open to anyone who finds the URL. It's a one-line env var, but it's the kind of thing that's easy to skip when you're just trying to get something running.
Deploying it
Raw Docker, if you want to run it yourself:
docker run -p 7700:7700 \
-e MEILI_ENV=production \
-e MEILI_MASTER_KEY=$(openssl rand -hex 24) \
-v meili_data:/meili_data \
getmeili/meilisearch:v1.46.1
Mount /meili_data as a real volume — that's where your indexes live, and it needs to survive restarts.
If you'd rather not manage the box: full disclosure, I maintain a one-click Railway template for this and get a kickback if you deploy through it — https://railway.com/deploy/meilisearch-lite?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=inventory. It's the stock getmeili/meilisearch:v1.46.1 image, pinned version, with the volume, production mode, and a generated master key wired up so you don't hit the wide-open-by-default trap above. Same image either way — the template just saves you the networking/volume/env setup.
Using it
Health check first:
curl https://<your-domain>/health
# {"status":"available"}
Then index and search:
curl -X POST 'https://<your-domain>/indexes/movies/documents' \
-H 'Authorization: Bearer <MEILI_MASTER_KEY>' \
-H 'Content-Type: application/json' \
--data '[{"id":1,"title":"Akira"}]'
curl 'https://<your-domain>/indexes/movies/search?q=aki' \
-H 'Authorization: Bearer <MEILI_MASTER_KEY>'
Where it falls short
It's not a vector database. If your primary need is large-scale semantic/embedding search over millions of vectors, a dedicated vector DB (Qdrant, pgvector) will out-perform Meilisearch's hybrid mode at scale. And RAM/disk scale with index size, so a huge catalog means a real resource budget, not a free-tier toy deploy. Where it earns its keep is the middle ground: app search, docs search, e-commerce search, or a keyword layer in front of a RAG pipeline — anywhere "fast and typo-tolerant" matters more than "state of the art semantic recall."
Top comments (0)