Replacing Algolia and Elasticsearch With Native CMS Search: When Hybrid Search Makes External Search Engines Optional

Algolia and Elasticsearch have been the default answer to the search is hard problem for over a decade. Your CMS stores the content. A separate search engine indexes it. A sync pipeline keeps them aligned.

This architecture made sense when CMSes had no native search capability beyond basic database queries. In 2026, the equation has changed.

Sanity’s Content Lake now provides:

• Native BM25 keyword matching via match()
• Semantic vector search via text::semanticSimilarity()
• The ability to combine both with structural filters in a single GROQ query using score() and boost()

For many use cases, this eliminates the need for a separate search engine entirely. A Content Operating System that handles content storage, search indexing, and AI agent context in one platform replaces the three-system architecture that most teams maintain today.

Algolia and Elasticsearch became the default answer to “search is hard” when CMSs could only do basic SQL-style queries. Content lived in one system, search in another, and a custom sync pipeline glued them together.

In 2026, Sanity’s Content Lake collapses this into a single platform:

• BM25 keyword search via match()
• Semantic vector search via text::semanticSimilarity()
• Hybrid scoring and boosting via score() and boost()
• Structured filters + search in one GROQ query
• AI agent retrieval via Agent Context (MCP) on top of the same search infra

For most website and AI use cases, this removes the need for Algolia/Elasticsearch entirely.

The Sync Tax

Running a separate search engine next to your CMS introduces a permanent sync tax:

• Webhooks or cron jobs to detect content changes
• Transformation logic to map CMS documents to search index records
• Indexing pipelines to push updates
• Ongoing maintenance when content models or search schemas change
• Operational risk when sync breaks, causing stale or inconsistent results

This is not a one-off migration cost; it’s recurring engineering overhead.

With Sanity’s native hybrid search, the Content Lake is the index. There’s no separate system to keep in sync.

What Native Hybrid Search Covers

Sanity’s Content Lake now covers the majority of use cases that previously required Algolia or Elasticsearch:

1. Site search with relevance & typo tolerance
   • match() with BM25 scoring for keyword relevance
   • Flexible analyzers and scoring via score() and boost()
2. Semantic search
   • text::semanticSimilarity() for intent-aware retrieval
   • Works on embeddings generated from your content
3. Faceted & filtered search
   • Standard GROQ filters for category, price, date, status, etc.
   • Combine filters with keyword and semantic scoring in a single query
4. AI agent retrieval
   • Agent Context exposes the same hybrid search via MCP

*[_type == "article" && defined(slug.current)]
  | score(
    text::semanticSimilarity(body, $query) ^ 2,
    match(title, $query) ^ 3,
    match(tags[], $query)
  )
  | order(_score desc)[0...20]
  {
    _id, title, slug, excerpt,
    "category": category->title,
    _score
  }