Support for Join-like Relationships Across Index

[Kavan72]

Hello Meilisearch Team,

First, I want to say thank you for building such an incredibly fast, developer-friendly search engine. The performance and ease of setup are really impressive, and Meilisearch has been a joy to work with.

That said, I wanted to propose a feature that could unlock powerful use cases for more complex applications: support for join-like behavior across indexes/documents — similar to what Typesense introduced in version 26.0.

🔍 Why Joins Matter

In many real-world use cases, data is relational in nature. For example:

• A books collection with author_id, and a separate authors collection
• An orders collection referencing customers
• A products collection with category_id, pointing to categories

Currently, Meilisearch requires us to denormalize the data manually, which works in many scenarios, but has significant drawbacks:

• Duplicate data: The same information (e.g., author name, category title) gets copied across many documents.
• Inconsistent updates: If a referenced field changes (like an author’s name), all related documents must be re-indexed.
• Complex data pipelines: Developers must build custom sync logic to maintain denormalized data, which increases the complexity and risk of data drift.

Supporting reference fields or lightweight joins would solve these issues elegantly and make Meilisearch much more robust for large, structured datasets.

🆚 Typesense’s Example (v26.0)

Typesense recently added support for references between collections. Their approach allows defining a field in one collection as a reference to another, and including related fields in queries.

{
  "name": "books",
  "fields": [
    { "name": "author_id", "type": "string", "reference": "authors.id" }
  ]
}

And querying with:

{
  "collection": "books",
  "q": "dune",
  "include_fields": "$authors(name,bio)"
}

This removes duplication, simplifies updates, and enables richer search results — all while keeping the indexing and query interface fast and predictable.

🙏 Proposed Behavior in Meilisearch

I understand that Meilisearch is designed for speed and simplicity. However, even a minimal reference system could go a long way:

• Define fields that reference other indexes
• Allow including referenced data at query time (read-only, optional)
• Help eliminate duplication and reduce the need for full document rewrites

This would enable better maintainability and data integrity for apps like CRMs, ecommerce platforms, learning portals, and CMSs — where structured search is often required.

Thanks again for all the amazing work on Meilisearch. Looking forward to hearing your thoughts on whether a feature like this could fit into the future roadmap, or if there are alternative patterns you’d recommend for handling cross-collection relationships efficiently.

[urvisism]

@Kavan72
I want to echo your suggestion for implementing join-like capabilities in Meilisearch. Handling relational data often requires denormalization, which can lead to redundancy and increased maintenance overhead. Introducing native support for reference fields or lightweight joins would greatly enhance Meilisearch's flexibility and efficiency in managing complex datasets.​

This feature would be a valuable addition, aligning Meilisearch more closely with real-world data modeling needs. Looking forward to seeing how the team considers this proposal.

[dureuill]

Hello @Kavan72 and @urvisism

Should it be possible to search in the fields of the joint index, or should the joint data "only" be recovered once the results have been decided by the search?

For example, when searching "Harry" in the "books" index that references the "authors" index, should an author with "Harry" in their name cause a hit, or only books with "Harry" in their title/description?

[urvisism]

Hello @dureuill
The joint data can only be retrieved after the search results have been determined.
However, while searching in the "books" index, it should be possible to filter results based on the joint fields.
In your example, documents in the "books" index should be filtered based on their authors listed in the "authors" index.
For instance, I only want to search for books written by authors like Harry and Hermione.

[Kavan72]

Hello @dureuill, thanks for the thoughtful question!

I agree with @urvisism — the join data should only be included after the primary search results are determined, not influence the scoring or matching of the main index.

IMO, searching inside the referenced (joined) index isn’t ideal, as it could introduce unnecessary complexity and performance costs. However, being able to:

• Filter based on fields from the joined collection (e.g., author.name = 'Harry')
• Include those joined fields in the final response

…would strike a perfect balance between flexibility and performance.

This way, Meilisearch can remain fast and simple, while still supporting more structured data use cases. Looking forward to seeing where this discussion leads!

[dureuill]

Understood, it seems reasonable not to be able to search in joint indexes.

I guess from the moment you want the filters though, you need an "inverted index" of which documents from the books index reference any particular document from the author index 🤔

I'm thinking about how to resolve a filter:

1. resolve the author.name filter on the authors index to get a list of documents from the "authors" index that match the filter.
2. Iteratively look at the matching documents from "authors" and find the documents from the "books" index that have these authors. <- this is costly ⚠
3. search in this set of books.

Alternatively, we could maintain an inverted index mapping the author names to the documents from the books index. But this negates a lot of the advantages of references the author index (it is basically the same as having author.name a filterable attribute in books directly).

🤔 need to think more.

[Kavan72]

Hi @dureuill, thanks for the thoughtful response!

You’re absolutely right — filtering based on joined fields does introduce additional complexity, especially if we try to resolve the filter by traversing another index in real-time. That could be quite costly.

In my opinion, there are two distinct use cases we should consider:

1. Join for inclusion only (read-only projection)

This is the simplest and most common case — where the client just wants to include related fields from a referenced index (like author.name) in the final response.

• No filtering
• No scoring influence
• Just enrich the response payload

In this case, the joined index can be queried post-search in a non-blocking way (maybe with caching or partial materialization).

2. Filtering on joined fields (e.g., author.name = "Harry")

This case is trickier, because the search engine would need to:

1. Resolve the filter on the authors index (name = "Harry" → get author_ids)
2. Filter the books index by those author_ids

As you pointed out, doing this naively would require traversing references and scanning document relationships — which is computationally expensive and breaks Meilisearch’s speed guarantees.

Maintaining a reverse (inverted) reference map like:

{
  "author_id_123": ["book_id_1", "book_id_7", "book_id_9"]
}

…would technically solve it, but as you mentioned, it essentially reintroduces denormalization — defeating the purpose of references.