ledoublegui's comments

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 :)

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?

Thanks for your answer dawnerd. I will take a look at it with fresh eyes, we may have missed something :)

Thanks adrianvincent! Did you see https://docs.meilisearch.com/reference/features/filtering.ht...?

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!

Hi berkes! (Guillaume from the MeiliSearch team here) I'm glad to see you were able to implement a solution for your project ;)

Hi dawnerd! Sorry to hear that, do you have the issue link so that we can take a look at it?

Based on the informations I can read here, I think it comes from the fact that the engine is not able to give an exhaustive finite number of records matching the query for reasons of response time. A finite pagination style (with number of pages) on the client-side is for now a pure work-around.

From what I understand, some of our users try to use MeiliSearch as a primary datastore or expect a classic finite pagination coming from a SQL database env, when we are here to solve search relevancy problems.

Ideally the search results should be relevant enough so that end-users don't have to click on another page selector button, that's why we advocate to integrate a pagination without number selection. Infinite scroll style or prev/next.

Happy to discuss this further with more context!

Thank you for your feedback :)

Hi! MeiliSearch product team here! It's super cool to see your feeback!

Concerning the disjunctive count of the facets, we are thinking about it. It is feasible on the client side by making several requests but we are aware that is it not ideal at all from a developer experience point of view. We are still thinking about the best way to solve that case in one of our future iterations!

The sort feature is coming in v0.22 (string and numeric fields) you will be able to easily configure the balance between exhaustivity and relevancy at index level through the positioning of the ranking rules.

I'm not sure I understand the where clause point so I'd love to hear more details!

Thanks for using us and giving us this kind of feedback :)