All Versions
75
Latest Version
Avg Release Cycle
6 days
Latest Release
83 days ago

Changelog History
Page 3

  • v1.39.0 Changes

    March 16, 2026

    What's Changed

    ✨ Enhancement

    πŸ”¬ Cross-index document hydration

    βž• Add a new ForeignKeys setting allowing to hydrate documents with documents coming from other indexes.

    πŸ‘ > πŸ““ Note: This implementation doesn't support a remote sharding environment

    foreignKeys experimental feature

    A new experimental feature, foreignKeys, has been added to the /experimental-feature route that must be set to true to activate the hydration.

    curl -X PATCH 'http://127.0.0.1:7700/experimental-features' \
      -H 'Content-Type: application/json' \
      --data-binary '{"foreignKeys": true}'
    
    foreignKeys index setting

    A new index setting, foreignKeys, has been added to the /indexes/{index_uid}/settings:

    // new setting, an array of foreign keys that allows multiple foreign relationships between indexes"foreignKeys": [
        {// the path in the JSON document containing foreign document ids"fieldName":"actors",// the UID of the foreign index containing the documents to fetch during hydration"foreignIndexUid":"actors"}
    ]
    
    Example

    With this new feature, a document shaped as follows:

    {"id":1,"title":"Forrest Gump",// Document IDs in foreign index"actors": [1]
    }
    

    Will be hydrated as follows in a search response:

    {"id":1,"title":"Forrest Gump","actors": [
        {"id":1,"name":"Tom","familyName":"Hanks","birthDate":"1956-07-09"}
      ]
    }
    

    By @ManyTheFish in #6047

    Disable proxy response buffering on Server-Sent Events (SSE)

    βž• Add X-Accel-Buffering: no on POST /chats/{workspace_uid}/chat/completions when the streaming mode is activated.
    By @YoEight in #6228

    πŸ›  πŸͺ² Bug fixes

    πŸ”© Miscellaneous

    Full Changelog : v1.38.0...v1.39.0

  • v1.38.2 Changes

    March 11, 2026

    πŸ›  Meilisearch v1.38.2 fixes a regression introduced in Meilisearch v1.38.0 where Meilisearch could sometimes stop processing tasks after an automatic task queue cleanup performed while more tasks where being added.

    We recommend that all users in v1.38.0 and v1.38.1 migrate to v1.38.2.

    ⬆️ Note that the dumpless upgrade process can take up to one minute before the HTTP server becomes available when migrating from a previous v1.38 version.

    Full Changelog : v1.38.1...v1.38.2

  • v1.38.1 Changes

    March 11, 2026

    πŸ‘€ Meilisearch v1.38.1 fixes a regression we have seen in task processing, which caused the engine to stop processing tasks.

    πŸ›  πŸͺ² Bug fixes

    • ⚑️ Revert, optimize, and fix task deletion. By @Kerollmops in #6219

    Full Changelog : v1.38.0...v1.38.1

  • v1.38.0 Changes

    March 09, 2026

    πŸ“š Meilisearch v1.38 drastically improves indexing performance for embeddings, cleans up the task queue of orphan tasks and batches, ensures they are correctly deleted now, fixes issues users may encounter with OpenAI or VoyageAI when generating embeddings, and improves the tooling for generating routes in the documentation.

    ✨ Enhancement

    • 🐎 Embeddings: Use the latest version of hannoy with improved performances by @Kerollmops in #6184
      We drastically reduced embedding indexing time by eliminating full database scans. It is more efficient to add a couple of embeddings to a large database now.
    • ⚑️ Tasks: Optimize and fix task deletion by @Mubelotix and @Kerollmops in #5828

    πŸ›  πŸͺ² Bug fixes

    • Embedders: Fix the intermittent connection reset by peer errors when embedding documents or search queries using a remote embedder. By @dureuill in #6191

    πŸ”© Miscellaneous

    • πŸ“š Enforce that routes appear in the reference documentation by @dureuill and @ManyTheFish in #6200
      πŸ“š The reference API is now generated from the source code, but it used to miss some actix-declared routes. It is now mandatory to attach a route when using the newly-provided routes::routes and routes::path macros, which ensures the route is added to the reference. Please refer to the documentation of the individual macros and the many examples throughout the codebase for more details.
    • 🚚 Chore: remove verbose debug log on list documents by @StephaneRob in #6198
    • βž• Add guide to CONTRIBUTING.md to test doc locally by @curquiza in #6180
    • πŸ“„ Docs: capitalize LangChain and MCP in README by @24f1000637 in #6183
    • πŸ“„ Docs: improve documentation of the parameters of the search route by @curquiza in #6194

    πŸ†• New Contributors

  • v1.37.0 Changes

    March 02, 2026

    Important

    πŸ’₯ This release contains breaking changes for users of the network experimental feature.

    🐎 Meilisearch v1.37 introduces replicated sharding, removes the vectorStoreSetting experimental feature, stabilizes our new vector store for best performance, adds a security fix and miscellaneous improvements.

    ✨ Improvements

    Β§ Replicated sharding

    Note

    Replicated sharding requires Meilisearch Enterprise Edition (EE).

    • πŸ‘‰ Users of Meilisearch Cloud, please contact support if you need replicated sharding.
    • πŸ‘‰ Users of the Community Edition, please contact the sales if you want to use replicated sharding in production.

    Β§ Breaking changes

    • network objects sent to the PATCH /network route must now contain at least one shard object containing at least one remote when leader is not null.

    ⬆️ Existing databases will be migrated automatically when upgraded with --experimental-dumpless-upgrade when leader is not null, such that for each remote:

    1. A shard with the same name as the remote is created
    2. This shard has exactly one remote in its remotes list: the remote with the same name as the shard.

    This change will not cause any document to be resharded.

    ⬆️ To be able to upgrade without resharding, the migration uses the same name for remotes and for shards. However, in new configurations, we recommend using different names for shards and remotes.

    Example of migration

    For instance, the following network object:

    {"leader":"ms-00","self":"ms-01","remotes": {"ms-00": {/\* .. \*/},"ms-01": {/\* .. \*/}
      }
    }
    

    is converted to:

    {"leader":"ms-00","self":"ms-01","remotes": {"ms-00": {/\* .. \*/},"ms-01": {/\* .. \*/}
      },"shards": {// ✨ NEW"ms-00": {// shard named like the remote"remotes": ["ms-00"]// is owned by the remote},"ms-01": {"remotes": ["ms-01"]
        }
      }
    }
    

    βž• Addition of network.shards

    The network object for routes PATCH /network and GET /network now contains the new field shards, which is an object whose values are shard objects, and keys the name of each shard.

    Each shard object contains a single field remotes, which is an array of strings, each string representing the name of an existing remote.

    Convenience fields

    🚚 The shard objects in PATCH /network contain the additional fields addRemotes and removeRemotes meant for convenience:

    • pass an array of remote names to shard.addRemotes to add these remotes to the list of remotes of a shard.
    • 🚚 pass an array of remote names to shard.removeRemotes to remove these remotes from the list of remotes of a shard.
    • if present and non-null, shard.remotes will completely override the existing list of remotes for a shard.
    • 🚚 if several of these options are present and non-null, then the order of application is shard.remotes, then shard.addRemotes, then shard.removeShards.

    βž• Adding a new shard with some remotes

    // PATCH /network{// assuming that remotes `ms-0`, `ms-1`, `ms-2` where sent in a previous call to PATCH /network"shards": {"s-a": {// new shard"remotes": ["ms-0","ms-1"]
        }
      }
    }
    

    Remotes ms-0 and ms-1 own the new shard s-a.

    Fully overriding the list of remotes owning a shard

    // PATCH /network{// assuming remotes `ms-0`, `ms-1`, `ms-2`// assuming shard `s-a`, owned by `ms-0` and `ms-1`"shards": {"s-a": {"remotes": ["ms-2"]
        }
      }
    }
    

    ms-2 is now the sole owner of s-a, replacing ms-0 and ms-1.

    βž• Adding a remote without overriding the list of remotes owning a shard

    // PATCH /network{// assuming remotes `ms-0`, `ms-1`, `ms-2`// assuming shard `s-a`, owned by `ms-2`"shards": {"s-a": {"addRemotes": ["ms-0"]
        }
      }
    }
    

    ms-0 and ms-2 are now the owners of s-a.

    Removing a remote without overriding the list of remotes owning a shard

    // PATCH /network{// assuming remotes `ms-0`, `ms-1`, `ms-2`// assuming shard `s-a`, owned by `ms-0` and `ms-2`"shards": {"s-a": {"removeRemotes": ["ms-2"]
        }
      }
    }
    

    ms-0 is now the sole owner of s-a.

    Entirely removing a shard from the list of shards

    Set the shard to null:

    // PATCH /network{"shards": {"s-a":null}
    }
    

    Or set its remotes list to the empty list:

    // PATCH /network{"shards": {"s-a": {"remotes": []
        }
      }
    }
    
    network.shards validity

    When network.leader is not null, each shard object in network.shards must:

    1. Only contain remotes that exist in the list of remotes.
    2. Contain at least one remote.

    βž• Additionally, network.shards must contain at least one shard.

    Failure to meet any of these conditions will cause the PATCH /network route to respond with 400 invalid_network_shards.

    πŸ”„ Change in sharding logic

    Documents are now sharded according to the list of shards declared in the network rather than the list of remotes. All remotes owning a shard will process the documents that belong to this shard, allowing for replication.

    Example of replication

    πŸ”§ The following configuration defines 3 remotes 0, 1 and 2, and 3 shards A, B, C, such that each remote owns two shards, achieving replication (losing one remote does not lose any document).

    {"leader":"0","self":"0","remotes": {"0": {/\* .. \*/},"1": {/\* .. \*/},"2": {/\* .. \*/}
      },"shards": {"A": {"remotes": ["0","1"]
        },"B": {"remotes": ["1","2"]
        },"C": {"remotes": ["2","0"]
        }
      }
    }
    
    • πŸ‘ Full replication is supported by having all remotes own all the shards.
    • πŸ‘ Unbalanced replication is supported by having some remotes own more shards than other remotes.
    • πŸš€ "Watcher" remotes are supported by having remotes that own no shards. Watcher remotes are not very useful in this release, and might be upgraded in a future release, so that they keep all documents without indexing them, allowing to "respawn" shards for other remotes.

    useNetwork takes network.shards into account

    When useNetwork: true is passed to a search query, it is expanded to multiple queries such that each shard declared in network.shards appears exactly once, associated with a remote that owns that shard.

    This ensures that there is no missing or duplicate documents in the results.

    _shard filters

    When the network experimental feature is enabled, then it becomes possible to filter documents depending on the shard they belong to.

    Given s-a and s-b the names of two shards declared in network.shards, then:

    • _shard = "s-a" in a filter parameter to the search or documents fetch will return the documents that belong to s-a.
    • _shard != "s-a" will return the documents that do not belong to s-a
    • _shard IN ["s-a", "s-b"] will return the documents that belong to s-a or to s-b.

    You can use these new filters in manual remote federated search to create a partitioning over all shards in the network.

    Important

    To avoid duplicate or missing documents in results, for manually crafted remote federated search requests, all shards should appear in exactly one query.

    Tip

    πŸ— Search requests built with useNetwork: true already build a correct partitioning over shards. They should be preferred to manually crafted remote federated search requests in replicated sharding scenarios.

    ⚑️ Update instructions

    ⚑️ When updating your Meilisearch network using dumpless upgrade, please observe the following guidelines:

    ⚑️ 1. Do not call the PATCH /network route until all remotes of the network are finished updating ⚑️ 2. If using the search routes with useNetwork: true, call them on un-updated remotes. Calling it on already updated remotes will cause un-updated remotes to fail the search as they don't know about the _shard filters.

    By @dureuill in #6128

    🚚 § Remove vectorStoreSetting experimental feature

    πŸ‘ The new HNSW vector store (hannoy) has been stabilized and is now the only supported vector store in Meilisearch.

    ⚑️ As a result, updating to v1.37.0 will migrate all remaining legacy vector store indexes (using arroy) to hannoy, and the vectorStoreSetting experimental feature is no longer available.

    By @Kerollmops in #6176

    πŸ‘Œ Improve indexing performance for embeddings

    🚚 We removed a computationally expensive step from vector indexing.

    🚚 On a DB with 20M documents, this removes 300s per indexing batch of 1100s.

    By @Kerollmops in #6175

    πŸ”’ Β§ πŸ”’ Security

    • ⬆️ Bump mini-dashboard (local web interface) which
      • now stores API key in RAM instead of in the localStorage
      • bumps dependencies with po...
  • v1.36.0 Changes

    February 23, 2026

    πŸ”– Version v1.36.0 introduces an exciting update to the ranking rules to improve the engine's relevance. It's actually the first time we've made such a change since v1.0, and we're really happy about this improvement!

    ✨ Enhancement

    πŸ›  πŸͺ² Bug fixes

    • πŸ›  Fix search failing when using attributesToSearchOn on an empty index by @zen-zap in #5944

    πŸ”’ πŸ”’ Security

    πŸ”© Miscellaneous

    • πŸ‘Œ Improve OpenAPI docs and CIs to improve documentation experience by @curquiza in #6145

    ⚠ Warning

    πŸ’₯ Breaking change: the meilisearch-openapi-mintlify.json file will not be available in the release assets anymore. If you were using it, please refer to the one that is now available in our public documentation repository.

    • GenAI contributing and PR template changes by @dureuill in #6140
    • πŸ›  Fix "test with almost all features" by @dureuill in #6139 and #6148
    • πŸ‘ Allow any IP for SDK tests by @Strift in #6151
    • πŸ‘Œ Improve output of the declarative tests, also in #6164

    πŸš€ ❀️ Thanks to @zen-zap for contributing to this release!

  • v1.35.1 Changes

    February 16, 2026

    πŸ›  πŸ¦‹ Bug fixes

    πŸ›  Meilisearch v1.35.1 fixes a possible task database corruption issue that would occur when using the S3 streaming snapshot method.

    • ⬆️ Users of the Community Edition do not need to upgrade as this feature is Enterprise Edition only
    • Affected users of the Cloud have been contacted.

    Details

    πŸ›  While snapshotting the task database, sending a task to Meilisearch could corrupt it. Index DBs were not affected, so manually rebuilding the task database fixes the corruption.

    By @dureuill in #6160

    Full Changelog : v1.35.0...v1.35.1

  • v1.35.0 Changes

    February 02, 2026

    πŸ›  Meilisearch v1.35.0 contains improvements to the observability of the search performance, a breaking change to the recently introduced POST /indexes/<index_uid>/fields route, and other bugfixes and improvements.

    🌈 Improvements

    🐎 Observe the search performance

    🐎 The search routes accept a new field named showPerformanceDetails. When set to ù true`, the search response contains a performance trace, allowing the user to better
    understand what takes time during a search query.

    impacted routes:

    • POST /indexes/<index_uid>/search
    • GET /indexes/<index_uid>/search
    • POST /multi-search
    • POST /indexes/<index_uid>/similar
    • GET /indexes/<index_uid>/similar

    Search

    routes: POST /indexes/<index_uid>/search and GET /indexes/<index_uid>/search

    Request

    πŸ†• new request parameters:

    • 🐎 showPerformanceDetails: true/false (boolean)

    example

    {"q":"glass","showPerformanceDetails":true}
    
    Response

    πŸ†• new response field:

    • 🐎 performanceDetails: {"<span>": "<human_duration>", .. } (map)

    example

    {"hits": [// hits ..],"query":"glass","processingTimeMs":5,"limit":20,"offset":0,"estimatedTotalHits":1,"requestUid":"\<uuid\>","performanceDetails": {"wait for permit":"295.29Β΅s","search \> tokenize":"436.67Β΅s","search \> resolve universe":"649.00Β΅s","search \> keyword search":"515.71Β΅s","search \> format":"288.54Β΅s","search":"3.56ms"}
    }
    

    Multi-search

    route: POST /multi-search

    Request

    πŸ†• new request parameters:

    • 🐎 queries.showPerformanceDetails: true/false (boolean)

    example

    "queries": [
        {"indexUid":"\<index\_uid\>","q":"glass","showPerformanceDetails":true}
    ]
    
    Response

    πŸ†• new response field:

    • 🐎 results.performanceDetails: {"<span>": "<human_duration>", .. } (map)

    example

    {"results": [
            {"indexUid":"\<index\_uid\>","hits": [// hits ..],"query":"glass","processingTimeMs":5,"limit":20,"offset":0,"estimatedTotalHits":1,"requestUid":"\<uuid\>","performanceDetails": {"wait for permit":"295.29Β΅s","search \> tokenize":"436.67Β΅s","search \> resolve universe":"649.00Β΅s","search \> keyword search":"515.71Β΅s","search \> format":"288.54Β΅s","search":"3.56ms"}
            }
        ]
    }
    

    Federated Search

    route: POST /multi-search

    Request

    πŸ†• new request parameters:

    • 🐎 federation.showPerformanceDetails: true/false (boolean)

    example

    {"federation": {"showPerformanceDetails":true},"queries": [
            {"indexUid":"\<index\_uid\>","q":"glass"}
        ]
    }
    
    Response

    πŸ†• new response field:

    • 🐎 performanceDetails: {"<span>": "<human_duration>", .. } (map)

    example

    {"hits": [// hits ..],"query":"glass","processingTimeMs":5,"limit":20,"offset":0,"estimatedTotalHits":1,"requestUid":"\<uuid\>","performanceDetails": {"wait for permit":"213.83Β΅s","search \> tokenize":"171.67Β΅s","search \> resolve universe":"257.63Β΅s","search \> keyword search":"577.71Β΅s","search \> format":"114.96Β΅s","search \> federation \> wait for remote results":"62.71Β΅s","search \> federation \> merge results":"120.04Β΅s","search \> federation \> merge facets":"53.42Β΅s","search \> federation":"237.04Β΅s","search":"289.08ms"}
    }
    

    Similar

    routes: POST /indexes/<index_uid>/similar and GET /indexes/<index_uid>/similar

    Request

    πŸ†• new request parameters:

    • 🐎 showPerformanceDetails: true/false (boolean)

    example

    {"id":143,"embedder":"manual","showPerformanceDetails":true}
    
    Response

    πŸ†• new response field:

    • 🐎 performanceDetails: {"<span>": "<human_duration>", .. } (map)

    example

    {"hits": [// hits ..],"id":"143","processingTimeMs":"[duration]","limit":20,"offset":0,"estimatedTotalHits":4,"performanceDetails": {"search \> format":"244.92Β΅s","search":"1.25ms"}
    }
    

    By @ManyTheFish in #6132

    πŸ›  Stabilize multithreaded post-processing of facets and prefixes

    πŸ›  Multithreaded post-processing of facets and prefixes speeds-up indexing on multi-core machines.

    Before v1.35.0, it could be disabled with an experimental feature.

    🚚 Meilisearch v1.35.0 removes that experimental feature, resulting in the multithreaded post-processing being always enabled.

    ⬆️ Cloud users upgrading to v1.35.0 will benefit from the speed-up.

    By @ManyTheFish in #6130

    πŸ›  πŸ¦‹ Fixes

    πŸ’₯ Breaking change: return pagination fields in POST /indexes/<index_uid>/fields route

    ⚠ Warning

    πŸ’₯ Breaking change : The POST /indexes/<index_uid>/fields route now returns an object containing the results, offset, limit, and total fields instead of returning an array of results. This change allows to know how many fields match a given filter

    Example: before/after

    Before:

    [// fields ..]
    

    After:

    {"results": [// [fields ..]],"offset":0,"limit":20,"total":0}
    

    By @ManyTheFish in #6126

    POST /indexes/<index_uid>/fields: Fix pattern filtering when a parent field was matching a child pattern: title was matching the pattern title.to*.

    Example: before/after

    For the following request:

    {"filter": {"attributePatterns": ["title.en"]
      }
    }
    

    Before Response, title field is returned:

    {"results": [
        {"name":"title",//metadata...},
    
      ],"offset":0,"limit":20,"total":1}
    

    After Response, nothing returned:

    {"results": [],"offset":0,"limit":20,"total":0}
    

    By @ManyTheFish, also in #6126

    πŸ›  πŸ› Other fixes

    • ⬆️ Bump mini-dashboard version to fix display of image in local UI interface by @Strift in #6129
    • πŸ›  Fix mTLS compatibility with Go by @curquiza in #6133

    πŸ”© Miscellaneous

    • βž• Add AI usage disclosure guidelines to CONTRIBUTING.md by @meili-bot in #6114
    • πŸ”¦ Expose SettingsDelta and related types for external crate usage by @MkDev11 in #6119

    πŸ†• New Contributors

    Full Changelog : v1.34.3...v1.35.0

  • v1.34.3 Changes

    January 28, 2026

    πŸ›  πŸ› Bug Fixes

    • Increase the auth store database size to 2 GiB so that we can index more keys by @Kerollmops in #6134

    Full Changelog : v1.34.2...v1.34.3

  • v1.34.2 Changes

    January 28, 2026

    πŸ‘ This patch fixes an accidental breaking change in v1.34.1 where Meilisearch would not start with a configuration file if experimental_allowed_ip_networks was not defined.

    • ⚑️ Meilisearch Cloud users do not need to update as they were not affected by this regression
    • ⬆️ We recommend that OSS users upgrade to v1.34.2

    Full Changelog : v1.34.1...v1.34.2