Hi, rvz! (Product team member of MeiliSearch here). This comparative table is not accurate and contains wrong pieces of information about MeiliSearch.

However, today TypeSense indeed has more features than MeiliSearch. After a long time of refactoring the engine's source code, we now have a solid base to welcome new features/improvements, and we hope to evolve quickly to solve many more search use-cases.

For Q3, we plan to add two new features: sort by and geo-search. The geo-search will come out as a first iteration allowing to sort documents around a geographical point and filter documents within a circle. We will also further improve the indexing speed (again yes, because we can do better) and provide two new formats for data indexing (csv and ndjson).

For Q4, we plan to add high availability and solve the multi-tenancy use-case.

That is just a preview of the upcoming features we are already working on.

The end of the year will be rich in evolution for MeiliSearch. We are looking forward to seeing you enjoy using MeiliSearch one day!

Hey Meili team, I work on Typesense and I’m the one who put that comparison matrix together. My intention was to provide as much factual information as possible based on my reading of each search engine’s documentation. This is one reason I stuck to a feature by feature comparison rather than an opinion based comparison for this particular page.

So if you see anything that’s wrong in the matrix, I apologize. Please do let me know which items are wrong and I would love to correct them.

Hi jabo! Thank you very much. That is very kind of you. It's always difficult to establish this kind of matrix when you can't necessarily know all the technical details and features with that level of details you wanted to emphasize. I'll get back to you with the list of points we think were misunderstood in a couple of days! Which medium do you prefer?

Sounds good! Email would be great: jasonb at typesense d0t org

Your plans seem spot on for our needs, especially regarding geo search! HA and multi tenancy are a must-have for our use case, though. Would it be possible to have a single large highly available index with tenants of wildly different sizes?

I will surely keep a close eye on your developments. Thank you!

Hi, clon!

"Would it be possible to have a single large highly available index with tenants of wildly different sizes?"

Yes, we can imagine API keys allowing each consumer to have access to a certain number of documents in an index. When querying the index, the internal filters allowing to select the documents accessible by this API key are automatically inferred and added to the initial query of the consumer. In short, it's a bit like a WHERE clause that would be fixed at each query.

I'm not sure if it answer your question, so don't hesitate to reach me!

I'm available to discuss your use cases from our community slack or by email :)

Thank you! That indeed is what I was hoping to hear.