English Vocabulary for Meilisearch Developers

Meilisearch is an open-source, developer-friendly search engine known for its fast setup, typo tolerance, and clean REST API. It is used to add powerful search experiences to applications without the operational complexity of Elasticsearch. Meilisearch has a specific vocabulary — indexes, filterable attributes, faceting, hybrid and vector search — that engineers need to understand to configure search correctly and communicate clearly with teammates. This post covers the core terms you will encounter when building with Meilisearch.

Key Vocabulary

Index The fundamental organizational unit in Meilisearch. An index holds a collection of documents that can be searched together. Each index has its own settings (filterable attributes, ranking rules, etc.) and is identified by a unique string name. Think of an index as a search-scoped database table. Example: “Create a separate index for products and another for blog posts — each index has different ranking rules and filterable attributes, so keeping them separate makes configuration cleaner.”

Documents The records stored inside a Meilisearch index. Each document is a JSON object with a unique identifier (by default the id field) and any number of other fields. Meilisearch indexes all string fields for full-text search by default. Example: “Add documents to the products index using the POST /indexes/products/documents endpoint — Meilisearch will make them searchable within milliseconds.”

Search parameters The options you pass in a search request to customize how results are returned. Common parameters include q (the search query), filter, sort, limit, offset, facets, and attributesToRetrieve. Composing these parameters correctly is the core of Meilisearch query building. Example: “Use the filter search parameter to restrict results to in-stock products, sort to order by price, and facets to return category counts alongside the results.”

Filterable attributes Fields that you explicitly configure as filterable in the index settings. Only fields listed in filterableAttributes can be used in filter expressions at search time. You must configure this before filters will work. Example: “Add category, brand, and in_stock to filterableAttributes in the index settings — the frontend is trying to filter by these fields and currently getting an error.”

Sortable attributes Fields configured in sortableAttributes that can be used in sort expressions. Like filterable attributes, these must be declared in settings before they can be used at search time. Adding a field to sortable attributes has an indexing cost. Example: “Add price and rating to sortableAttributes — users need to be able to sort search results by price ascending and by average rating.”

Faceting The feature that returns aggregated counts of documents per attribute value alongside search results — for example, “Electronics (42), Clothing (18), Books (7).” Facets power the filter sidebars common in e-commerce search interfaces. Example: “Enable faceting on category and brand — we need the counts to render the filter sidebar so users can narrow results without re-querying for each combination.”

Hybrid search A search mode that combines traditional keyword search (BM25 relevance ranking) with vector search (semantic similarity) in a single query, using a configurable semanticRatio to weight the two signals. This produces results that match both exact terms and related concepts. Example: “Switch to hybrid search with a semanticRatio of 0.5 — users searching for ‘laptop bag’ should also find results for ‘notebook sleeve’ even if those exact words aren’t in the query.”

Vector search A search mode where documents are retrieved based on semantic similarity to a query embedding rather than keyword overlap. Meilisearch can store vector embeddings alongside documents and use them for nearest-neighbor retrieval at search time. Example: “Generate embeddings for each product description using an embedding model and store them in the _vectors field — then enable vector search to find semantically similar products.”

How to Use This Vocabulary

Meilisearch configuration discussions typically follow a pattern: define the index, add documents, then configure settings (filterable attributes, sortable attributes, ranking rules). A common mistake teams make is adding documents before configuring settings, then discovering that filter fields are not set up — this requires updating settings and waiting for re-indexing.

Search parameter discussions often involve trade-offs between limit (how many results per page), facets (which attributes to aggregate), and sort (how to order results). Teams also debate when to enable hybrid or vector search — usually when keyword search alone fails to surface relevant results for vague or conceptual queries.

Example Conversation

Dana: The search for “wireless headphones” isn’t returning noise-canceling results even when we have them in stock. Chris: That sounds like a keyword gap. Have you tried hybrid search? Set semanticRatio to 0.3 and see if the semantic signal picks up the relationship. Dana: Good idea. Also, I need to add noise_canceling to filterableAttributes — the filter panel isn’t working for that field yet. Chris: Update the settings and re-index. It’ll be live in a few seconds.

Practice

1. Design a Meilisearch index for a recipe search app. Identify at least three fields that should be filterableAttributes (e.g., dietary restrictions, cuisine type) and two that should be sortableAttributes. Write down your configuration in plain English.
2. Explain the difference between filterable attributes and search parameters to a junior developer. Use a restaurant search example: what is configured once in settings vs. what is sent with each search request?
3. Write a short paragraph describing when you would choose hybrid search over pure keyword search, and what semanticRatio value you would start with and why.

Navigating Nuance: Common Phrasing Around Search Data

Understanding Meilisearch’s core concepts – indexes, documents, filters, facets – is one thing. Communicating effectively about them within a development team, particularly when discussing performance, changes, or troubleshooting issues, requires a slightly different skillset. This isn’t just about knowing the definitions; it’s about recognizing common phrasing and how professionals describe search behavior and data relationships. A significant hurdle for non-native English speakers often lies in subtle differences in terminology and the way these concepts are typically discussed in agile development environments. For example, saying “the index is slow” isn’t enough; you need to articulate why it’s slow – is it a query issue, an indexing problem, or a data volume concern? Similarly, describing a complex filter chain requires precise language to avoid ambiguity and ensure everyone understands the intended behavior.

One area where confusion frequently arises is around “hybrid search” and its impact on results. Rather than simply stating “hybrid search isn’t working,” a more constructive approach would be, “We’re seeing a noticeable decrease in relevance scores for queries utilizing the hybrid search configuration. The current weighting of the full-text and vector searches appears to be contributing to this issue; we should investigate adjusting the minScore parameter.” This phrasing immediately highlights the specific area needing attention – the weighting – and suggests a concrete action (investigating). Another common phrase you’ll hear is “query latency,” which refers to the time it takes for Meilisearch to respond to a search request. It’s far more informative than simply saying “the query is slow.” You might also encounter discussions about “tokenization” and “stemming,” terms that, while technically accurate, are often best explained in simpler terms when discussing impact on search speed or accuracy.

Furthermore, be mindful of how you describe changes to the index. Instead of a vague “updated the index,” use language like: “Implemented an incremental update to the products index, incorporating new product data and optimizing the indexing pipeline for faster performance.” This level of detail allows reviewers to assess the impact of the change and understand any potential side effects. Finally, remember that collaboration is key. If you’re unsure about a term or concept, always ask for clarification – it’s far better to err on the side of precision than to make assumptions based on incomplete understanding.

Here’s an example of how Meilisearch can be used in a practical scenario:

meilissearch sync --url http://localhost:8080/ --collection products --data '{"name": "Laptop", "description": "A powerful laptop for developers."}'

This command demonstrates the simplest way to add new data to an index. The sync command, combined with the data parameter, allows you to quickly populate a Meilisearch collection with new documents. It’s crucial to understand that this is just one element of a larger indexing process – monitoring the indexing pipeline and ensuring optimal performance are equally important considerations when discussing search data.