Elasticsearch review: Why developers are choosing Meilisearch for simplicity in 2025

I’ve always loved coding, from the quiet flow and small wins to the feeling of seeing something come alive on the screen.

Yet as Melisearch grew and I fully stepped into my role as co-founder and CEO, those moments became rare. You know how it is: your days fill up with calls, emails, and strategy meetings. The deeper you get into running the company, the further you drift from the keyboard.

Then I discovered vibe coding, and for the first time in years, I felt like I had time to build again – quickly, playfully, almost effortlessly.

Essentially, you describe what you want in a prompt, using natural language, and an AI writes the code for you. You don’t analyze the code line by line. You just follow the flow. You chase the result. You chase the vibe.

Almost a year in, I can tell you this: *vibe coding is addictive*. It feels like magic, and it reignited the part of me that just loves to create. 

It’s fast, thrilling, and yes, sometimes mentally draining, but in the way any great creative process can be.

Let me explain what I mean.

## Why vibe coding feels so addictive

Vibe coding has a rhythm that pulls you in. The AI writes code faster than you can imagine, and you watch your ideas come to life almost instantly while barely lifting a finger. 

It’s a kind of creative acceleration I’ve never experienced before. You get used to that pace, and it’s intoxicating.

### Just one more prompt

It starts innocently enough. You write one prompt to create a new feature. You make a few tweaks to test an idea. Then, suddenly, you’re chasing “just one more prompt.” 

The AI responds instantly, revealing things you might not have imagined yourself, sparking curiosity and adrenaline. It’s like gaming: one more level, one more round, one more challenge.

According to Lydia Chilton, Associate Professor of Computer Science at Columbia Engineering, [as cited by Columbia AI](https://ai.columbia.edu/news/ai-creativity-photography-art), innovation starts with the ‘flare’ stage, where you brainstorm ideas and solutions. She notes that AI amplifies this stage by letting you explore more ideas, run more experiments, and design faster than ever before.

That’s why, for me, each new prompt is like a mini-reward that gives me a dopamine rush. It’s a sort of high that I can’t get enough of.

### Speed feels like power

Traditional coding gives you natural pauses. Typing forces you to think, plan, and troubleshoot. 

With vibe coding, the AI does the code writing, and your only job is to keep up. Every result appears row by row, and your brain races to process it, evaluate it, and type in the next prompt.

It’s a creative flow in its purest form, an exhilarating conversation between you and the machine. 

I find myself doing it all the time: while drinking my morning coffee, during a break, or late at night when inspiration strikes.

Every prompt feeds the next. Every result creates a new possibility. The speed is empowering because it smooths things out between your thoughts and their realization.

## The other side of vibe coding

Like any powerful tool, vibe coding requires a bit of balance. The rush can blur time, and when the session ends, your mind feels both satisfied and exhausted.

You might wake up the next day mentally drained, replaying the ideas you explored the night before. 

For me, this is a sign of deep engagement, the same kind of creative fatigue that follows a productive all-night brainstorming session.

But not everyone agrees…

### Your brain can have a hard time keeping up

The biggest challenge of vibe coding is keeping your head in the game. You’re jumping between ideas, testing, prompting, debugging, and the output never stops.

[Researchers at MIT found that](https://www.media.mit.edu/projects/your-brain-on-chatgpt/overview/) extensive reliance on AI for creative tasks can reduce deep focus and comprehension. 

This makes sense because once you stop typing and start prompting, your brain is no longer engaged in the same way. 

Every time you skip reading and analyzing the AI-generated code, you give up a little bit of understanding. Over time, those skipped moments add up, and you can lose touch with how the system really works.

As Andrej Karpathy, the computer scientist who introduced the concept of vibe coding, [wrote in his now-famous post on X](https://x.com/karpathy/status/1886192184808149383?lang=en): “The code grows beyond my usual comprehension, I'd have to really read through it for a while.”

Still, vibe coding simply pushes you to think differently. As long as you stay curious and read what the AI produces, you can turn speed into skill.

### Everything can start to sound the same

The code looks clean, the structure makes sense, but it feels too familiar. It reads like a snippet from a coding tutorial on YouTube or a GitHub repo you’ve never seen but somehow recognize.

That’s the thing with AI-generated code: it can sometimes feel like everyone’s work and no one’s in particular, at the same time. It can have the shape of expertise, but lack creativity, until you add yours back in.

[According to Columbia AI](https://ai.columbia.edu/news/ai-creativity-photography-art), Lydia Chilton calls AI “reductive and fundamentally unoriginal” because it doesn’t know how to judge or refine what it generates.

This is where the human element comes in. Your quirks, your choices, your deviations from convention are what make the output yours.

When you bring your perspective into the loop, vibe coding stops being generic and starts being expressive and meaningful again.

## Where this could lead

Vibe coding shows what happens when creativity meets automation head-on. The line between thought and execution is gone. 

It’s a new kind of craftsmanship and it’s extraordinary!

Those long hours of debugging that used to build patience and precision can now be invested in design thinking, experimentation, or storytelling.

Even if the work changes its shape, your spirit can remain the same.

### Two directions

We can already see two paths forming:

* Some developers dive headfirst into the fast, freeform rhythm of vibe coding. 
* Others prefer [what Simon Willison calls ‘vibe engineering,](https://simonwillison.net/2025/Oct/7/vibe-engineering/)’ where AI tools improve your work but never replace your judgment. 

Both approaches work as long as you know when to let the AI lead and when to step in.

Vibe coding can make you feel like the ideas are racing ahead of you, but that’s part of its magic. The real skill is deciding which ideas are worth pursuing. 

You choose the problems that matter, the features that add value, and the solutions that feel right. Let AI handle the repetitive work while you focus on creativity, purpose, and direction.

## The bottom line

Vibe coding is a reminder that AI tools can speed up work and reignite curiosity. 

Every morning when I open my laptop, I feel the same spark that got me into coding in the first place. 

I prompt, I explore, I build, and it’s thrilling, but I still need to remind myself every once in a while to slow down and stay grounded.

If AI makes coding feel like a game, then the real skill now is learning to play it well.

Have you felt that pull too?

If you’ve found yourself chasing just one more prompt or losing track of time while coding with AI, I’d love to hear about it. How has vibe coding changed the way you create?


I’m a developer who vibe codes – and you should, too

Elasticsearch vs Qdrant (vs Meilisearch): Which search solution actually fits your needs in 2025?

This is the third in our series on practical RAG with Meilisearch. In [post #1](https://www.meilisearch.com/blog/mastering-rag), we explained how hybrid retrieval (lexical + semantic) boosts both recall and precision so your results are actually the right ones. In [post #2](https://www.meilisearch.com/blog/rag-with-meilisearch), we walked through the full RAG pipeline: query refinement → retrieval → generation, and why keeping those pieces integrated keeps latency low and the system simple.

In this post, we focus on how teams actually ship. We’ll look at three patterns that show up over and over in real products: **R**etrieval, **A**nswers, and **G**rowth, and illustrate each with concrete use cases from teams using Meilisearch today.

## (R)etrieval: making the search bar fast, precise, and dependable

Shoppers don’t want an essay about sneakers; they want the right product card with a clean **'Add to cart' button**. In a commercial flow, generation is optional, but **retrieval quality** is everything. That’s the heart of the revenue pattern: make rank #1 correct, obvious, and fast, so the next click is a purchase, and not a string of revised queries.

![retrieve-find-results-fast.png](https://unable-actionable-car.media.strapiapp.com/retrieve_find_results_fast_84dd0e3314.png "Retrieve: Find results fast and accurately")

You can see this play out at [**Bookshop.org**](https://www.meilisearch.com/blog/bookshop-increases-search-based-purchases), where better retrieval directly translates into more purchases from search, increasing from 14% of searches leading to a purchase to 20%, a **43%** relative lift. That’s the sort of metric you feel in the revenue graph, and it came from relevance, not more copy. 

[**Minipouce**](https://www.meilisearch.com/blog/minipouce-top-grade-customer-experience) showcases the “great on day one” angle: solid defaults, typo tolerance, and intuitive facets produce results that feel right without weeks of tuning. 

And for teams outside classic retail, [**Qogita**](https://www.meilisearch.com/blog/qogita-simplifies-b2b-trade) (B2B marketplace) and [**HitPay**](https://www.meilisearch.com/blog/hitpay-streamlines-search) (fintech/commerce) exhibit the same retrieval-first pattern, dropping into very different surfaces: fast to set up, easy to operate, and friendly to lean teams.

What makes this work is a short, disciplined loop: hybrid ranking to catch both exact matches (“Air Max 270 black 42”) and intent phrasing (“black Nike runners size 9”), facets that narrow instantly, and a UI that respects the action. Keep an eye on zero-results queries, measure search→purchase conversion, and treat synonyms/typos as first-class relevance features. When intent is commercial, **R > G**: retrieval first, retrieval last.

## (A)nswers (retrieval + generation): one reliable answer beats ten links

Internal questions are scavenger hunts across policies, procedures, docs, tickets, and code. Your teammate doesn’t want ten blue links; they want a short, sourced answer they can act on. That’s where **retrieval + generation** shines: retrieval assembles the right building blocks; generation assembles them into a trustworthy and concise answer.

![answer-produce-accurate-answers.png](https://unable-actionable-car.media.strapiapp.com/answer_produce_accurate_answers_c4524820d2.png "Answer: Produce accurate answers synthesizing the searched results.")

In practice, [**Louis Vuitton**](https://eu.louisvuitton.com/eng-e1/homepage) is a clear example: store associates get consistent, fast answers to policy and product questions across locations. The value isn’t that an LLM can chat – it’s that retrieval surfaces current, canonical guidance, and generation condenses it into steps a person can follow. 

For developer productivity, [**Symfony**](https://www.meilisearch.com/blog/symfonys-solution-for-documentation-search) shows what low-latency, well-scoped search looks like at scale: sub-10 ms responses over **85,000+** docs across **30** versions help engineers land on the exact class, command, or procedure they need. At [**OCTO Technology**](https://www.meilisearch.com/blog/meilisearch-is-a-partner-of-choice-for-octo), the same approach operates as a dependable, production-ready solution in client environments where reliability and maintainability are crucial.

The craft is in the details: make retrieval source-aware (favor canonical and current, down-rank duplicates and stale pages), retrieve **snippets** instead of whole pages so the model stays on a short leash, and use a prompt that’s opinionated about behavior, yet can synthesize briefly, cite every claim, include steps or a code block when useful, and say “no evidence found” instead of guessing. A tiny feedback loop (“useful / missing / outdated”) helps you fix the source, not just the surface.

## (G)rowth (infrastructure): scale you don’t have to think about

Most RAG stories focus on search and answers. That’s great, until the demo grows up. The catalog doubles, traffic spikes on a Tuesday, someone adds three new locales, and suddenly your tidy prototype is juggling a keyword engine, a vector store, and a re-ranker stitched together with custom middleware. Queries get slow, dashboards get noisy, and your on-call starts carrying two laptops.

![grow-scale-effortlessly.png](https://unable-actionable-car.media.strapiapp.com/grow_scale_effortlessly_0f7c99ddde.png "Grow: Scale effortlessly as the data and customer base grow")

Some things are meant to be boring, and **scaling** should be one of them. Instead of an ever-changing stack where you tweak three services every time the user base grows, **Meilisearch offers one hybrid path** that stays fast as you add data, users, and languages. **One engine and one request handle both lexical precision and semantic recall.** No service hopping, fewer moving parts, and fewer surprises. As the client, you focus on content and UX, and we focus on the plumbing.

That’s the experience we aim for with Meilisearch. Index growth feels like adding shelves, not rebuilding the warehouse. Versioned indexes and safe schema changes turn “we need a new attribute” into a routine deployment. Language-aware analyzers, combined with embeddings, handle phrasing differences without a meeting. Monitoring covers what actually matters: latency *and* quality. That way you can spot recall/precision drift before users do. And vectors don’t have to eat your budget: compact embeddings, ANN indexes, and only storing what moves relevance keep costs sensible.

You can see this pattern in the wild. **CarbonGraph** moved from a standalone vector setup and found that adding embeddings inside a hybrid engine was straightforward, meaning no extra choreography was required. 

[**Hugging Face**](https://www.meilisearch.com/blog/hugging-face-democratizes-ai) is the stress test: discovery keeps working across **2.2M model cards**, **500k datasets**, and **60k demos** without turning every query into a science project. 

And for “hard-mode” content, [**TutKit**](https://www.meilisearch.com/blog/tutkit-multilingual-learning-at-scale) serves **15,000+** items in **26 languages**, while [**Bildhistoria**](https://www.meilisearch.com/blog/powering-bildhistoria-discovery) keeps **90,000+** richly annotated historical images findable and fast. Different shapes of data, the same quiet promise: it scales, and you barely notice.

## Ready, Aim, Go!

RAG isn’t one architecture; it’s a set of patterns you can plug in and ship. With Meilisearch, you get three practical pillars to build on: **Retrieve**, **Answer**, and **Grow**. **Retrieve** for quick discovery. **Answer** for concise, sourced guidance. **Grow** for speed and stability at scale. Start where you are, keep one path, and keep iterating.

Retrieve and gain: Three RAG use-case patterns you can ship today

Large language models (LLMs) are becoming better at handling larger context windows. But does that mean retrieval-augmented generation (RAG) is obsolete? Not quite. 

Here’s a quick look at what this guide covers:

* How RAG delivers grounded and user-friendly responses through retrieval and generation. 
* The hype surrounding long-context LLM models like Gemini 1.5 Pro or GPT-4.1, which can process thousands of tokens simultaneously.
* The major difference between RAG and long-context as well as the gap between them.
* When to use RAG and long-context LLMs, and what makes one better than the other in different situations. 
* A look at the pros and cons of each, and whether there is a need to use both together.
* How both RAG and long-context LLMs perform in real-world use cases, from AI agents to enterprise knowledge bases.

Let’s find out which approach gives you better, more grounded responses while incurring minimal costs.

## What is retrieval-augmented generation (RAG)?

[Retrieval-augmented generation](https://www.meilisearch.com/blog/what-is-rag) connects information retrieval with LLMs to generate accurate responses. How? By searching external knowledge bases or vector bases for relevant documents. 

RAG provides an LLM with retrieved chunks of external data, providing relevant context and helping it produce the response the user is looking for. 

As a result, RAG reduces the likelihood of AI hallucinations. It’s used in [AI agents](https://www.meilisearch.com/blog/agentic-rag) and real-time workflows that depend on external data.

Next, let’s take a look at how long-context LLMs handle larger context windows without retrieval.

## What is a long-context LLM?

A long-context LLM, as the name suggests, is a large language model specifically designed to handle a much larger context window size than the standard models. The difference is quite staggering, as it can sometimes process even millions of tokens without relying on retrieval.

Modern examples include GPT-4.1, Gemini 2.5 Pro, Claude 4 Opus, and Llama 4 Maverick. They can read entire reports, research papers, or knowledge bases at once, making them ideal for summarization, deep reasoning tasks, and extended document analysis.

Next, let’s compare how these long-context models differ from RAG.

## How does RAG differ from long-context LLMs?

The basic difference you need to understand between RAG and long-context LLMs is that they handle context differently. 

RAG retrieves relevant information from external sources before generation. Long-context LLMs, on the other hand, process all input within a single, long-context window. 

![RAG vs Long-Context LLMs.png](https://unable-actionable-car.media.strapiapp.com/RAG_vs_Long_Context_LL_Ms_cbc72da795.png)

While accuracy and scalability are goals for both approaches, the methods used to achieve them differ. 

If you’re exploring different architectures, our post on [RAG types](https://www.meilisearch.com/blog/rag-types) breaks down each variant with examples. 

Now, let’s see when using one of these is better than the other.

## When should you use RAG over long-context LLMs?

Retrieval-augmented generation is the perfect match when your app relies on external knowledge or dynamic datasets. If you need real-time retrieval and scalability, you can’t go wrong with RAG.

RAG handles changing knowledge bases and keeps latency predictable, minimizing the required number of tokens per query. 

It’s cost-effective and enables domain-specific optimization as well as granular access control for transparent audit trails. 

## When are long-context LLMs a better choice?

The best time to use long-context LLMs is when your data fits inside a single large context window and doesn’t change often. Summarization, reasoning, technical reports, understanding transcripts; they do it all. 

The newer models, such as GPT-4.1, Gemini 2.5 Pro, Claude 4 Opus, and Llama 4 Maverick, push context window sizes past a million tokens and easily handle complex cross-document reasoning. Additionally, these models can handle entire datasets directly, eliminating the need for retrieval pipelines.

As amazing as that sounds, it comes with a significant computational cost. The latency also goes up for larger inputs. 

In short, for static knowledge bases, more extended context exploration, or quick experimentation, long-context LLMs are often the more practical path.

## What are the main advantages of RAG?

RAG gives you all the control and flexibility you need to build faster and minimize costs when developing your system. 

Let’s see what makes RAG special:

1. **Efficient use of resources:** By retrieving only relevant documents, RAG keeps the number of tokens small, reduces costs, and speeds up each query.
2. **Speed:** Thanks to the use of vector bases and embedding models in the retrieval process, the speed of RAG systems is unmatched.
3. **Flexibility and adaptability:** RAG easily integrates with various knowledge bases, requiring no fine-tuning.
4. **Full transparency:** Every answer can point back to its retrieved chunks, so it can easily be traced while maintaining user trust.

Want to see how teams optimize performance? Check out our official guide on [RAG tools](https://www.meilisearch.com/blog/rag-tools).

## What are the main advantages of long-context LLMs?

Long-context LLMs are by far the best option when you need the system to handle large inputs while retaining the context. 

Let’s take a deeper look at their pros:

1. **Thorough understanding:** These models process entire datasets or documents in a single pass, ensuring minimal fragmentation and preserving the meaning.
2. **Exhaustive reasoning:** Long-context LLMs shine in reasoning tasks and can connect ideas spread across long sequences for stronger logical flow.
3. **Simplicity:** There’s no need for external RAG pipelines or vector databases. Just input your text and generate.

Now, it’s time to see the limitations of both RAG and long-context LLMs.

## What are the limitations of RAG?

RAG is the go-to option for accuracy and control, but that doesn’t mean it comes without challenges. Let’s look at some below:

1. **Retrieval is not 100% accurate:** You may sometimes receive poor output quality due to inadequate chunking and embedding models.
2. **Costly maintenance:** Keeping indexes fresh requires ongoing updates to datasets and managing data pipelines. None of this is free or easy.
3. **Experienced prompt engineering skills needed:** RAG depends on well-structured prompts to merge retrieved chunks without confusing the LLM.
4. **Latency changes too easily:** Each retrieval step adds milliseconds to the response time. When you estimate this at scale, it adds up to a significant amount of latency. 

These factors make RAG more complex to deploy and maintain than long-context LLMs, which is why small teams tend to avoid it.

## What are the limitations of long-context LLMs?

Let’s now explore the key drawbacks to long-context LLMs:

1. **Excessive resource use:** When you want to process millions of tokens, you need more computational resources.
2. **Scaling isn’t easy:** It’s not straightforward to scale long-context LLMs, as latency and response times increase with added context length.
3. **Lost context:** You can lose important details, especially in extremely long inputs or mixed datasets.
4. **Data security:** The larger the prompt, the greater the risk of prompt injection, which can lead to data leakage and compromise enterprise security.

Even advanced models face these issues when pushed to their context window size limits.

Next, we’ll examine how both methods perform using real-world benchmarks.

## How do RAG and long-context LLMs perform on benchmarks?

Numerous qualified studies offer nuanced insights into how each approach performs. 

Let’s look at some of the most recent papers that discuss this in detail.

[‘Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach’](https://arxiv.org/abs/2407.16833) (Li et al., 2024) found that long‐context LLMs consistently outperformed RAG when ample resources were available, but RAG was undoubtedly far more cost-efficient.

Another study, [‘LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs – No Silver Bullet for LC or RAG Routing’](https://arxiv.org/abs/2502.09977) (Li et al., 2025), observed that there was no one-size-fits-all solution. The choice ultimately depends on the model size, task type, and other factors surrounding context length and retrieval quality.

Long-context models shine for long, static documents. On the other hand, RAG performs better when datasets are dynamic or diverse. 

## How do RAG and long-context LLMs impact costs?

It’s no secret that RAG offers lower overall costs for setup, while long-context LLMs incur a higher token and infrastructure cost at scale: 

* **Unique setup cost:** With RAG, the focus is on indexing, embedding, and retrieval. For LLMs, the focus is on a premium API or GPUs that support large context windows. 
* **Inference costs:** The inference cost for RAG is much lower since it only sends relevant chunks to the LLM. This way, it minimizes the token cost and usage. On the other hand, LLMs that are processing 200k+ tokens per request might even cost up to $20 per call. 
* **Scaling and maintenance costs:** RAG pipelines require ongoing index upkeep and retrieval tuning, but base LLM token consumption stays low. Long-context solutions scale poorly with more users or larger documents because each call incurs increased costs and latency.
* **Operational charges to consider:** Enterprises with strict cost or latency targets often choose RAG since it better suits their needs. For long-context LLMs, hidden costs like GPU usage, memory capacity, and slower responses become an uninvited guest that you don’t enjoy dealing with.

## What are real-world use cases for RAG?

RAG is ideal for domains that deal with rapidly changing contexts. These include:

1. **Enterprise knowledge systems:** Companies use RAG to consolidate all their internal data from wikis, emails, and CRMs into a unified knowledge base. AI assistants can then use this knowledge base to deliver relevant answers.
2. **Intelligent search engines:** RAG serves as the backbone for intelligent search engines. Thanks to vector databases and [hybrid retrieval](https://www.meilisearch.com/blog/hybrid-search), manual lookup time can be significantly reduced.
3. **Dynamic document management:** In fast-moving domains such as finance or healthcare, RAG enables real-time updates without requiring retraining of the AI model. This way, the output always reflects the latest updates.

## What are real-world use cases for long-context LLMs?

Long-context LLMs excel at handling tasks that require large inputs: 

1. **Summarization and analysis:** Models can process entire reports, transcripts, or books. They provide all the information you need from these sources, whether summaries, transcripts, or answers to questions that require reasoning.
2. **Legal and compliance review:** Long-context LLMs are a go-to choice for enterprises that need to review legal contracts in their entirety. They also help in flagging inaccurate info and comparing clauses without losing context.
3. **Academic and technical research:** Long-context systems can explore long datasets, scientific papers, or arXiv collections to identify relevant information and trends across different fields.

It’s now time to explain why LLMs’ growing capabilities are starting to challenge traditional RAG pipelines.

## Why are long-context LLMs challenging traditional RAG pipelines?

All these recent advances in context window size are reshaping how developers think about retrieval. 

Models that can handle over a million tokens reduce reliance on RAG pipelines and vector databases. For smaller or static datasets, long-context LLMs provide faster and simpler results without requiring any retrieval infrastructure. 

However, RAG remains undefeated when it comes to dynamic or real-time data retrieval, offering both data freshness and scalability.

Let’s see how to choose between these two approaches effectively.

## How to choose between RAG and long-context LLMs?

Choosing between RAG and long-context LLMs depends on your data volume, update frequency, and performance goals. Each approach can meet a distinct need:

1. **Project scope:** If the project is small or static, such as a policy chat or document summary, the long-context models are way easier to deploy. For larger projects that need real and ongoing reasoning, RAG is what you want.
2. **Data type and freshness:** If your system relies on constantly changing or real-time content (such as support tickets, logs, or news) RAG ensures the results remain current and up-to-date. 
3. **Scalability and cost:** RAG minimizes token usage, so it’s more cost-effective for enterprise-scale workflows. Long-context LLMs consume more tokens as the context length increases, resulting in increased latency and computational resources.
4. **Compliance and control:** When there can be no compromise with audit trails and explainability, such as in healthcare or finance, RAG’s indexed architecture provides audit-ready outputs. 

In short, RAG suits high-volume, dynamic ecosystems, while long-context LLMs excel in reasoning-intensive domains.

## How does retrieval work in RAG vs. long-context LLMs?

In RAG, retrieval happens before the model generates a reply. A retriever searches your knowledge base to find the most relevant documents, then passes the retrieved information to the large language model for response generation.

Tools like Meilisearch make this step even faster and production-ready. Meilisearch indexes content and performs hybrid retrieval (keyword + vector) with built-in filters, scoring, and reranking. This gives grounded and citable snippets that aren’t just accurate but also easy to track. It’s transparent and quick to update or scale through Meilisearch’s simple <code><em>/chat</em></code> API.

Long-context LLMs have no retrieval step at all. They rely entirely on what’s packed inside the prompt. 

While this works for short, static data, it becomes costly and less fresh as context windows grow. Additionally, there’s no automatic refresh or audit trails, so it is impossible to trace the origin of the response.

## Can RAG and long-context LLMs be combined?

Yes, and it’s often the best of both worlds. Hybrid setups use RAG to fetch relevant documents from a knowledge base, then feed them into a long-context LLM. Then comes the reasoning across the entire input combined.

This hybrid approach strikes the perfect balance between recall and reasoning. RAG ensures the prompts are lean and cost-effective, while the long-context LLMs handle the analysis and reasoning the user requires.

Meilisearch handles the retrieval layer in such systems: indexing, filtering, and returning grounded, high-quality snippets before the model processes them.

If you’re into experimenting with model correction or hybrid routing, explore [our guide on corrective RAG](https://www.meilisearch.com/blog/corrective-rag) for practical strategies.

## Bringing it together: choosing between RAG and long-context LLMs

Both RAG and long-context LLMs push the limits of how large language models use data, but their goals differ significantly from one another. 

RAG is all about accuracy and efficiency, but long-context LLMs excel in reasoning and retaining context. 

The best foundation you can build for any system is to combine both of them.

RAG vs. long-context LLMs: A side-by-side comparison

Elasticsearch vs Pinecone (vs Meilisearch): Which search solution actually fits your needs in 2025?

RAG (retrieval-augmented generation) indexing determines how well an AI system grounds its answers in relevant information. It enables the system to quickly locate relevant documents for a search query. 

Developing RAG indexing involves building a pipeline with the following steps: 

* Data collection 
* Meaningful chunking
* Metadata addition 
* Embedding
* Storage in a vector index

Good indexing reduces AI hallucinations and improves relevance across both structured and unstructured data.

RAG indexing strategies, such as hybrid, hierarchical, domain-specific, and graph-based, adapt to the structure of the knowledge base and the retrieval system's goals.

Issues caused by scale, chunk size, and metadata quality can be handled with clean data, consistent embeddings, and regular updates.

Factors such as speed, cost, integration needs, and dataset size are important considerations when selecting a database.

RAG indexing differs from keyword search by using embeddings rather than exact term matches.

Future RAG developments are moving toward hybrid retrieval methods, graph-enhanced approaches, and RAPTOR-style hierarchical indexing.

## What is RAG indexing?

RAG indexing is the process by which a [RAG system](https://www.meilisearch.com/blog/what-is-rag) organizes and prepares data so that, when prompted by a user query, the correct information can be easily retrieved. 

It takes the documents, chunks them into smaller pieces, creates vector representations of the chunks, and stores them in a special index so the system can quickly find them when needed. 

Without indexing, a RAG system would not know how to connect a user’s question to the relevant context. The index serves as a map of the knowledge base, enabling the retriever to quickly locate the most relevant text without having to search the entire knowledge base. 

That retrieved information is then passed to the LLM (large language model) to generate an appropriate answer to the query.

## How does RAG indexing work?

RAG indexing organizes the source data so that the RAG system can quickly find and return the most relevant information chunk. It converts raw documents into searchable vector embeddings and stores them in a vector database, enabling fast similarity searches. 

![How RAG Indexing Works.png](https://unable-actionable-car.media.strapiapp.com/How_RAG_Indexing_Works_2b7e28b7a3.png)

Here are the main stages of RAG indexing:

1. **Data collection:** RAG indexing begins by collecting data from various sources. These can be external PDFs, blog articles, an FAQ spreadsheet, etc. 
2. **Cleaning the text:** Next, the collected data is processed. Data cleaning may involve removing headers, fixing unparseable symbols, removing extra spaces, and so on. 
3. **Document chunking:** Long documents are typically split into smaller chunks to ensure the text is within the LLM’s context window. The chunks should be large enough to retain context but small enough to be processed efficiently. For instance, instead of treating a 40-page policy manual as one giant block of text, you can break it into hundreds of smaller sections.
4. **Tagging with metadata:** Next, each chunk is tagged with metadata for quick filtering. The metadata are relevant fields such as title, data source, topic, category, or date. For example, tagging a chunk from a refund policy document with ‘topic: refunds' allows the system to instantly find it when a user asks a related question.
5. **Embedding:** The chunks are then converted into [vector embeddings](https://www.meilisearch.com/blog/what-are-vector-embeddings) to ensure similar chunks are placed close to each other. For example, we can expect chunks on ‘refund rules’ and ‘return policy’ to be close because they would share similar vectors.
6. **Vector storage:** Finally, these vectors and their metadata tags are stored in a [vector database](https://www.meilisearch.com/blog/what-is-a-vector-database). Some common vector databases are Pinecone, Milvus, FAISS, and Weaviate.

## Why is indexing important in RAG?

RAG indexing makes RAG systems more accurate by organizing information so the LLM can quickly find and use the right content when answering a question. 

Here are some of its benefits:

* **Speed:** Without indexing, the system would have to scan every document in its entirety whenever someone asks a question. Indexing stores precomputed embeddings, so the system can instantly search and retrieve relevant chunks without having to search from scratch.
* **Relevance:** Because chunks are embedded and tagged with metadata, the algorithm can match a user’s query to the most meaningful pieces of text. This precise retrieval enhances the relevance of answers.
* **Accuracy:** Indexing preserves context and meaning. Since the retrieval step is cleaner and more targeted, the final answer generated is better grounded in correct information.
* **Scalability:** Vector databases and indexing techniques can elegantly handle large data volumes. Therefore, it is possible to update or expand the knowledge base over time without affecting the RAG system's performance. 

## What are the main RAG indexing strategies?

Different indexing strategies fit different [types of RAG](https://www.meilisearch.com/blog/rag-types). Picking the right one mainly depends on the content you want to search through. 

Your indexing strategy can also impact the relevance and performance of the RAG. 

Here are several common RAG indexing strategies and when you would use them:

### 1. Hierarchical indexing

Hierarchical indexing involves organizing content at multiple levels. The text resource is broken down from a document into sections, then paragraphs, and finally chunks. This strategy respects a document's structure and does not randomly create chunks. 

For example, a legal contract might first be identified by section (e.g., ‘Termination Clause’) then by the exact paragraph that answers the user query. 

You can use this technique when your documents, such as manuals or textbooks, are long and logically organized. It reduces noise, improves relevance, and allows the retriever to first narrow down the section before searching in-depth.


### 2. Hybrid indexing

Hybrid indexing combines keyword-based search (e.g., BM25) with vector search, similar to [hybrid search](https://www.meilisearch.com/blog/hybrid-search). The AI system uses both approaches to improve its search accuracy. 

For example, when searching for ‘how to fix my damaged electric kettle,’ a keyword search identifies documents containing those exact terms. A vector search retrieves related content to help fix damaged electrical appliances. 

This strategy is ideal when you want precision and coverage. It is also useful when migrating from classic search tools to [RAG tools](https://www.meilisearch.com/blog/rag-tools) without losing keyword search performance.

### 3. Time-based Indexing

Time-based indexing is used to keep track of information that changes over time. Each document or section is stored with a date label, so the AI system knows which are the most recent. 

This strategy is useful for materials that are frequently updated, such as financial reports, company guidelines, or news articles. 

### 4. Multi-representation indexing

Multi-representation indexing stores multiple vector embeddings for the same piece of text within a single retrieval system. Each embedding focuses on a different aspect of the content. One might capture the overall idea, another might emphasize technical language. 

When a user types a search query, it is processed across all versions. 

This method works well in areas where information can be interpreted in several ways. It is also useful when precision is essential and the language used in your documents is specialized.

### 5. Domain indexing

Domain indexing is designed to match the terminology of a particular field. For example, in medical data, the system might use drug names or symptom categories to label chunks. In software documentation, the index could be organized by API endpoints or code use cases. 

This approach works best when your material follows clear patterns and uses consistent terms. 

It improves search relevance because the index is built around how professionals in that field naturally search for information, rather than treating all text the same.


### 6. Graph-enhanced indexing

Graph-enhanced indexing is a strategy that links text chunks (called nodes) using relationships (called edges). Nodes could include topics, categories, citations, and related details. Graphs allow you to quickly see how multiple chunks are connected. 

Use this strategy in situations when relationships are more important than similarity. It is also ideal for complex domains, such as legal matters or academic research, that involve interconnected concepts.

## What are common challenges in RAG indexing?

RAG indexing involves choices that affect speed, accuracy, and long-term maintenance. 

Here are some common challenges and how you can overcome them:

* **Handling large datasets:** When you are working with thousands of documents (or millions of chunks) indexing and searching can be incredibly slow. Storage costs also go up. A good solution would be to use sharding, compress embeddings, or remove low-value content rather than indexing everything.
* **Picking the right chunk size:** Chunks that are too long can provide the wrong context, and chunks that are too short can lose their meaning. To find the right balance, test with different token lengths (e.g., 200, 400, 600) and evaluate their retrieval quality before deciding on a chunk size.
* **Keeping embeddings consistent:** If you change the embedding model, older vectors may no longer match the new ones. That can lead to bad retrieval. To avoid this, version your embeddings and re-embed only affected documents when the model changes.
* **Stress in managing metadata:** Messy or inconsistent metadata makes filtering useless. You can fix this by defining an explicit schema (e.g., source, date, format, or access level) from the start and enforcing it during ingestion.

## What are the best practices for RAG indexing pipelines?

The quality of your chunks, embeddings, and metadata directly shapes what the AI model can find and use. Here are some best practices for building and maintaining RAG indexing workflows:

* **Always start with clean and meaningful data:** Never dump everything into the index. Remove duplicates and filter out low-value text, such as headers, navigation menus, or disclaimers. Cleaner input means cleaner retrieval and fewer irrelevant matches later.
* **Chunk by meaning, not by fixed length:** Instead of automatically slicing text every 300 tokens, break it around natural boundaries. This includes headings, paragraphs, bullet lists, or API endpoints. It keeps context intact and reduces confusion during retrieval.
* **Keep embeddings and models aligned:** If you update your embedding model or retriever, do not leave the index behind. Re-embed over time or version your vectors so that the old and new chunks stay compatible.
* **Always add metadata:** Good tags make filtering more powerful. Try adding tags such as source, document type, date, section, or access level. This helps the system narrow results quickly and stay grounded in the proper context.
* **Use smart retrieval tricks:** Hybrid search (combining keywords and vectors), light reranking, and query rewriting for typos boost recall without flooding the results with junk.
* **Monitor and refresh the index:** Always track retrieval quality, stale documents, and storage bloat. In addition, replace outdated content and reduce noise instead of letting the index grow unchecked.

### How Meilisearch helps

Meilisearch supports vector search and hybrid querying, which makes it a good fit for RAG indexing pipelines. You can store your text chunks and their embeddings directly in the index, instead of using a separate vector database. That means your indexing step can include both chunking and attaching embeddings.

Meilisearch also lets you filter by metadata such as source, tags, or date, which keeps retrieval grounded and avoids random matches. 

Since Meilisearch handles both semantic search and keyword search, you can combine exact terms with vector similarity. This is perfect when your users mix natural phrasing with domain-specific words.

Another bonus is speed! Indexing is fast, and updating entries doesn’t require a complete rebuild. That helps when documents change or you need to refresh embeddings. In a RAG setup, Meilisearch acts as a searchable store for meaning and structure without overcomplicating the pipeline.

## When should you update a RAG index?

You should update the RAG index whenever the data, documents, or the embedding model change in a way that could affect retrieval quality.

Suppose you add new documents, update policies, change pricing, publish fresh blog posts, or remove outdated material. The index needs to be refreshed so the AI system does not return inaccurate answers. 

The same applies if the embedding model gets upgraded. Old vectors will not match new ones, so re-embedding is needed. 

In fast-changing domains, updates should be scheduled daily or weekly. Monthly or incremental updates may be enough for slower-moving content. 

A good rule of thumb is that if a human wants the new information reflected in the answers, the index should be updated.

## How can you evaluate RAG indexing performance?

You can assess RAG indexing by measuring how fast the system retrieves results, how relevant they are, and whether users find the answers helpful. 

* **Speed:** Slow searches usually indicate a poorly structured index. 
* **Semantic accuracy:** A good question to ask here is, “Are the top chunks related to the query, or just loosely similar?” You can answer this with small human-reviewed samples or automated relevance checks. If you are working with structured data (such as product tables or policy fields) and unstructured data (such as PDFs or help articles), make sure your index handles both consistently.
* **User satisfaction:** Track follow-up questions, unanswered queries, and user feedback to identify areas for improvement. For more structured testing, you can use evaluation tools or custom scripts that measure how often your system retrieves the correct results. If retrieval feels slow or unreliable, your indexing pipeline probably needs fine-tuning, better chunking strategies, or fresher embeddings.

## What are the most popular vector stores for RAG indexing?

Some of the most popular vector stores (or vector-backed retrievers) used in RAG pipelines are Meilisearch (with its vector support), Pinecone, Weaviate, Chroma, Milvus, Qdrant, and FAISS (or pgvector).

* **Meilisearch:** Though not a traditional vector database, you can use it as a vector-backed retriever by storing embeddings alongside documents. It is excellent when you want a unified search layer (both keyword and vector) without managing a separate vector store. Choose Meilisearch if your dataset is moderate and you value simplicity and lightweight operations.
* **Pinecone:** Excellent if you do not want to deal with servers or scaling issues. It is fully managed, fast, and built for production so that you can focus on retrieval, not infrastructure.
* **Weaviate:** Open source and flexible. It handles hybrid search, filtering, schemas, and even relationships between data. It’s a good fit when you care about meaning and structure, not just raw embeddings.
* **Chroma:** Simple and developer-friendly (built with Python users in mind). It is often used in quick RAG prototypes or smaller RAG applications. If you are experimenting or do not have many vectors, Chroma is a good vector store to use.
* **Milvus:** Milvus is designed for scale. It is open source and works well for storing and querying millions of embeddings across machines. You should use it when performance and control matter more than convenience.

### How to choose a vector DB for RAG indexing

When building a RAG system, your vector database is the backbone of the retrieval system. It needs to store embeddings efficiently and return relevant results quickly. The goal is not just picking a popular tool, but choosing one that fits how you plan to use it:

* **Speed:** If your app needs quick responses, latency matters a lot. A good vector database should return similar results fast, even when working with many embeddings.
* **Scalability:** Your data might start small, but it will not stay that way. The database you choose should handle growth without turning into a maintenance nightmare. If you expect to move from thousands to millions of vectors, choose a tool that can scale horizontally without losing performance.
* **Integration:** You do not want to spend hours wiring things together. Choose a database that works efficiently with your infrastructure. Clean APIs and SDK support make the development process smoother.
* **Cost:** Some options are fully managed and save you time, but they can get pricey as usage grows. Open-source tools are cheaper to run but require more hands-on setup and maintenance. It is all about balancing convenience with budget.

Let’s see how RAG indexing differs from traditional search indexing.

## How does RAG indexing differ from traditional search indexing?

RAG indexing and traditional search indexing seem similar on the surface, but they work in very different ways. 

Traditional indexing is all about keywords. 

RAG indexing, on the other hand, focuses on semantic meaning. Instead of relying solely on words, it uses embeddings to capture context and retrieve relevant chunks based on semantics.

![RAG Indexing vs. Traditional Search Indexing.png](https://unable-actionable-car.media.strapiapp.com/RAG_Indexing_vs_Traditional_Search_Indexing_6b6b7f9ad7.png)

RAG indexing shines when users do not use the exact wording found in the source documents. Examples are conversational queries, domain jargon, or multilingual content. 

Traditional indexing is still a good option when speed, exact matches, and lightweight infrastructure are priorities. Examples are documentation sites or e-commerce search results.

## What are future trends in RAG indexing?

RAG indexing is evolving rapidly, and the next wave involves combining smarter context handling with more effective retrieval strategies:

* **Graph-powered retrieval:** Instead of treating documents as isolated chunks, newer trends link concepts using knowledge graphs. This approach captures relationships across topics and returns more connected answers.
* **RAPTOR-style hierarchical chunking:** Approaches inspired by RAPTOR break content into layers (small chunks are broken for precision, and larger summaries are broken for broader context). This ensures that information retrieval can adapt to the query’s depth.
* **Hybrid retrieval pipelines:** Mixing keyword search, semantic vectors, and metadata filters is becoming the norm. This combination boosts accuracy and speed without relying on a single retrieval process.

## Index smarter, answer sharper

Indexing is a critical component of a good RAG system. When the index is well-chunked and backed by good embeddings, your model will efficiently retrieve the correct information.

However, a smart index is not something you set and forget. As new content springs up, the index should evolve too. Even minor improvements (such as better metadata, refreshed embeddings, or reorganized chunks) can noticeably improve the retrieval accuracy. 

At the end of the day, sharper answers do not come from luck or bigger models. They come from indexing that is done with intent.  

RAG indexing: Structure and evaluate for grounded LLM answers

Algolia pricing guide: Is it worth the cost in October 2025?

Welcome to our new roundup of product updates, community news, and everything happening across the Meilisearch ecosystem.

This October was big: we wrapped up [**Launch Week**](https://www.meilisearch.com/launch-week-q3-2025?utm_campaign=238324931-Monthly%20Newsletter&utm_source=hs_email&utm_medium=email&_hsenc=p2ANqtz-8neQp3zIW5wCVhJGcT4mmJ79gYs9F6CC6SnoLDy1i_-B3FDbW6rum2QjF65Mqw7iaNbZSC), were featured in the Product Hunt top products newsletter, and hit a few other exciting milestones along the way. Let’s dive in 👇

---

## 🚀 Product updates: what’s new at Meilisearch

**Another [Launch Week](https://www.meilisearch.com/launch-week-q3-2025) is in the books!** From conversational AI and multi-modal search to personalization and a new pricing model - we shipped **five major updates in just five days**:

- [**Meilisearch Chat**](https://www.meilisearch.com/blog/meilisearch-chat)
- [**Advanced geosearch**](https://www.meilisearch.com/docs/learn/filtering_and_sorting/geosearch)
- [**Enhanced multi-modal search**](https://www.meilisearch.com/docs/learn/ai_powered_search/image_search_with_multimodal_embeddings)
- [**Search personalization**](https://www.meilisearch.com/docs/learn/personalization/search_personalization)
- [**Resource-based pricing**](https://www.meilisearch.com/blog/resource-based-pricing)

Explore the Launch Week:

🔗 [Explore each release, day by day.](https://www.meilisearch.com/launch-week-q3-2025)

🔗 [Launch Week recap blog](https://www.meilisearch.com/blog/launch-week-2).

---

### ⚡ AI Search experience, out of the box

We’ve made it easier than ever to experience the power of **AI Search** - no setup, no data required. With just one click, you can explore a built-in mock dataset and see real-time progress feedback as the search runs:

![](https://hs-25945010.f.hubspotemail-eu1.net/hub/25945010/hubfs/AI%20search%20mock%20data.gif?upscale=true&width=1120&upscale=true&name=AI%20search%20mock%20data.gif)

---

### ☁️ We are available on AWS marketplace

We’re thrilled to announce that **Meilisearch is now live on the [Amazon Web Services (AWS)](https://aws.amazon.com/marketplace/pp/prodview-7ougkqatzyr7i)** Marketplace! 😎 AWS has been an incredible partner, and this makes it even easier for customers to deploy Meilisearch directly.

👉 Learn more in this [blog post.](https://www.meilisearch.com/blog/aws-marketplace)

---

### 📊 Cloud UI - billing update

We’ve clarified how project metrics are displayed in the Cloud UI. This also includes users of free trial as well paid resource-based pricing model users:

- **Transparent project view:** project cards will now display **real usage data**, not your peak billing values.
- **More visibility:** both resource-based and free-trial projects will now show current **searches and documents** metrics directly in the dashboard.

![](https://hs-25945010.f.hubspotemail-eu1.net/hub/25945010/hubfs/image%20(47).png)

---

### 🚧 Coming soon: search analytics V2

We’ve heard your feedback and we're now in the final stretch before releasing an upgraded version of Search Analytics. Stay tuned for a deeper, more actionable view of your search performance.

---

## Community section & ecosystem news:

### Product Hunt feature:

**Meilisearch Chat** was featured in the [**Product Hunt Daily**](https://www.producthunt.com/newsletters/archive/44612-videos-that-don-t-suck) newsletter – reaching over a million readers! Huge thanks to our open-source community for the love and excitement around conversational AI built on your own data. 💜

### 🔥 Fireship x Meilisearch:

We were also featured in the latest [**Fireship**](https://www.youtube.com/watch) video covering **OpenAI’s** new browser, Atlas! If you haven’t tried Meilisearch yet, here’s your sign 👀 - there’s even a little code surprise in the video.

→ Watch the video [here](https://www.youtube.com/watch?v=5uSboan45Zg).

### 💡 Customer highlights:

See what users are saying about Meilisearch:

*"Since we redesigned our Program Finder and implemented Meilisearch, our conversions have more than doubled. We are so very happy with Meilisearch."*

Gabriela Sa Teles, Assistant Director of Digital Services at the **University of Missouri-Kansas City**

## Tips & resources:

**We published a new guide:** [Optimize Indexing Performance with Batch Statistics](https://www.meilisearch.com/docs/learn/indexing/optimize_indexing_performance)

This guide serves to help you use *progressTrace* to analyze and resolve indexing bottlenecks in Meilisearch.

---

## 🏢 Company news

In October, we held our regular company offsite where we used the time to refine our long-term vision. During the offsite, we also built this multimodal demo on a massive dataset:

👉 [check it our here.](https://flickr.meilisearch.com/)

Our CEO Quentin also wrote a [post](http://linkedin.com/posts/quentin-de-quelen-4241a865_we-ran-a-small-experiment-during-our-offsite-activity-7392154072931389441-z62H) describing the entire stack, if you'd like to learn more about it.

💼 **We’re hiring!**

Meilisearch is expanding, and we’re opening  several new roles across teams, with more to come!

If you know someone who’d be a great fit - or if you’re curious about what’s next for us 👉 keep an eye on our [**Careers page.**](https://www.meilisearch.com/careers)

![45C6AD8A-89DA-49B6-81F3-7C109EB6B6EF_1_102_o.jpeg.webp](https://unable-actionable-car.media.strapiapp.com/45_C6_AD_8_A_89_DA_49_B6_81_F3_7_C109_EB_6_B6_EF_1_102_o_jpeg_326f23623c.webp)

--- 

Receive this updates in your inbox by subscribing to our [monthly newsletter](https://dub.sh/meili-newsletter). To learn more about Meilisearch's future and help shape it, take a look at our [roadmap](https://roadmap.meilisearch.com/) and participate in our [Product Discussions](https://github.com/orgs/meilisearch/discussions).

For anything else, join our developers community on [Discord](https://dub.sh/meili-discord).

Meilisearch October updates

Most CTOs assume that implementing search is a quick, done-in-a-sprint kind of task. Something their dev team can figure out in a week. 

But the truth couldn’t be more different. According to our survey, more than half (55%) of development teams require **three weeks or more** to roll out a search solution. 

And they are the lucky ones. For some, it can take **two or more months**. 

This begs the question: **why is something as vital as search still so hard to get right?**

We asked over 100 CTOs and technical CEOs to share what went wrong when implementing search and what they wish vendors would do differently. Their answer reveals common pitfalls and insights that can help you avoid the same costly mistakes. 

Let’s dive into what they shared and how it applies to your own search initiatives. 

## Key insights (TL;DR)

* 86% of respondents called search **‘very important’ and ‘critical’ to their product’s user experience** across industries like e-commerce, fintech, healthtech, edtech, etc. 
* 55% of development teams spent **three or more weeks** implementing search. 17% struggled for **two months or longer**. 
* The biggest blockers aren’t just bugs – they’re structural. The top three: **inflexible tools (61%), broken documentation (47%), and a lack of expertise (34%).**
* **Less than 1%** of respondents said integrating search was easy for them.
* During the implementation phase, the majority of teams turned to **vendor documentation (55%)** and **support and customer success teams (49%)** for help, while **20%** relied on AI assistants like **ChatGPT**.
* **Fast response time (71%), accurate results (51%)**, and the **ability to handle typos or fuzzy matching (50%)** are the top three features teams expect in their search experiences.

## Insight #1: Most teams spent weeks – or months – on search implementation

According to our survey, only 15% of teams implemented search in under a week, while **55% took more than three weeks** to do so. 

For 17% of development teams, the process stretched to **at least two months**, resulting in a significant amount of wasted time. 

![How long did it take to integrate the search functionality_.png](https://unable-actionable-car.media.strapiapp.com/How_long_did_it_take_to_integrate_the_search_functionality_1d72bf913b.png)

These results reflect a consistent trend: integrating search has become a slow, resource-draining process for most teams. 

In the open-ended answer section of our survey, one respondent even said, “Plan for double the time to implement.” 

Users expect each search experience to be fast, accurate, and typo-tolerant by default. Giants like Google and Amazon have set high standards. Yet behind the scenes, devs are investing massive amounts of time just to get the basics working.

From our perspective at Meilisearch, that’s a costly baseline. 

## Insight #2: Search fails at the structural level, not just in the code

**Less than 1%** of respondents said that their search integration went smoothly.

When asked what slowed them down, they highlighted three most common issues: 

1. **Technical limitations (61%):** Inflexible infrastructure, clunky APIs, or the wrong tools often force teams to rethink and rebuild key systems. 
2. **Poor documentation (47%):** Missing or outdated documentation adds friction and guesswork into the process.
3. **Lack of expertise (34%):** Many teams don’t have the experience to successfully implement search, leading to false starts and much trial and error. 

![What were the biggest challenges your team faced during the search integration process.png](https://unable-actionable-car.media.strapiapp.com/What_were_the_biggest_challenges_your_team_faced_during_the_search_integration_process_f458e8105f.png)

While bugs and integration hiccups can cause short-term delays, the real problem comes from **structural issues**. 

This means the architecture of the product wasn’t built with search in mind, the documentation is more of a hindrance than a help, and teams lack key skill sets to implement search properly. 

The result is search that ships late, costs more, and becomes harder to maintain with every iteration.

## Insight #3: When teams need help, the docs don’t always deliver

When search implementation gets tough – as it often does – what do teams do? They look for support. 

![What resources did you rely on for integrating search.png](https://unable-actionable-car.media.strapiapp.com/What_resources_did_you_rely_on_for_integrating_search_75df6f93ba.png)

The **most common first stop is vendor documentation (55%)**, which ironically is the second biggest roadblock to implementing search, as noted in our previous insight. 

Often, documentation is incomplete, outdated, or simply hard to navigate. 

So, if the most relied-on source of guidance is also a leading pain point, it’s no wonder people get stuck for weeks. 

Respondents also relied on vendor support or customer success teams (49%), online tutorials (48%), and peers or communities (e.g., Discord) (45%).

Almost one in five developer teams (19%) turned to AI tools, such as ChatGPT or Copilot, for help – a clear sign that AI tools are becoming an integral part of the troubleshooting stack. 

Our survey findings show that **support is fragmented.** Developers chase answers across multiple sources, wasting time and energy as deadlines rapidly approach.

## Insight #4: What developers really want from their search tools

Aside from the challenges, our team also asked technical leaders what they wished their search tools had done better. 

Their answers focused on ways to save time, reduce confusion, and avoid frustration. 

![A graphic listing the most common responses from developers working on integrating a search functionality into their products.](https://unable-actionable-car.media.strapiapp.com/What_developers_want_from_their_tools_489451aa44.png)

### Better, clearer documentation 

Teams want docs that go beyond the basics, with real-world examples and easy-to-follow setup steps to speed up integration. 


### Simpler, unified APIs

A common frustration is having to integrate multiple endpoints, so leaders are requesting unified APIs. 

“*Provide a single, well-documented API that can pull from multiple sources (documents, emails, chats, etc.) with consistent formatting,*” one respondent said.  


### Seamless integration tooling

Teams want builders that work with popular frameworks and data pipelines, without spending too many hours on setup. 

“*Make sure you find a platform that integrates well with other software development *[tools],” was a recurring sentiment among respondents. 


### Flexible customization and metadata control

Search isn’t a one-size-fits-all, so teams want more control over their ranking, filtering, and metadata display. 

One respondent said: “*Offering customizable filters and permission controls would help teams tailor search to their specific workflows.*” 

Respondents aren’t asking for the impossible. The idea is to make search implementation more straightforward, especially for teams working in fast-paced industries. 

That’s why, at Meilisearch, we continually update our documentation, prioritizing a unified and straightforward API that anyone can understand. 


## Survey methodology and limitations

Our survey was conducted in July 2025 using SurveyMonkey’s paid Audience panel. 

Respondents were decision-makers – CTOs, technical founders, or equivalent roles – at US-based software companies across all industries and company sizes. 

To qualify, respondents had to pass two screening questions: one to confirm their technical leadership role and another to verify their experience with implementing search functionality. 

This ensured we got answers from those with practical experience on the subject.

The survey included 11 questions in total (2 screening, 9 core), and we received 119 qualified responses. You can find complete data in [this spreadsheet](https://docs.google.com/spreadsheets/d/1Q1Z0brmX1AilNnbW5PCORSqUCCoAXGyN7TFZbLuSGvU/edit?gid=1781222527#gid=1781222527).

As with any data study, there are constraints. Responses may not fully represent large enterprises or heavily regulated industries, where search implementation challenges may differ.

Furthermore, the respondents were compensated by the SurveyMonkey platform for their participation, which may have introduced bias. 

Finally, our mix of multiple-choice and open-ended questions provided quantitative and qualitative data, but may not have captured every nuance of the implementation process. 


## Search doesn’t have to be hard

The data paints a clear picture: search is needlessly complicated. Most teams spend weeks – even months – just to set up the basics, bogged down with technical hurdles and unclear guidelines that don’t meet real-world needs. 

Technical leaders want vendors to go the extra mile, and that means offering simpler APIs, better documentation, and faster setup times. 

In short, they want tools that respect their time and scale with their needs. 



Meilisearch latest news and company updates