_This is part 3 of a series of blog posts_ [_originally published on my personal blog_](https://blog.kerollmops.com/meilisearch-expands-search-power-with-arroy-s-filtered-disk-ann)_._ _Begin the journey with_ [_part 1_](/blog/spotify-inspired-hybrid-search-and-rust/) _and_ [_part 2_](/blog/refining-ann-performance-with-rust/)_._

We can store vectors in [Arroy](https://github.com/meilisearch/arroy) and efficiently compute the search tree nodes, but we still need some features to make it usable in Meilisearch. Our full-text search engine has great support for filtering; selecting subsets of documents is an essential feature to support. For instance, one of our biggest clients requires the ability to filter through over 100 million YouTube video metadata and their associated image embeddings to effectively select videos released within specific time frames, such as a single day or week. This represents the scalability and responsiveness challenges we aim to address with our filtering system, making it a perfect use case to tailor our developments.

Meilisearch supports the following operators on the filterable attributes of your documents: `<`, `<=`, `=`, `!=` `>=`, and `>`. Internally, we extensively [use `RoaringBitmap`s](https://github.com/RoaringBitmap/roaring-rs), which are well-optimized sets of integers that support fast binary operations like unions and intersections. When the engine receives a user request with filters, it first computes the subset of documents from the filter that will be inputted into the search algorithms, the one that ranks documents by quality. This subset is represented by a `RoaringBitmap`.

How was it working before Arroy?
--------------------------------

Ranking only the subset of filtered documents has been working well since 2018, but now that we have a new data structure to search on, we need to look at how to implement it. The engine had already supported the vector store feature for months but was inefficient. We were using an in-memory HNSW and were deserializing the whole data structure in memory, searching for the nearest neighbors of the target vector, which was returning an iterator.

```Rust
fn vector_store(db: Database, subset: &RoaringBitmap, target_vec: &[f32]) -> Vec<DocumentID> {
    // This takes a lot of time and memory.
    let hnsw = db.deserialize_hnsw();

    let mut output = Vec::new();
    for (vec_id, vec, dist) in hnsw.nearest_neighbors(target_vec) {
        let doc_id = db.document_associated_to_vec(vec_id).unwrap();
        if !output.contains(&doc_id) {
          output.push(doc_id);
          if output.len() == 20 { break }
        }
    }

    output
}
```

You may wonder why we are retrieving the document ID associated with the vector ID. Meilisearch supports multiple vectors by document since the beginning of the vector store feature. This is unfortunate because we must look up every vector we are iterating. We need to maintain this lookup table. The iterator can iterate on the whole vector dataset if the subset is small enough, e.g., `document.user_id = 32`. We want the document operations to be atomic and consistent, so we have to store the HNSW on disk and avoid having to maintain synchronization between the LMDB transactions and this vector store data structure. Ho! And the library doesn't support incremental insertion. We must reconstruct the HNSW in memory from scratch every time we insert a single vector.

Integrating Arroy in Meilisearch
--------------------------------

As we worked on updating Meilisearch to include the new vector store, arroy, we tried out mob programming for the first time. This is where we all code together at the same time. It might sound like it would slow us down, but it actually made us super productive! By tackling problems together right as they came up, we got arroy fitted into Meilisearch much faster than if we'd worked alone.

Arroy is different because it doesn’t return an iterator to give back search results. Now, our search engine is smarter and can figure out the exact number of results it needs to give back, even when there are filters to consider. This teamwork improved our search tool and showed us that working together is key when facing big tech challenges.

#### Filtering while searching in Arroy

You can find a description of the arroy internal data structure in [part 1 of this series](https://blog.kerollmops.com/spotify-inspired-elevating-meilisearch-with-hybrid-search-and-rust). Here is a list of the different kinds of nodes you can find:

*   The item nodes. The original vectors that the user provides. The small points on the left.
*   The normal nodes, also called split planes. They represent hyperplanes that split subsets of item nodes in half.
*   The descendant nodes. They are the tree leaves composed of the item IDs you'll find if you follow a certain normal node path.

![split-plane-combined-schema](https://unable-actionable-car.media.strapiapp.com/spli_plane_b53ab895e8.png)

A typical search will load all the normal nodes in a binary heap associated with an infinite distance. Remember that there are a lot of randomly generated trees, and there are, therefore, a lot of entry points. Ascending distances order the binary heap; the shortest nodes found will be popped first.

In the search algorithm, we pop the nearest item from this heap. If it's a normal node, we fetch the left and right sides of the hyperplane:

*   If we find normal nodes again, we associate the distance from the hyperplane with positive and negative distances from the targeted/queried vector.
*   If we find descendant nodes, we do not push them into the queue but rather directly add them to the potential output list as they represent the nearest vectors we have found.

You probably noticed where I want to go, but this is where magic happens. We modified arroy to store the list of descendants in `RoaringBitmap`s instead of a raw list of integers. This is another improvement compared to the original Spotify library, as those lists weigh less. Doing an intersection with the filtered subset is way easier now.

However, there is always an issue: the vector IDs are not the document IDs, and Meilisearch, after executing the filters, only knows about the documents. Iterating on the lookup table, I talked about before, constructing the final bitmap with all the vector IDs corresponding to the filtered documents would not be efficient when many documents are part of this subset, e.g., `document.user_id != 32`. I do not recommend using an `O(n)` algorithm in the search functions.

#### Using multiple indexes for efficient filtering

Fortunately, we developed a fun feature that wasn't meant to be used that way in arroy: the support for multiple indexes in a single LMDB database. We originally developed the multiple indexes feature to be able only to open a single LMDB database to store different vector types. Yes! In Meilisearch v1.6, you can describe the different embedders that live in a single index. You can identify the different vectors with different numbers of dimensions and distance functions you can store in a single document. Defining multiple vectors for a single document associated with the same embedder is also possible.

The indexes are identified by an `u16`. This feature can trick the algorithm into being even more efficient than the previous HNSW solution. Using one store by embedder and vector in a document is interesting because we can now identify the vectors using the document ID. No more lookup database and vector IDs. The vector IDs are reduced to the document IDs. We can use the output of the filters to filter the arroy indexes.

The search algorithm is different on the Meilisearch side. We request the nearest neighbors in every arroy index, sort the results by document ID to be able to deduplicate them and not return the same document multiple times, sort them again by distance, and then return only the top twenty documents. It may seem complex, but we are talking about twenty documents by the number of vectors for a single document. Usually, users will have a single vector.

```Rust
fn vector_search(
    rtxn: &RoTxn,
    database: Database,
    embedder_index: u8,
    limit: usize,
    candidates: &RoaringBitmap,
    target_vector: &[f32],
) -> Vec<(DocumentId, f32)> {
    // The index represents the embedder index shifted and
    // is later combined with the arroy index. There is an arroy
    // index by vector for a single embedded in a document.
    let index = (embedder_index as u16) << 8;
    let readers: Vec<_> = (0..=u8::MAX)
        .map(|k| index | (k as u16))
        .map_while(|index| arroy::Reader::open(rtxn, index, database).unwrap())
        .collect();

    let mut results = Vec::new();
    for reader in &readers {
        let nns = reader.nns_by_vector(rtxn, target_vector, limit, None, Some(candidates)).unwrap();
        results.extend(nns_by_vector);
    }

    // Documents can have multiple vectors. We store the different vectors
    // into different arroy indexes, we must make sure we don't find the nearest neighbors
    // vectors that correspond to the same document.
    results.sort_unstable_by_key(|(doc_id, _)| doc_id);
    results.dedup_by_key(|(doc_id, _)| doc_id);

    // Sort back the documents by distance
    results.sort_unstable_by_key(|(_, distance)| distance);
    results
}
```

The design philosophy behind these improvements
-----------------------------------------------

We're trying to make Meilisearch flexible enough for everyone's needs. Whether your documents are powered by a single embedding, like the kind OpenAI's nifty tools generate, or mixing it up with text and image embeddings, as many e-commerce sites do, we want your search experience to be seamless. We haven't forgotten you for the power users working with multiple embeddings from multi-modal embedders. Our latest improvements ensure that everyone gets to update and fine-tune their search indexes incrementally, making the whole process as smooth as butter.

Big thanks to everyone: Wrapping this up, a huge shout-out to the squad – [@dureuill](https://github.com/dureuill), [@irevoire](https://github.com/irevoire), and [@ManyTheFish](https://github.com/ManyTheFish) – for their genius and grunt work that brought our ideas to life. And watch out for [@irevoire](https://github.com/irevoire)'s upcoming article, where he'll explain how we've implemented incremental indexing in Arroy—meaning you can add new vectors without rebuilding everything from scratch. More on that soon!

You can comment about this article on [Lobste.rs](https://lobste.rs/s/hdokyh/meilisearch_expands_search_power_with), [Hacker News](https://news.ycombinator.com/), [the Rust Subreddit](https://www.reddit.com/r/rust/comments/18pqxdz/meilisearch_expands_search_power_with_arroys), or [X (formerly Twitter)](https://x.com/kerollmops/status/1738837058628551148?s=46&t=0s6OFYJM-Oyl_WD-1jijQA).

* * *

[Meilisearch](https://meilisearch.com/?ref=blog.meilisearch.com) is an open-source search engine that not only provides state-of-the-art experiences for end users but also a simple and intuitive developer experience.

For more things Meilisearch, you can join the community on [Discord](https://discord.gg/meilisearch/?ref=blog.meilisearch.com) or subscribe to the [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&ref=blog.meilisearch.com). You can learn more about the product by checking out the [roadmap](https://roadmap.meilisearch.com/?ref=blog.meilisearch.com) and participating in [product discussions](https://github.com/orgs/meilisearch/discussions?ref=blog.meilisearch.com).

Meilisearch expands search power with Arroy's Filtered Disk ANN

_This is part 2 of a series of blog posts_ [_originally published on my personal blog_](https://blog.kerollmops.com/multithreading-and-memory-mapping-refining-ann-performance-with-arroy)_. Begin the journey with_ [_part 1_](/blog/spotify-inspired-hybrid-search-and-rust/)_._

Wouldn't it be great to show you how a single-threaded, memory-mapped key-value store can be more efficient than a hand-written memory-mapped solution? I faced issues while porting the Spotify disk-based Approximate Nearest Neighbors library to Rust and, more specifically, to LMDB. Those issues were primarily due to LMDB and memory safety. Here is the story.

To remind you, [Arroy](https://github.com/meilisearch/arroy) is a library that stores embeddings (vectors of floats) on disk. Some data structures are generated on top of those vectors, which look like trees governed by normals used to recursively split the vectors dataset into subdomains. But you can read more about this in [part 1](/blog/spotify-inspired-hybrid-search-and-rust/ of this series.

### How does Annoy generate the tree nodes?

Annoy, the Spotify library stores the nodes on disk, the item nodes (the ones containing the embeddings), and the other nodes that we will call tree nodes in this article. The advantage of doing this is double:

*   The program's memory usage is low and optimized by the OS as all the nodes live in a memory-mapped file.
*   The concept is simple: Access a node by using its ID. The library will find its offset on disk by using a simple multiplication.

However, there are downsides to doing that. All nodes: items with embeddings along with the tree nodes must have the same size, and If a user wants to identify its embedding using the ID 231, the library will increase the file size to the ID multiplied by the node size. For example, with a vector of 768 dimensions, storing a single item with the ID 231 will generate a file of more than 6.5 TiB.

In generating the final data structure, the tree nodes are all written to disk in the same file as the user item containing the embeddings. Those tree-building processes run in parallel, one running process by tree, and, therefore, requires a lot of synchronization when defining the newly created node ID and the memory area reserved for it, most importantly, when the memory-mapped file is too small to accept more nodes, only a single thread must grow the file, so a mutex is used on top of the mutable memory-map and around a `node_id` variable. One interesting property of tree generation is that the generation process only requires the original user item with embeddings.

### The challenges we encountered when porting it to LMDB

A fun fact is that it is the first time in a long time that I have written C++, and the first time I asked ChatGPT to code for me because I was not confident in doing C++ and feared falling into some segfault. I needed a small program to deserialize embeddings from stdin and give them to Annoy. The chatbot's code was mostly effective, but it omitted a critical [empty vector check](https://gist.github.com/Kerollmops/d0e434016b1a698ec9bdbd86d268885e#file-par_build_tree-cpp-L74), which led to a segmentation fault...

The main obstacle to porting it to LMDB is that writing into this key-value store is single-threaded. It doesn't support concurrent write operations to maintain a correctly balanced BTree. Fun incoming!

#### Reading the user item nodes from different threads

We have used LMDB at Meilisearch since the beginning. It is a well-maintained key-value store used in Firefox and maintained by the OpenLDAP developers. It is memory-mapped and does not maintain a user-end cache of the entries in memory but instead gives you a pointer to the memory-mapped area on disk. The main advantage is that you can keep a pointer to this area for as long as your read transaction lives. Ho yeah! Because it is a transactional key-value store that supports atomic committing, too!

But tree generation doesn't require referring to the generated nodes but only the user items. We previously saw that LMDB gives direct pointers into the memory-mapped file without maintaining any intermediate cache (that could be invalidated). There is another quirk with LMDB: you cannot share a read-only transaction between multiple threads, i.e., `RoTxn: !Sync` and you cannot move the write transaction between threads, i.e., `RwTxn: !Send + !Sync`. Ho! And there is no way to create a read-transaction on uncommitted changes. This is an issue because we want to generate the data-structures trees in the same transaction where we store the items.

But magic is everywhere, starting with the following small and fun data structure. The principle is to keep the pointers to the internal user items with embeddings in a `Vec<*const u8>`. Thanks to Rust, we can ensure, at compile time, that the pointers will live long enough by keeping the lifetime in the struct. Using the `&'t RwTxn` to get the `&'t RoTxn` by using `Deref` also ensures that we cannot modify the database while reading in it by using a `&'t mut RwTxn`. [According to the leading developer of LMDB](https://bugs.openldap.org/show_bug.cgi?id=10138#c9), it is safe to share those pointers between threads and why I implemented `Sync` for this structure.

```Rust
pub struct ImmutableItems<'t, D> {
    item_ids: RoaringBitmap,
    constant_length: Option<usize>,
    offsets: Vec<*const u8>,
    _marker: marker::PhantomData<(&'t (), D)>,
}

impl<'t, D: Distance> ImmutableItems<'t, D> {
    pub fn new(rtxn: &'t RoTxn, database: Database<D>, index: u16) -> heed::Result<Self> {
        let mut item_ids = RoaringBitmap::new();
        let mut constant_length = None;
        let mut offsets = Vec::new();

        for result in database.items()? {
            let (item_id, bytes) = result?;
            assert_eq!(*constant_length.get_or_insert(bytes.len()), bytes.len());
            item_ids.push(item_id);
            offsets.push(bytes.as_ptr());
        }

        Ok(ImmutableLeafs { item_ids, constant_length, offsets, _marker: marker::PhantomData })
    }

    pub fn get(&self, item_id: ItemId) -> heed::Result<Option<Leaf<'t, D>>> {
        let len = match self.constant_length {
            Some(len) => len,
            None => return Ok(None),
        };
        let ptr = match self.item_ids.rank(item_id).checked_sub(1).and_then(|offset| self.offsets.get(offset)) {
            Some(ptr) => *ptr,
            None => return Ok(None),
        };
        let bytes = unsafe { slice::from_raw_parts(ptr, len) };
        ItemCodec::bytes_decode(bytes).map(Some)
    }
}

unsafe impl<D> Sync for ImmutableItems<'_, D> {}
```

You have also probably noticed some other fun optimizations in this simplified version of the data structure. We also know that the user-item nodes have a constant length, so I decided to store it only once, reducing the offsets vector's size by two. Considering that our objective is to store 100M vectors and that this vector is in memory, we shrunk its size from 1526 MiB to 763MiB, which is not much, but better than nothing.

#### Writing the tree nodes in parallel

Ok! Now that we know how to store pointers to items and share them between threads without any user-end synchronization, we need to generate the tree nodes using it. We already know how to deal with LMDB at Meilisearch and decided to implement the same workaround. To write in parallel into LMDB, write into different, independent files and merge everything afterward. This leverages the [Share-Nothing principle](https://en.wikipedia.org/wiki/Shared-nothing_architecture) and isolates the algorithms. This drastically reduces the number of synchronization points [compared to the original C++ code](https://github.com/spotify/annoy/blob/2be37c9e015544be2cf60c431f0cccc076151a2d/src/annoylib.h#L1344-L1445) (look at the `.lock/unlock` calls) to a single line in our code: the atomically increasing global tree node ID.

```Rust
pub fn next_node_id(&self) -> u64 {
    self.0.fetch_add(1, Ordering::Relaxed)
}
```

Our functions that generate normal split nodes based on the user-item nodes are now simply writing the nodes into independent files. The [nodes are appended into a file](https://github.com/meilisearch/arroy/blob/4f193fd534acd357b65bfe9eec4b3fed8ece2007/src/parallel.rs#L20-L71), and the on-disk offsets and bounds are stored into a vector, a single `usize` by node. Using Rayon, we run all tree-generation functions in parallel and, once completed, retrieve the files and boundaries to write the uniquely identified nodes into LMDB sequentially.

### Performances comparison

Our objective at Meilisearch is to support 100M embedding of around 768 dimensions. If we store those as `f32` vectors without any [dimensionality reduction](https://en.wikipedia.org/wiki/Dimensionality_reduction), it would be equivalent to `100M * 768 * 4 = 307B`, in other words, 286 GiB to store the vectors raw, without any internal tree nodes, i.e., no way to search in them efficiently.

If you don't specify the number of trees to generate, the algorithm will continue to create trees while the number of tree nodes is smaller than the number of item vectors. At the end, there must be roughly the same number of tree nodes and items.

#### Discovering the limit of vectors we can index

Arroy and Annoy use memory mapping extensively but in slightly different ways. In a previous article from [@dureuill](https://github.com/dureuill), we saw that [operating systems do not have infinite memory-map space](/blog/dynamic-virtual-address-management/ So, let's dive into performance results.

I noticed something strange when running Arroy with 25M vectors of 768 dimensions. The CPUs were not used, and the program seemed to read the SSD/NVMe a lot, too much 🤔 The tree generation algorithm is splitting the vector space into subdomains with fewer vectors. Still, it must first find the appropriate normal to split the entire domain, and for that, it randomly selects many items. Unfortunately, my machine only has 63 GiB of memory, and indexing those 25M items requires more than 72 Gib. Annoy was also struggling in the same way.

![We cannot index 25M vectors of 768 dimensions with 63 GiB](https://unable-actionable-car.media.strapiapp.com/annoy_arroy_e83f58691c.png)

After investigating, I understood why the whole swap space and memory mapping limits were reached. Not only the item nodes were not only _768 \* 4 bytes_ because we store the norm and other stuff alongside the vectors, but in the case of Arroy, LMDB needs to maintain BTree data structures around the entries, and those are also tacking memory-mapped space. Both programs request random item nodes unavailable in memory, so the OS fetches them from the disk, which takes time. Ho and every single thread is doing that in parallel. CPUs are simply awaiting the disk.

So, after some dichotomy, I found the point where arroy successfully used all of the memory without being bound to the disk speed. It can index 15.625M on a 63 GiB machine. You can see on this htop screenshot that the disk read speed is at zero as all of the vectors fit in RAM, that arroy is writing the tree nodes to disk, and that the CPUs are doing their best. It took less than seven hours to process.

![Successfully indexing 15.6M vector of 768 dimensions with 63 GiB](https://unable-actionable-car.media.strapiapp.com/annoy_arroy2_a873d31d2d.png)

But... Annoy cannot index this same number of documents. It suffers from the same issue we saw before: high disk read and low CPU usage. But why? I needed clarification because the nodes have the same format, the number of item vectors to index is the same, and the algorithm has been ported. So, what is the difference between both solutions?

For those who looked into the C++ codebase and were probably hinted by the memory mapping issue described earlier, you probably noticed this slight difference: Arroy is writing the generated tree nodes into different raw files when Annoy, on the contrary, is [reserving space into the memory-mapped file and directly writing into it](https://github.com/spotify/annoy/blob/2be37c9e015544be2cf60c431f0cccc076151a2d/src/annoylib.h#L1354-L1370). By doing this trick, the OS needs to keep much more space in the memory-mapped area and is forced to invalidate the item nodes from the cache to keep the just-written tree nodes hot in the cache, slowing down the system for no reason, as the tree nodes are not necessary for the algorithm.

So, after even more dichotomy to find the Annoy limits on a 63 GiB machine, I discovered that it could roughly index 10M vectors in five hours.

#### The share nothing principle to the win

So Arroy can index 36% more vectors on the same machine, but how long does it take? Wouldn't it be faster to write into the same file in parallel instead of copying all those tree nodes in a single-threaded way? It will be a much shorter paragraph as I only did some small tests, but Arroy is always faster!

|  | number of vectors | number of threads | building time |
| --- | --- | --- | --- |
| Annoy | 96k | 1 | 5min 38s |
| arroy | 96k | 1 | **3min 45s** |
| Annoy | 96k | 12 | 1min 9s |
| arroy | 96k | 12 | **54s** |
| Annoy | 10M | 12 | 5h 40min |
| arroy | 10M | 12 | **4h 17min** |
| Annoy | 15.625M | 12 | \-- |
| arroy | 15.625M | 12 | **7h 22min** |

Now, you probably tell me that I will need around 400GiB of memory to index 100M vectors, and you are probably right, but [@irevoire](https://github.com/irevoire) will talk about incremental indexing in a future article. I did a linear regression for fun. With those 12 threads and the required memory, I predicted it would take one day, 22 hours, and 43 min 😬. Ho! As we also use this vector store in Meilisearch, we need to provide ways to filter this data structure at search time. This is the next article in this series.

You can comment about this article on [Lobste.rs](https://lobste.rs/s/87aheu/multithreading_memory_mapping_refining), [Hacker News](https://news.ycombinator.com/), [the Rust Subreddit](https://old.reddit.com/r/rust/comments/18jmuoe/multithreading_and_memorymapping_refining_ann), or [X (formerly Twitter)](https://x.com/Kerollmops/status/1735941213516140814).

[Part 3](/blog/arroy-filtered-disk-ann/) of this series is now available, exploring further advancements in our search with Arroy's Filtered Disk ANN.

* * *

[Meilisearch](https://meilisearch.com/?ref=blog.meilisearch.com) is an open-source search engine that not only provides state-of-the-art experiences for end users but also a simple and intuitive developer experience.

For more things Meilisearch, you can join the community on [Discord](https://discord.gg/meilisearch/?ref=blog.meilisearch.com) or subscribe to the [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&ref=blog.meilisearch.com). You can learn more about the product by checking out the [roadmap](https://roadmap.meilisearch.com/?ref=blog.meilisearch.com) and participating in [product discussions](https://github.com/orgs/meilisearch/discussions).

Multithreading and Memory-Mapping: Refining ANN performance with Arroy

_This is part 1 of a series of blog posts_ [_originally published on my personal blog_](https://blog.kerollmops.com/spotify-inspired-elevating-meilisearch-with-hybrid-search-and-rust)_._

Uniting keyword and semantic search
-----------------------------------

At Meilisearch [we are working hard on hybrid search](https://github.com/meilisearch/meilisearch/issues/3838), mixing the widespread keyword search algorithm with the not-so-common semantic search. The former is very good at exact matching, while the latter finds stuff you can _describe_ better.

I will explain why we even talk about [Meilisearch/arroy](https://github.com/meilisearch/arroy) and why it is important to us. The semantic search was something new to us. The principle is quite simple: documents are associated with vectors (lists of floats), and the closer they are to each other, the closer they are semantically. When a user queries the engine, you compute the embeddings (vectors) of the query and do an approximate nearest neighbor search to get the nth closest items to the user query. Fun fact: after all this time, Annoy [is still among the top competitors](https://ann-benchmarks.com/gist-960-euclidean_10_euclidean.html), so imagine when we will finally release Arroy.

Seems simple, right? Do you **really** think this series of blog posts will talk about a dead simple subject? Join us on a journey as [@irevoire](https://github.com/irevoire) and I ([@Kerollmops](https://github.com/Kerollmops)), with the assistance of [@dureuill](https://github.com/dureuill), work on porting this cutting-edge library to Rust.

Optimizing storage and search for high-dimension embeddings
-----------------------------------------------------------

The embeddings are something between 768 and 1536 dimensions. We have customers at Meilisearch who want to store over 100M of them. Embeddings that were not modified by any dimension reduction algorithm use 32-bit floats. This means storing this data will take between 286 GiB and 572 GiB, depending on the dimensions.

[Yes, it fits in RAM](https://yourdatafitsinram.net/), but at what cost? Storing on disk is much cheaper. Ho! And it is only the raw vectors. I assure you that doing an approximate neighbors search among all vectors in `O(n)` will be quite slow. So we decided to store them on disk. We have looked at many different solutions before choosing Spotify/Annoy. Initially, we used the HNSW from instant-distance Rust crate, another data structure, to do an ANNs (approximate nearest neighbors) search. However, it is not disk-based; everything lives in memory, which is unpractical.

Spotify's hyperplan trees for efficient ANNs
--------------------------------------------

Spotify worked on a cool C++ library to search in enormous vector sets. The algorithm generates multiple trees that refer to the vectors. The tree nodes are random hyperplanes that split subsets of vectors in half. The root node splits the whole set of vectors in half, and the left and right branches split the subsets of vectors recursively again until the subset is small enough. When we perform an ANNs search, we go through all the root trees and decide whether to go on the hyperplanes' left or right, depending on the haystack provided. The advantage is that every node and vector is directly stored in a memory-mapped file.

![Hyperplanes mapped to binary trees](https://unable-actionable-car.media.strapiapp.com/blog_arroy_1_76462ae24c.png)

The way Annoy and Arroy generate hyperplanes to split the vector space

At the end of the tree, we can see the descendants' nodes. Those define the final list of leaf vectors that fit on this side of the recursive split nodes above. It is a list of unsigned integers the user provides. Annoy represents them as slices of `u32`s, but we decided to go [with RoaringBitmaps](https://roaringbitmap.org/about/) to reduce their size. Annoy cannot compress them because they have a fun constraint: All nodes, user leaf vectors, split nodes, and descendants must be the same size to be accessible using offsets on disk.

The above image shows the way a split plane can be represented. A hyperplane splits a subset of nodes here in two dimensions, but imagine that with 768 to 1536 dimensions. Each hyperplane creates two subsets of points recursively split by another hyperplane. Once the number of points to split is small enough, we create a descendants node containing the item IDs corresponding to these points. Furthermore, the embeddings of the points are never duplicated in memory; we refer to them by their IDs.

Adapting Annoy to LMDB
----------------------

So, if it works so well, why must we port it to Rust? One, because I follow the _Rewrite it in Rust_ dogma 😛, two because this is a C++ library with a lot of horrifying hacks and undefined behaviors, and three because Meilisearch is based on LMDB, an atomic, transaction-based, memory-mapped key-value store. Moreover, [since 2015, they have wanted to use LMDB](https://github.com/spotify/annoy/issues/96), but they have yet to achieve it; it requires a lot of time to change the data structures accordingly.

LMDB uses a BTree to order the entries, and it takes more space for the intermediate data structures than annoy, which directly identifies vectors using the offset in the file. Another advantage of using this key-value store is managing incremental updates. It is easier to insert and remove vectors. Suppose you insert a vector identified by a high 32-bit integer in Annoy. In that case, it will allocate a lot of memory to store it as the dedicated offset, increasing the file size if necessary.

In Meilisearch and Arroy, [we use heed, a typed LMDB Rust wrapper](https://github.com/meilisearch/heed), to avoid undefined behavior, bugs, and stuff related to C/C++ libraries. We, therefore, use `&mut` and `&` extensively to be sure that we are not modifying the key-value store entries while keeping references inside it, and we make sure that the read-write transactions can't be referenced or sent between threads. But that will be for another story.

We first thought using this key-value store would make Arroy slower than Annoy. However, LMDB writes its pages in memory before writing them to disk, which seems much faster than directly writing into mutable memory-mapped areas. On the other hand, LMDB doesn't guarantee the memory alignment of the values that Annoy's file format permits; we'll talk about that later.

Optimizing vector handling with SIMD
------------------------------------

The most CPU-intensive task that Arroy was supposed to do was to try to split clouds of vectors in half. This requires computing a massive number of distances in hot loops. But we read the embeddings from a memory-mapped disk. What could go wrong?

```rust
fn align_floats(unaligned_bytes: &[u8]) -> Vec<f32> {
    let count = unaligned_bytes.len() / mem::size_of::<f32>();
    let mut floats = vec![f32::NAN; count];
    cast_slice_mut(&mut floats).copy_from_slice(unaligned_bytes);
    floats
}
```

We used Instrument on macOS to profile our program and discovered a lot of time was spent moving stuff around, i.e., `_platform_memmove`. The reason is that reading unaligned floats from disk is undefined behavior, so we were copying our floats into an aligned memory area as shown above. Cost: An allocation by reading plus a calling `memmove`.

![Profiling showing a big memmove usage](https://unable-actionable-car.media.strapiapp.com/blog_arroy_2_c34c821b3c.png)

Profiling shows a lot of memory copies to align bytes

While porting the distance function from C++ to Rust, we used the Qdrant SIMD-optimized distance functions without modifying them beforehand. Although, [being aware of the performance cost of reading unaligned memory](https://dwrensha.github.io/capnproto-rust/2020/01/11/unaligned-memory-access), we decided to execute the distance functions on unaligned floats, making sure not to represent it as a `&[f32]` as it would be undefined behavior. The functions take raw slices of bytes and deal with them using pointers and SIMD functions. We unlocked performances. The distances functions were slower, but it compensated the `memmove`s and allocations!

![Profiling showing no memmove usage](https://unable-actionable-car.media.strapiapp.com/blog_arroy_3_519276495b.png)

Directly dealing with unaligned memory removed the copies

Similarly to the `memmove` calls, we can see that the `_platform_memcmp` function is taking a lot of space here. The reason is that LMDB uses this standard function to compare key bytes and decide whether a key is lexicographically located above or below another key in the tree. It is used whenever we read or write in LMDB. [@irevoire](https://github.com/irevoire) drastically reduced the size of the keys and saw an important gain in performance. We further tried using the `MDB_INTEGERKEY`, which makes LMDB compare memory using the computer endianness, but it was complex to use and not showing significant performance gains.

Upcoming challenges
-------------------

While porting this cool algorithm to Rust and LMDB, we were missing one of the most important features: Multithreading the tree building. The main reason for this missing feature is LMDB, which does not support concurrent writes to disk. It is part of the beauty of this library; writing is deterministic. We already know LMDB very well, and we will explain how we leveraged the power of LMDB in part 2 of this series and how we beat the Spotify library.

In addition to equalizing the current Annoy features, we needed more for Meilisearch. We implemented [Microsoft's Filtered-DiskANN feature](https://harsha-simhadri.org/pubs/Filtered-DiskANN23.pdf) in Arroy. By providing the subset of item IDs we want to retrieve, we avoid searching the whole trees to fetch the approximate nearest neighbors. We will talk about this in a soon-to-be-released article.

In Meilisearch v1.6, we've optimized performance for updating only document parts, as with vote counts or view numbers. The described single-threaded version of Arroy constructs tree nodes anew for each vector adjustment. [@irevoire](https://github.com/irevoire) will explore Arroy's incremental indexing in his next article, a capability not offered by Annoy.

You can comment about this article on [Lobste.rs](https://lobste.rs/s/4pw9kf/spotify_inspired_elevating_meilisearch), [Hacker News](https://news.ycombinator.com/), [the Rust Subreddit](https://old.reddit.com/r/rust/comments/18dq493/spotifyinspired_elevating_meilisearch_with_hybrid), or [X (formerly Twitter)](https://twitter.com/Kerollmops/status/1733158652444369286).

[Part 2](/blog/refining-ann-performance-with-rust/ and [part 3](/blog/arroy-filtered-disk-ann/ of this series are now available, exploring further advancements in ANN algorithms with Rust.

* * *

[Meilisearch](https://meilisearch.com/?ref=blog.meilisearch.com) is an open-source search engine that not only provides state-of-the-art experiences for end users but also a simple and intuitive developer experience.

For more things Meilisearch, you can join the community on [Discord](https://discord.gg/meilisearch/?ref=blog.meilisearch.com) or subscribe to the [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&ref=blog.meilisearch.com). You can learn more about the product by checking out the [roadmap](https://roadmap.meilisearch.com/?ref=blog.meilisearch.com) and participating in [product discussions](https://github.com/orgs/meilisearch/discussions).

Spotify-Inspired: Elevating Meilisearch with Hybrid Search and Rust

⚡ Meilisearch 1.5
-----------------

[![Meilisearch 1.5 release notes](https://unable-actionable-car.media.strapiapp.com/124_1_50202b66d0.jpg)](/blog/meilisearch-1-5/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

We just shipped Meilisearch 1.5, bringing up to **25% faster indexing**, **on-demand snapshots**, and **Puffin reports** exports. Read the release notes to get the full picture.

[Read release notes](/blog/meilisearch-1-5/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

💼 Meet our customers
---------------------

[![Meilisearch customers page](https://unable-actionable-car.media.strapiapp.com/Screenshot_2023_11_28_at_18_25_33_6d4a7777c7.png)](https://www.meilisearch.com/customers?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

We’ve built a cosy page to host all our customers. All our customer stories —like the [HuggingFace](/blog/hugging-face-democratizes-ai/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog and [Symfony](/blog/symfonys-solution-for-documentation-search/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog success stories— now live there as well.

[View customers](https://www.meilisearch.com/customers?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

📰 In the news
--------------

### 🔍 [A complete guide to full-text search with Laravel](/blog/laravel-full-text-search/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

Everything you need to know to build full-text search with Laravel 10.

### 📈 [Introducing Cloud search analytics](/blog/search-analytics-release/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

Get immediate actionable insight to optimize your search.

### ✈️ [Migrating to Meilisearch Cloud](https://www.meilisearch.com/docs/learn/update_and_migration/migrating_cloud?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

Migrating from self-hosted? Here’s how to handle the migration.

### 🎓 [Navigating search results: pagination vs infinite scroll vs load more](/blog/pagination-vs-infinite-scroll-vs-load-more/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

Learn the pros & cons of the different ways to display search results.

### 🦜🔗 [Building semantic search with LangChain tutorial](/blog/langchain-semantic-search-tutorial/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

Learn how to build semantic search using similarity search.

🥰 Made with Meilisearch
------------------------

[Minipouce.fr](/blog/minipouce-top-grade-customer-experience/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog) is an online platform that enables future parents to create a baby registry list—a list of items to receive as gifts. They integrated Meilisearch to power **search in their marketplace**.

[![Minipouce.fr marketplace](https://unable-actionable-car.media.strapiapp.com/gif_minipouce_aef574247b.gif)](blog/minipouce-top-grade-customer-experience/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

Minipouce.fr marketplace

_We’re always looking to promote new projects from the community. Post yours in the_ [_#built-with-meilisearch_](https://discord.meilisearch.com/) _Discord channel!_

🏡 Life at Meili
----------------

Company culture and benefits are a huge plus. But a decent and fair salary is the number one thing we can do to ensure we take care of our employees. Here’s our **approach to salaries at Meilisearch**.

[![Waving lucky cat](https://unable-actionable-car.media.strapiapp.com/billsbillsbills_9a52817e21.jpeg)](/blog/our-approach-to-salaries/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

[Read blog post](/blog/our-approach-to-salaries/?utm_campaign=newsletter&utm_source=november-news-23&utm_medium=blog)

🦸 We're hiring!
----------------

See our open positions:

*   [Head of Developer Marketing](https://jobs.lever.co/meili/6c9637b0-399a-4300-9f03-1e6f4c450efa)
*   [Senior Account Executive](https://jobs.lever.co/meili/92e2ebdc-3023-4fbe-8dd2-c3cfc9ecd7bf)
*   [People Ops](https://jobs.lever.co/meili/e85fbbd1-0da5-48e1-b65c-35df12f97d76)

* * *

Get these monthly updates straight to your inbox by subscribing to our [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&ref=blog.meilisearch.com).

For more things Meilisearch, join our developers community on [Discord](https://discord.gg/meilisearch/?ref=blog.meilisearch.com). You can learn more about the product by checking out the [roadmap](https://roadmap.meilisearch.com/?ref=blog.meilisearch.com) and participating in [product discussions](https://github.com/meilisearch/product/discussions?ref=blog.meilisearch.com).

Until next time.

Meilisearch November Updates

In this guide, we will see how to use the search functionality in Laravel 10. We'll start with by introducing the benefits of full-text search. Then, we'll walk you through setting up full-text search in your Laravel application.

Why use full-text search?
-------------------------

In traditional SQL or NoSQL databases, queries find results exactly matching given criteria. Conversely, full-text search queries can match some _or_ all of a text query with the database’s content. So essentially, full-text search can provide results even in case of partial matches.

When building user-facing search interfaces, full-text search is empowering for users. Tolerance to typos, prefix search, and synonyms help them get results more quickly. It improves discoverability when users do not know _what_ they're looking for.

<Callout>
  See all [full-text search features](https://www.meilisearch.com/docs/learn/what_is_meilisearch/overview#features?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide) of Meilisearch search engine.
</Callout>

How to use search functionality in Laravel 10?
----------------------------------------------

### Installing Laravel Scout

Laravel comes with out-of-the-box full-text search capabilities via Laravel Scout.

To enable it, navigate to your Laravel application directory and install Scout via the [Composer](https://getcomposer.org/) package manager:

```sh
composer require laravel/scout
```

After installing Scout, you should publish the Scout configuration file. You can do this by running the following artisan command:

```sh
php artisan vendor:publish --provider="Laravel\Scout\ScoutServiceProvider"
```

This command should create a new configuration file in your application directory: `config/scout.php`.

### Configuring the Laravel Scout driver

Let’s configure Laravel Scout to use the Meilisearch driver. Meilisearch is an open-source search engine built in Rust. This will allow to get the best full-text search performance. Indeed, the database driver comes with [limitations inherent to SQL databases](/blog/postgres-full-text-search-limitations/?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide

First, install the dependencies required to use Scout with Meilisearch via Composer:

```sh
composer require meilisearch/meilisearch-php http-interop/http-factory-guzzle
```

Then, update the environment variables in your `.env` file:

```sh
SCOUT_DRIVER=meilisearch
# Use the host below if you're running Meilisearch via Laravel Sail
MEILISEARCH_HOST=http://meilisearch:7700
MEILISEARCH_KEY=masterKey
```

Laravel’s official Docker development environment, [Laravel Sail](https://laravel.com/docs/master/sail), comes with a Meilisearch service out-of-the-box. Please note that when running Meilisearch via Sail, Meilisearch’s host is `http://meilisearch:7700`.

<Callout>
  This comes from Docker [Bridge network driver](https://docs.docker.com/network/drivers/bridge/#differences-between-user-defined-bridges-and-the-default-bridge) behavior.
</Callout>

For production use cases, we recommend using a managed Meilisearch via [Meilisearch Cloud](https://www.meilisearch.com/cloud?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide). On Meilisearch Cloud, you can find your host URL in your project settings.

<Callout>
  Learn [how to get started with Meilisearch Cloud](https://www.meilisearch.com/docs/learn/getting_started/cloud_quick_start?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide).
</Callout>

### Making Eloquent models searchable

With Scout installed and configured, just add the `Laravel\Scout\Searchable` trait to your Eloquent models to make them searchable. This trait will use Laravel’s model observers to keep the data in your model in sync with Meilisearch.

Here’s an example model:

```php
<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Laravel\Scout\Searchable;

class Contact extends Model
{
	use Searchable;
}
```

You can use the `toSearchableArray` method to configure which fields to store in Meilisearch. This notably enables storing a model and its relationships’ data in the same document.

The example below shows how to store a model's relationships data in Meilisearch:

```php
<?php

namespace App\Models;

use App\Models\Company;
use Laravel\Scout\Searchable;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Contact extends Model
{
    use Searchable;

    public function company(): BelongsTo
    {
        return $this->belongsTo(Company::class);
    }

    public function toSearchableArray(): array
    {
	    // All model attributes are made searchable
        $array = $this->toArray();

		// Then we add some additional fields
        $array['organization_id'] = $this->company->organization->id;
        $array['company_name'] = $this->company->name;
        $array['company_url'] = $this->company->url;

        return $array;
    }
}

```

### Configuring filterable and sortable attributes

Meilisearch allows you to perform advanced [filtering](https://www.meilisearch.com/docs/learn/fine_tuning_results/filtering?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide) and [sorting](https://www.meilisearch.com/docs/learn/fine_tuning_results/sorting?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide) on your search results. Choose which attributes are filterable and sortable via your Meilisearch index settings.

Configure your Meilisearch index settings via the `config/scout.php` file:

```php
<?php

use App\Models\Contact;

return [
	// additional configuration...
	
    'meilisearch' => [
        'host' => env('MEILISEARCH_HOST', 'http://localhost:7700'),
        'key' => env('MEILISEARCH_KEY'),
        'index-settings' => [
            Contact::class => [
                'filterableAttributes' => ['organization_id'],
                'sortableAttributes' => ['name', 'company_name']
            ],
        ],
    ],
```

The example above updates Meilisearch index settings for the Contact model:

*   it makes the `organization_id` field filterable
*   it makes the `name` and `company_name` fields sortable

Update your Meilisearch index settings by running the following Artisan command:

```sh
php artisan scout:sync-index-settings
```

Laravel full-text search example
--------------------------------

We built a demo application to give you a feel of what full-text search looks like in a Laravel application. This demo showcases an app-wide search in a CRM (Customer Relationship Management) application.

[![CRM demo application build with Laravel](https://unable-actionable-car.media.strapiapp.com/saas_demo_screenshot_e72232c181.png)](https://saas.meilisearch.com/?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide)

[Laravel SaaS search demo](https://saas.meilisearch.com/?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide)

This demo application uses the following search features:

*   [Multi-search](https://www.meilisearch.com/docs/reference/api/multi_search?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide) (search across multiple indexes)
*   [Multi-tenancy](https://www.meilisearch.com/docs/learn/security/tenant_tokens?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide)
*   [Filtering](https://www.meilisearch.com/docs/learn/fine_tuning_results/filtering?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide)
*   [Sorting](https://www.meilisearch.com/docs/learn/fine_tuning_results/sorting?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide)

The code is open-sourced on Github. 🎉

👉 Check out the repository: [https://github.com/meilisearch/saas-demo](https://github.com/meilisearch/saas-demo)

* * *

We hope this guide helped to understand the importance of full-text search and how to implement it with Laravel. For more information, read the [Laravel Scout](https://laravel.com/docs/10.x/scout) and [Meilisearch](https://www.meilisearch.com/docs?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide) docs.

[Meilisearch](https://meilisearch.com/?ref=blog.meilisearch.com) is an open-source search engine with intuitive developer experience to build user-facing search. You can [self-host](https://www.meilisearch.com/docs/learn/getting_started/quick_start?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide) it or get a premium experience with [Meilisearch Cloud](https://meilisearch.com/cloud?utm_campaign=laravel&utm_source=blog&utm_medium=full-text-search-guide).

For more things Meilisearch, you can join the community on [Discord](https://discord.gg/meilisearch/?ref=blog.meilisearch.com) or subscribe to the [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&ref=blog.meilisearch.com). You can learn more about the product by checking out the [roadmap](https://roadmap.meilisearch.com/?ref=blog.meilisearch.com) and participating in [product discussions](https://github.com/meilisearch/product/discussions?ref=blog.meilisearch.com).

A complete guide to full-text search with Laravel

We’re announcing the release of Meilisearch 1.5. Let’s dive into some of the most important changes.

<Callout>
  Meilisearch 1.5 is also available on [Meilisearch Cloud](https://cloud.meilisearch.com/login?utm_campaign=release-v1-5&utm_source=blog)—upgrade without any downtime now.
</Callout>

Indexing speed improvements
---------------------------

We’re excited to release the first of a series of improvements to Meilisearch’s indexing speed. 🎉

We’ve noticed **up to 25% faster indexing** depending on the use case. The performance gain is more significant on datasets containing a lot of words like wikis or ebooks.

We’ve achieved this by tweaking the settings for multiple-words queries. If you see any impact on your search relevancy, [let us know](https://github.com/orgs/meilisearch/discussions)!

<Callout>
  Take a look at the [indexing speed benchmarks](https://x.com/StriftCodes/status/1726539789401546880).
</Callout>

There’s more regarding indexing speed in version 1.6—but I don’t want to spoil anything 🤫

New feature: on-demand snapshots
--------------------------------

A [snapshot](https://www.meilisearch.com/docs/learn/advanced/snapshots?utm_campaign=release-v1-5&utm_source=blog) is a copy of your database. Snapshot files are useful to backup your database content and settings. Meilisearch 1.5 introduces the ability to create snapshots on demand.

To create a snapshot, use the [relevant SDK](https://www.meilisearch.com/docs/learn/what_is_meilisearch/sdks?utm_campaign=release-v1-5&utm_source=blog) method or the [REST API](https://www.meilisearch.com/docs/reference/api/snapshots?utm_campaign=release-v1-5&utm_source=blog). In JavaScript, create a snapshot like this:

```javascript
const client = new MeiliSearch({ /* credentials */ })
const task = await client.createSnapshot()
```
<Callout>
  You can also [schedule automatic snapshots](https://www.meilisearch.com/docs/learn/advanced/snapshots?utm_campaign=release-v1-5&utm_source=blog#creating-snapshots) on regular intervals.
</Callout>

Experimental feature: Puffin reports
------------------------------------

Puffin reports allow to get information about what’s happening in the search engine. Enabling this feature will make Meilisearch automatically export .puffin file reports. If you’re encountering performance issues, make sure to share your reports with the Meilisearch team.

This experimental feature can be enabled via the [REST API](https://meilisearch.com/docs/reference/api/experimental_features?utm_campaign=release-v1-5&utm_source=blog#configure-experimental-features):

```sh
curl \
  -X PATCH 'http://localhost:7700/experimental-features/' \
  -H 'Content-Type: application/json'  \
--data-binary '{
    "exportPuffinReports": true
  }'
```
<Callout>
  Give feedback regarding Puffin reports in this [Github discussion](https://github.com/orgs/meilisearch/discussions/693).
</Callout>

Contributors shout-out
----------------------

We’re grateful for all the community members who participated to this release. We would like to thank [@braddotcoffee](https://github.com/braddotcoffee), [@harshau007](https://github.com/harshau007), and [@vivek-26](https://github.com/vivek-26). Also, thanks to [@choznerol](https://github.com/choznerol) and [@xshadowlegendx](https://github.com/xshadowlegendx) for contributing to [Charabia](https://github.com/meilisearch/charabia), Meilisearch’s tokenizer. Finally, we extend special thanks to our SDKs maintainers. 🫶

<Callout>
  Learn how you can [contribute to Meilisearch](https://github.com/meilisearch/meilisearch/blob/main/CONTRIBUTING.md).
</Callout>

* * *

And that’s a wrap for v1.5! This release post highlights the most significant updates. For an exhaustive listing, read the changelog on Github.

Stay in the loop of everything Meilisearch by subscribing to [the newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e). To learn more about Meilisearch's future and help shape it, take a look at our [roadmap](https://roadmap.meilisearch.com/) and come participate in our [Product Discussions](https://github.com/meilisearch/product/discussions).

For anything else, join our developers community on [Discord](https://discord.meilisearch.com/?utm_campaign=release-v1-5&utm_source=blog). I’ll see you there 👋

Meilisearch v1.5

You asked for it, and it's finally here! Search analytics has officially landed in the Meilisearch Cloud! We've received numerous [requests](https://roadmap.meilisearch.com/tabs/1-under-consideration) for a way to track key analytics in the Meilisearch Cloud, and we've been hard at work developing a solution that not only empowers you to make data-driven decisions, but also enhances the overall user experience.

So, what's all the buzz about? 🤔
---------------------------------

The new dashboard incorporates a set of metrics providing insights into your users' search behaviors. Its purpose is to give you a quick and comprehensible overview of user search queries and highlight what they might be missing. The implications are vast:

*   Improve recommendations and popular search sections, bolstering e-commerce through cross-selling.
*   Create intelligence reports for your customers.
*   Fine-tune settings and ranking rules to optimize search experiences and inform business decisions.

![](https://unable-actionable-car.media.strapiapp.com/search_analytics_gif_093e60c664.jpg)

What metrics can you expect?
----------------------------

The first iteration of cloud analytics covers the following metrics:

*   Daily searches chart
*   Most searched queries
*   Searches without results
*   Daily search latency
*   Total searches
*   Total users
*   No result rate
*   Click through rate\*
*   Average click position
*   Daily searches per index
*   Conversion\*

\*_The CTR (click-through rate) and the conversion rate_ [_must be configured_](https://www.meilisearch.com/docs/learn/cloud/analytics?utm_campaign=analytics-v1&utm_source=blog) _to fit a specific use case or need._

The default view combines the data from the indexes per project, but it’s also possible to filter out the insights for a specific project of your choice. The dashboard also allows you to select a custom range using a date picker:

![](https://unable-actionable-car.media.strapiapp.com/sa_index_data_picker_gif_56b1687bfd.jpg)

For a detailed walkthrough, check out the [live demo recording of search analytics](https://www.youtube.com/watch?v=yCQWha562M0) on our YouTube channel.

The benefits of search analytics insights
-----------------------------------------

There are numerous advantages to gaining deeper insights into how your users interact with search. With our brand-new dashboard, you can:

*   **Gain rapid, actionable insights into your search performance** at a glance.
*   **Enhance your users' experience** by continuously optimizing result relevancy.
*   **Make more informed business decisions** by understanding your users and their needs.
*   For eCommerce and marketplaces: **develop cross-selling and upselling strategies to boost conversions.**

This marks just the beginning of our optimization and insights journey. Stay tuned for v2, where we will introduce advanced analytics capabilities and subviews.

### Availability and plans

The new Cloud search analytics are available for all Cloud users across all pricing tiers. Each tier has access to the same analytics and chart functionalities of the search analytics dashboard, with the distinction occurring in the _length of data retention_ provided to each tier: 7 days for the Build plan, 30 days for the Grow plan, and 90 days for both Pro and Enterprise plans.

[Try it in Meilisearch Cloud](https://cloud.meilisearch.com/?utm_campaign=analytics-v1&utm_source=blog)

Learn how to [get started with Meilisearch Cloud](https://www.meilisearch.com/docs/learn/getting_started/cloud_quick_start?utm_campaign=analytics-v1&utm_source=blog) and read the [Analytics documentation](https://www.meilisearch.com/docs/learn/cloud/analytics?utm_campaign=analytics-v1&utm_source=blog).

* * *

Stay in the loop by subscribing to our [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&utm_campaign=teams-release&utm_source=blog). To learn more about Meilisearch's future and help shape it, take a look at our [roadmap](https://roadmap.meilisearch.com/?utm_campaign=teams-release&utm_source=blog) and participate in our [Product Discussions](https://github.com/meilisearch/product/discussions/?utm_campaign=teams-release&utm_source=blog).

For anything else, join our developer community on [Discord](https://discord.meilisearch.com/?utm_campaign=teams-release&utm_source=blog).

Search analytics have arrived!

[Meilisearch Cloud](https://meilisearch.com/cloud?utm_campaign=teams-release&utm_source=blog) introduces the all-new Teams feature. Now you can host and manage your projects in collaboration with your teammates.

Keep reading to learn how to use our Teams feature.

**Creating a team**
-------------------

From your main dashboard, click on the dropdown menu next to the Meilisearch logo on the top navbar, select _Create a team_. By clicking it and assigning a name to your team, your collaborative space is instantly set up.

![Create a team](https://unable-actionable-car.media.strapiapp.com/teams_1_cb16300cee.png)

**Inviting team members**
-------------------------

To invite your colleagues, navigate to the team settings, click on _Invite new member_, and enter their email address.

![Invite new member](https://unable-actionable-car.media.strapiapp.com/team_2_03149ccabf.png)

When you invite someone to a team, they receive an invitation link via email, and upon acceptance, they can start collaborating immediately. If they already have an account, a notification pops up on their dashboard too.

Collaborating
-------------

Every team member can create their own projects, ensuring everyone has a say in the collaboration.

Managing a team
---------------

For team owners have extensive control. They can modify project plans and update billing information.

From the _Team settings_ section, team owners can rename their team, manage user invitations and removals, and even transfer ownership.

![Team settings](https://unable-actionable-car.media.strapiapp.com/teams_4_468f5be5d0.png)

We hope this new release will improve collaboration with your team! Now start sending those invites 😜

[Open Meilisearch Cloud](https://cloud.meilisearch.com/?utm_campaign=teams-release&utm_source=blog)

Learn how to [get started with Meilisearch Cloud](https://www.meilisearch.com/docs/learn/getting_started/cloud_quick_start?utm_campaign=teams-release&utm_source=blog).

* * *

Stay in the loop by subscribing to our [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&utm_campaign=teams-release&utm_source=blog). To learn more about Meilisearch's future and help shape it, take a look at our [roadmap](https://roadmap.meilisearch.com/?utm_campaign=teams-release&utm_source=blog) and come participate in our [Product Discussions](https://github.com/meilisearch/product/discussions/?utm_campaign=teams-release&utm_source=blog).

For anything else, join our developer community on [Discord](https://discord.meilisearch.com/?utm_campaign=teams-release&utm_source=blog).

Introducing Teams — Meilisearch Cloud

🤩 Meilisearch v1.4 is live
---------------------------

0:00

/0:59

1×

Meilisearch v1.4 introduces the ability to configure **custom text separators** and **user-defined dictionaries**. Check out these shiny new features in action in our [video](https://www.youtube.com/watch?si=a8RiA4ZidNkC0Bgd&v=730tYmlFG9I&feature=youtu.be).  For more details, you can also read the [release blog post](/blog/v1-4-release/?utm_campaign=newsletter&utm_source=october-news-23

[Read release blog](/blog/v1-4-release/?utm_campaign=newsletter&utm_source=october-news-23)

🚀 Symfony success story
------------------------

![Symfony's search solution for 12M words of documentation with Meilisearch](https://unable-actionable-car.media.strapiapp.com/symfony_4179adf8bf.png)

With Meilisearch, Symfony enhanced the search functionality across its **30 versions and 12M words of documentation**, significantly **boosting the speed and quality** of search results.

[Read sucess story](/blog/symfonys-solution-for-documentation-search/)

🗓 Save the date: upcoming live demo
------------------------------------

![Getting started with Meilisearch Cloud. Featuring live demo, product release updates, and Q&A. Thursday, Novemeber 2nd. 4PM CET, 3PM GMT, 11AM EDT](https://unable-actionable-car.media.strapiapp.com/unnamed_0a521c383b.png)

Join us on **November 2nd** to see a **live demo** of **Meilisearch Cloud** and its key capabilities. Get a first sneak peek of our newest **Search Analytics product release**. Bring your questions for the **live Q&A session** with our experts: **Thomas, Meilisearch’s cofounder**; and **María from the Product team**.

👉 Secure your participation [here](https://us06web.zoom.us/meeting/register/tZMlc-mqrjIsH912-HTRe-AaT-pp41bDe81a#/registration).  
  
We look forward to seeing you there!

[Register now](https://us06web.zoom.us/meeting/register/tZMlc-mqrjIsH912-HTRe-AaT-pp41bDe81a#/registration)

* * *

📰 In the news
--------------

### 🔁 [Syncing Meilisearch with your PostgreSQL database](https://www.meilisearch.com/docs/learn/cookbooks/meilisync_postgresql?utm_campaign=newsletter&utm_source=october-news-23)

Learn how to keep Meilisearch in sync with your PostgreSQL database.

### 🔻 [Guide to hierarchical faceted search](/blog/nested-hierarchical-facets-guide/?utm_campaign=newsletter&utm_source=october-news-23)

Structure data and use Meilisearch to navigate through nested hierarchical facets from general to specific categories.

### 🌥 [Getting started with Meilisearch Cloud](https://www.meilisearch.com/docs/learn/getting_started/cloud_quick_start?utm_campaign=newsletter&utm_source=october-news-23)

Our latest guide helps you get the best of Meilisearch without the hassle of self-hosting.

### 💾 [Squeezing millions of documents in 128 TB of virtual memory](/blog/dynamic-virtual-address-management/?utm_campaign=newsletter&utm_source=october-news-23)

How dynamic management of virtual memory enabled us to remove limitations in Meilisearch indexing policy.

### 🤓 [Are you indexing the smart way?](/blog/best-practices-for-faster-indexing/?utm_campaign=newsletter&utm_source=october-news-23)

Review the best practices to index your data efficiently and speed up the indexing process

* * *

🥰 Made with Meilisearch
------------------------

[Cardmapr](https://cardmapr.nl/) is back on the spotlight! Originally featured in our [newsletter #9](https://mailchi.mp/meilisearch/newsletter-5970105) for helping users discover businesses and their accepted credit cards, we're bringing it to the limelight again.

Why? They've  integrated a **WhatsApp service** into their platform. Now, users can send their location through WhatsApp, and thanks to **Meilisearch's [**geosearch**](https://www.meilisearch.com/docs/learn/fine_tuning_results/geosearch)** capability, instantly receive nearby hotspots.

![nimated GIF showing a mobile phone screen displaying a messaging app. A message is received from 'Location' with the headline 'Locaties in Zwolle.' A brief summary mentions 157 locations found near the user's location in Zwolle, including 23 restaurants, 6 hotels, 20 fashion stores, and 13 supermarkets. There's also a link provided to view all these locations. ](https://unable-actionable-car.media.strapiapp.com/cardmapr_8a2b570a4e.gif)

<Callout>
  __We’re always looking to promote new projects from the community. Post yours in the__ [__#built-with-meilisearch__](https://discord.meilisearch.com/?ref=blog.meilisearch.com) __Discord channel or share it on Twitter/X with the #MadeWithMeilisearch hashtag!__)
 
</Callout>

* * *

🏡 Life at Meili
----------------

Discover the rationale, implementation, and outcomes of our shift to a four-day workweek, reflecting our commitment to work-life balance while maintaining operational excellence.

![A pair of hands holding up a large red alarm clock with a white frame, set against a bright turquoise background. The clock displays 4:22 time. The person's nails are painted in a vibrant red to match the clock's face.](https://unable-actionable-car.media.strapiapp.com/malvestida_magazine_Ffb_VFLA_Vscw_unsplash_f041fe4532.jpeg)

[Read blog post](/blog/how-we-implemented-the-4-day-work-week/?utm_campaign=newsletter&utm_source=october-news-23)

* * *

🦸 We are hiring!
-----------------

See our open positions:

*   [People Ops](https://jobs.lever.co/meili/e85fbbd1-0da5-48e1-b65c-35df12f97d76)
*   [Senior Account Executive](https://jobs.lever.co/meili/92e2ebdc-3023-4fbe-8dd2-c3cfc9ecd7bf)

* * *

Get these monthly updates straight to your inbox by subscribing to our [newsletter](https://meilisearch.us2.list-manage.com/subscribe?u=27870f7b71c908a8b359599fb&id=79582d828e&ref=blog.meilisearch.com).

For more things Meilisearch, join our developers community on [Discord](https://discord.gg/meilisearch/?ref=blog.meilisearch.com). You can learn more about the product by checking out the [roadmap](https://roadmap.meilisearch.com/?ref=blog.meilisearch.com) and participating in [product discussions](https://github.com/meilisearch/product/discussions?ref=blog.meilisearch.com).

Until next time.

Meilisearch latest news and company updates