Typesense vs Meilisearch for Indie Apps: Which Search Engine You Can Actually Operate Alone

Meilisearch already has a reputation on this site as the indie alternative to Elasticsearch. Typesense is the other small engine people mention in the same breath, usually after a HN thread and before anyone has restored a snapshot. I ran both for a docs site and a catalog-shaped side project. The question I care about is not “which ranks better in a demo.” It is which one I can keep alive as a single operator when the index looks fine and the queries feel haunted.

Elasticsearch is out of scope except as a warning. If you need aggregations that look like a BI tool, you are not in this article. If you need “type three letters and see products,” you are. If even that daemon is too much box for a tiny app, SQLite FTS5 versus Meilisearch is the smaller fork.

What both engines are for

Typesense and Meilisearch are typo-tolerant search servers you can actually start with Docker Compose. They ingest JSON documents. They return hits fast. They offer ranking knobs that are friendlier than Lucene priesthood. They are not your database. If you treat them as a database, you will eventually restore the database and wonder why search is a week behind.

The cultural difference is real. Meilisearch feels like a product company that wants you on their cloud and their dashboard. Typesense feels like a search server that grew a cloud. Either cloud is fine if you do not want a container. This piece assumes you might self-host, because that is when “operate alone” stops being a slogan.

Indexing and the schema fight

Meilisearch has gotten stricter about settings and documents over the years in a way I appreciate. You declare searchable attributes, filterable attributes, ranking rules. You send documents. You wait for the task queue. The task queue is the first honest thing about Meilisearch ops: indexing is asynchronous, and “the API said 202” is not “the user can find it.”

Typesense wants a collection schema up front. Fields have types. That is annoying on day one if your documents are sloppy. It is a gift on day thirty when you try to filter on a field you never declared. I have shipped a Meilisearch index where a field was searchable but not filterable because I forgot a settings update, then spent an hour blaming the query. Typesense would have refused me earlier. I prefer being refused.

Nested documents and arrays are where both get less cute. Read the docs for your exact version before you invent a document shape. I flattened more than I wanted to on both. Flattening is not a defeat. It is how you stay an indie instead of a search consultant.

Relevance: knobs versus surprises

Out of the box, both handle typos well enough that users think you are clever. The first custom ranking rule is where you learn the product.

Meilisearch ranking rules are a list you reorder: words, typo, proximity, attribute, sort, exactness, and your own sortables. It is understandable. It is also easy to put a business sort too high and watch typo-tolerance collapse into “whatever is newest.” I did that with a publishedAt sort and spent a week hearing that search was “random.” It was not random. It was me.

Typesense ranking is more explicit about query-by and weights, and the optional sort_by on the query. I found it easier to say “this field matters more” without accidentally flattening the rest of relevance. I also found it easier to build a query that only a future me would remember. Write the ranking intent in a comment in the client. Neither engine will remember why you were clever.

Synonyms, stop words, and locale are table stakes. Test your real language, not English lorem. A catalog with SKUs and model numbers will punish both engines if you treat SKUs like prose. Give SKUs their own field and boost them. This is not engine-specific wisdom. It is how you stop blaming Typesense for a document you designed as a blob.

Ops: the part demos skip

RAM is the constraint I watch. Both want to be fast, which means they want memory. On a 2 GB VPS I have watched Meilisearch get uncomfortable with a fat docs index and too many filterable attributes. Typesense was not magically tiny. “Lightweight versus Elasticsearch” is not “tiny versus a Raspberry Pi 3.” Size the box for the index, not for the blog post.

Disk snapshots are your real HA. I do not run multi-node search for an indie app. I run one node, a compose file, and a backup I have restored once on purpose. Meilisearch dumps and snapshots exist. Typesense snapshots exist. If you have not restored one, you do not have a backup. You have a file you feel good about.

Upgrades are the other solo-operator tax. Read the changelog. Pin the image. Do not float latest on a Friday. I have had a settings default change the meaning of a ranking rule. The query still returned 200. The hits were a different product. That is worse than a crash.

Healthchecks belong on the search container the same way they belong on everything else. A process that is up and an index that is empty are different failures. If you only ping TCP, you will serve a beautiful empty state after a volume mount goes wrong.

APIs, keys, and the frontend temptation

Both want you to search from the browser with a search-only key. That is fine for public docs. It is less fine if your index contains anything you would not print on a billboard. I keep a thin backend route for anything with user data, even if it adds 20 ms. A search-only key in a SPA is a public document dump with extra steps if the documents were greedy.

Admin keys in environment variables, not in the repo. Rotate them when a contractor leaves, even if the contractor was you on a second laptop. I say this because I once found an admin key in a Netlify screenshot. The screenshot was cropped badly. The key was not.

Meilisearch’s instant-search ecosystem is polished. Typesense’s is good. Do not pick an engine because of a React component. Pick the engine, then pick a client. Swapping the widget later is cheaper than swapping the ops model.

Cloud versus a box you own

If search is on the critical path of a paid app and you do not want to think about disks, pay for hosted. Typesense Cloud and Meilisearch Cloud both exist so you can stop being a DBA. The indie move that fails is self-hosting to save $40 and then losing a weekend to a corrupt volume. I have paid the $40 after that weekend. I did not feel less indie. I felt like I could ship.

Self-host when the corpus is modest, the machine already exists, and you have a restore drill. A homelab search for personal docs is a great self-host. A customer-facing storefront on a single NUCs’s Docker is a story you will tell after an outage.

Multi-index apps and the one-brain problem

A docs site plus a changelog plus a blog will tempt you into three indexes. That can be correct. It can also be three backups, three schemas, and three ways to forget a filterable field. I keep one index when the documents share a type field I can filter. I split when ranking rules fight each other — products want stock and price, docs want heading proximity.

Facets are how storefronts look smart. They are also how RAM grows. Every filterable attribute is a promise you will use it. I have marked six fields filterable “just in case” and paid for it on a small VPS. Start with the two facets users already ask for. Add the third after someone complains.

Analytics are optional until they are not. If you cannot see zero-result queries, you cannot fix synonyms. A cheap log of q= parameters in your own backend beats a fantasy dashboard. I paste a weekly sample into a note. It is ugly. It finds the SKU format nobody indexed.

Which one I would operate alone

For a new public docs site or a small catalog with a schema I can declare, I would pick Typesense. The schema friction saves me from sloppy filters. The ranking controls match how I explain relevance to myself.

For a project already in the Meilisearch orbit, or a team that likes their dashboard and cloud story, I would not migrate for sport. Meilisearch is not the wrong engine. It is the engine whose async tasks and settings API I have already been bitten by, so I treat the task queue as part of the product. Typesense bites differently. You still need the restore drill.

I would not run both. Two search engines is how a solo operator creates a new job called “why do these hits disagree.” Pick one. Put the documents in git or in the primary database. Treat the engine as a projection. Reindex from source when you are unsure. Reindexing is slower than arguing with a replica.

Elasticsearch can wait until a query needs a workplace. Until then, the honest choice is the smaller engine whose snapshot you have actually opened. Typesense is the one I would install on a quiet box today. Meilisearch is the one I would keep if it was already there and paid. Neither replaces thinking about your documents. The documents are the product. The engine is the index you can afford to lose and rebuild before lunch — if you designed it that way, and if you practiced.