Typesense vs Algolia in production (after using both)

I already published a roundup of Algolia alternatives. That post was a catalog. This one is the decision I actually make after shipping search on products people use — including Public, where Algolia and Typesense both appear in the stack for a reason.

The job of search in these apps

Character catalogs, users, posts, and grocery SKUs all want instant, typo-tolerant search. None of them wanted a six-month Elasticsearch project. Algolia sells that feeling as a service. Typesense sells it as software you can run.

When I still pay Algolia

When the team is small, the index is a product surface (search must “just work” globally), and I do not want to own RAM, clustering, or relevancy tooling. You are paying for ops you will not hire. The bill is the feature.

When I run Typesense

When query volume and record count would make Algolia a line item I cannot explain, and when I am already running Redis, Docker, and a Node API. Typesense’s API is close enough that the frontend does not care. I accept backups, versioning, and “someone has to watch the box.”

What I did not reach for first

Elasticsearch/OpenSearch remain right for logs and messy relevance. They are wrong as the first instant-search box for a social app or a kirana catalog. Meilisearch is in the same family as Typesense; I pick on hosting and the ecosystem I already know.

A boring rule

If search quality is the product, buy the hosted specialist until the invoice hurts. If search is plumbing next to a feed or a POS, own Typesense (or equivalent) and spend the money on the API that actually makes money — like one grocery API for three apps or limits on expensive AI routes.

The old list of engines is still useful as a menu. This is the order I reach for the menu.