We are thrilled to announce that the first major release of Meilisearch is here! It's the result of the combined efforts of many people. We are proud to release a completely stable version of Meilisearch, which will guarantee compatibility with future versions of Meilisearch. We are very grateful to our community, which has supported us and helped us to get this far.
Let's take a look at some of the most significant changes. You can read the full changelog on GitHub, but we’ll go over the main ones in this article.
New feature: Korean support
Meilisearch is multilingual and features optimized support for several languages. Thanks to our amazing contributor qbx2, we now support Korean as well.
Improvement: language support
Thanks to the engagement, feedback, suggestions, and PRs of our global community, we improved language support all around with notable enhancements for Chinese:
- Transliteration of Chinese characters into Pinyin to improve relevancy
- Updates to our Chinese segmenter to remove inconsistencies when splitting text into words
- Unification of Chinese character variants to enhance Chinese normalization
We are always looking to improve, join the discussion about Chinese support on GitHub!
Improvement: one-step upgrade
Users of Meilisearch v0.20 or below had to perform a two-step migration to be able to use their database with any version above 0.24. Until now.
v1.0 is compatible with dumps from all previous versions.
We have simplified the process so that anyone can smoothly migrate to our first major version! Check the updating guide in our documentation.
Improvement: indexing and search speed
- We have reduced memory usage of search requests containing multiple long words.
- We have also reduced the computational complexity of the exactness ranking rule and have implemented a caching system, resulting in a significant improvement in its performance, especially for search queries containing many words.
When interpreting a search query, multi-word synonyms are no longer treated as regular search query terms, but as phrases. Suppose you set San Francisco and SF as synonyms. The following search request:
I am going to SF soon
will now be interpreted as:
I am going to "San Francisco" soon
This change prevents requests containing multi-word synonyms from exceeding the word length limit and degrading the search performance. At the same time, it removes a source of denial-of-service attacks, and improves the relevancy of the search results.
- We have tweaked the behavior of the proximity rule for search requests ending with prefixes or very short words to achieve substantial speed improvements.
- Before v1.0, if the settings object contained searchable attributes, updating the settings always triggered a reindex. Now, Meilisearch checks if any changes were made to avoid unnecessary reindexing. Many thanks to GregoryConrad for implementing this!
You will be happy to learn that the following are the last breaking changes we are going to introduce until v2.0 🥳 You can relax for a while, v2.0 is not yet planned ☺️
Check our new versioning policy to learn more about breaking changes.
New master key security requirement
To strengthen security, Meilisearch now requires master keys to be at least 16 bytes when the server environment is set to
production. If none is provided or if it doesn’t meet the criteria, Meilisearch will suggest a secure autogenerated master key you can use when restarting your instance.
Primary key inference revamp
When creating an index or adding documents to Meilisearch, you can set the primary key explicitly or let Meilisearch infer it from your dataset.
To guess the primary key, also known as inference, Meilisearch used to look in your first document for an attribute containing the string
id. Now, it looks for an attribute ending with the string
Furthermore, if multiple attributes ending with
id are detected, Meilisearch will now throw an error asking you to specify the primary key manually using the update index endpoint.
New CLI behavior
--max-task-db have been removed as they were not actually limiting the disk space taken by Meilisearch. This change has two consequences:
- Due to operating system limits on the amount of virtual memory allocatable by a single process, the number of indexes that can exist simultaneously in a Meilisearch database are:
- around 200 for Linux/MacOS
- around 20 for Windows
2. The size of an index is limited to 500GiB
While we plan on lifting the limitations described above in v1.1, if any of these changes affect you, it would be of great help to have your input. You can find more details in this GitHub discussion.
Since its introduction in v0.26, the auto-batching feature has proven its worth. The
disable-auto-batching CLI option and the associated environment variable
MEILI_DISABLE_AUTO_BATCHING, which had been kept for debugging purposes, are no longer needed and have been removed.
We’re also removing the
--snapshot-interval-sec flag to make scheduling snapshots simpler.
meilisearch --schedule-snapshot --snapshot-interval-sec 3600
meilisearch --schedule-snapshot 3600 # If no value is provided, Meilisearch will take a new snapshot every 24 hours.
Finally, for the sake of consistency, the
--dumps-dir CLI option has been renamed to
--dump-dir, which is more idiomatic and in conformity with other existing options.
Error handling improvements
To provide greater clarity and predictability in the use of the API, we have added granular error codes and a new
system error type. You can consult the detailed list in the changelog.
A big thank you to all our contributors! We couldn't have reached this milestone without your support. You're really, truly great and we can't thank you enough for all the effort, suggestions, comments, and time you dedicate to Meilisearch. We are so grateful to have such an amazing community.
This month, we want to send a special shout-out to @amab8901, @colbsmcdolbs, @elbertronnie, @funilrys, @jiangbo212, @mohitsaxenaknoldus, and @shivaylamba for their help with Meilisearch, and to @amab8901, @GregoryConrad, and @pnhatminh for their contributions to Milli. Likewise, we would like to thank @choznerol, @crudiedo, @daniel-shuy, @harshalkhachane, @mosuka, @qbx2, @Roms1383, @Sokom141, and @yenwel for their precious support on Charabia.