Awesome. I've tried MeiliSearch and it is very easy to set up and use. It works very well for less than a million of data.
The only let down for me is their very slow indexing speed when it comes to millions to tens of millions of data (personal experience, also experienced by other users in their public slack workspace).
I wanted to thank you for your feedback. I also wanted to confirm that several people have given us feedback on indexing speed problems.
That is why we have decided to focus on this issue during the first quarter of 2022. We have already made a lot of progress on indexing speed, and we can't wait to show you these new capabilities with the arrival of v0.26.0.
Thanks for the reply, @qdequelen. Nice to know you guys are working on the indexing speed. That is what I missed in the "What's next?" session in the blog post. Looking forward to seeing what you guys will deliver
Hi @qdequelen, thanks for that comparison table, I've never seen that before.
Thank you also for putting indexing speed in your priority, I'm sure there are other people with large datasets who are also looking forward to it.
It must be challenging, each search engine has their own best use cases right now, different requirements, and different trade offs. E.g. typesense requires decent amount of cpu and ram, quickwit allows s3 storage but doesn't support document update and delete operations yet, lol. Lovely progress too on each projects.
To answer your third point. Indeed, each solution has its own positioning, which implies requirements and trade-offs. I don't know the positioning of Typesense and Quickwit so I would have difficulty speaking on their behalf. But I have the impression that Quickwit is the new Elasticsearch. In the long term, they will surely position themselves in front of them, put themselves on the log market, and why not of the security analysis. It is impossible to update or delete data makes me think of this. A system capable of managing terabytes of data with precise and fast tasks. Even if it is far from the need of instant search.
On our side, we have a clear focus on user-facing search. All searches can improve the user experience and increase user satisfaction and product retention. Use cases today are mainly E-commerce, marketplace, site-search, media, SaaS application, B2C applications. The needs for these use cases are the same. Search in a fixed data type with incredible relevance and performance.
Moreover, I want to underline this because I see that you mention it in your comments. At Meilisearch, we have made it a point of honor to offer a solution with the best possible developer experience. Everything we do (API, SDK, Documentation), we do it with developer experience in mind.
I pretty much agree with you qdequelen, Quickwit and Meilisearch are targeting 2 very different markets: user facing search for Meilisearch and what I would call "search analytics on large (almost) immutable datasets" for Quickwit. We want to handle deletes in 2022 in the form of "delete by query" but it will be quite a heavy operation and you won't be able to do that too often (few times per day typically). So yes, log market is one of our target, plugging Quickwit search to ClickHouse was also pretty fun.
And as concerning the "best possible developer experience", Meilisearch is very inspiring and we want to follow the same path :)
Thanks for sharing, we did do a POC of it in the company I work for as an alternative for elastic-search, and it worked pretty well(in most cases).
Unfortunately, we end up not moving forward with it because we need new ingestion to be available super quickly. I hope to see new versions improving that too.
Thanks for the list of competitors. I will take a look at them
Similar exp lol. I was instantly sold at the ease of installation, great documentation, and the built-in search interface web app.
Had to put it on the side for a while when I noticed it just indexed 3m docs in 8hrs (compared to 70m docs in 8 hrs of same data on elasticsearch). There were tips given on their slack but we found it a bit too hacky (at that moment) for our use case (you know, worries that will such approach be consistent or broken on next versions, things like that).
Nevertheless I still think it's perfect for hundreds of thousands of documents at the moment (just not millions yet).
Indeed for the moment, I would not advise going to more than a few million documents, especially if you want to make regular updates. With the new update that we will release in March, I think we will go up to a few tens of millions of documents with much higher update frequencies. However, we keep in mind that Meilisearch should do much, much more. This will be a work in progress for us during the year, as we plan in the future to allow Meilisearch to be no longer a search binary with limited resources but as a globally distributed solution that will have no limits to scale. But it's still too early to talk about our long-term plans on how we will improve user-facing search. #serverless
10 comments
[ 3.5 ms ] story [ 34.9 ms ] threadThe only let down for me is their very slow indexing speed when it comes to millions to tens of millions of data (personal experience, also experienced by other users in their public slack workspace).
Other competitors / alternatives:
- https://github.com/typesense/typesense
- https://github.com/quickwit-oss/quickwit
- https://github.com/elastic/elasticsearch
- https://github.com/valeriansaliou/sonic
A decent feature-by-feature comparison:
- https://typesense.org/typesense-vs-algolia-vs-elasticsearch-...
If you guys know other open-source competitors / alternatives, I'd love to check those out!
I wanted to thank you for your feedback. I also wanted to confirm that several people have given us feedback on indexing speed problems.
That is why we have decided to focus on this issue during the first quarter of 2022. We have already made a lot of progress on indexing speed, and we can't wait to show you these new capabilities with the arrival of v0.26.0.
If you want another comparison table we have also made our own. https://docs.meilisearch.com/learn/what_is_meilisearch/compa...
Thank you also for putting indexing speed in your priority, I'm sure there are other people with large datasets who are also looking forward to it.
It must be challenging, each search engine has their own best use cases right now, different requirements, and different trade offs. E.g. typesense requires decent amount of cpu and ram, quickwit allows s3 storage but doesn't support document update and delete operations yet, lol. Lovely progress too on each projects.
On our side, we have a clear focus on user-facing search. All searches can improve the user experience and increase user satisfaction and product retention. Use cases today are mainly E-commerce, marketplace, site-search, media, SaaS application, B2C applications. The needs for these use cases are the same. Search in a fixed data type with incredible relevance and performance.
Moreover, I want to underline this because I see that you mention it in your comments. At Meilisearch, we have made it a point of honor to offer a solution with the best possible developer experience. Everything we do (API, SDK, Documentation), we do it with developer experience in mind.
I pretty much agree with you qdequelen, Quickwit and Meilisearch are targeting 2 very different markets: user facing search for Meilisearch and what I would call "search analytics on large (almost) immutable datasets" for Quickwit. We want to handle deletes in 2022 in the form of "delete by query" but it will be quite a heavy operation and you won't be able to do that too often (few times per day typically). So yes, log market is one of our target, plugging Quickwit search to ClickHouse was also pretty fun.
And as concerning the "best possible developer experience", Meilisearch is very inspiring and we want to follow the same path :)
Unfortunately, we end up not moving forward with it because we need new ingestion to be available super quickly. I hope to see new versions improving that too.
Thanks for the list of competitors. I will take a look at them
Had to put it on the side for a while when I noticed it just indexed 3m docs in 8hrs (compared to 70m docs in 8 hrs of same data on elasticsearch). There were tips given on their slack but we found it a bit too hacky (at that moment) for our use case (you know, worries that will such approach be consistent or broken on next versions, things like that).
Nevertheless I still think it's perfect for hundreds of thousands of documents at the moment (just not millions yet).