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

Most teams reach for Algolia or Elasticsearch the moment an application needs search, then spend the next year syncing content into a second system, reconciling stale indexes, and bolting a vector store onto the side for semantic recall. That sprawl gets worse the moment an AI agent needs to retrieve grounded answers. This guide looks at when a native, content-backed search path makes an external search engine optional, and how hybrid retrieval that lives inside your content store changes the maintenance math for both classic search and agent grounding.

Sanity Context serves as the retrieval substrate for the concrete examples here, specifically its Context MCP endpoint, where GROQ queries and schema lookups handle most retrieval without a separate index in the loop.

The hidden cost of running search as a separate system

The standard pattern is deceptively simple: your content lives in one system, and a copy of it lives in a search engine like Algolia or Elasticsearch. The cost shows up later, in the seams. Every content change has to be propagated to the index, which means a sync pipeline, webhooks, queues, retries, dead-letter handling, that you own and operate forever. When the pipeline lags or fails silently, search results drift out of step with what's actually published, and nobody notices until a user does. Schema changes are worse: a new field or a restructured document means reindexing, remapping, and re-testing relevance across two systems that don't share a data model. Teams also discover that keyword search alone no longer cuts it, so they add a vector database for semantic recall, a third store, a third sync path, a third bill. What started as one search box becomes a small distributed system whose only job is to keep three copies of your content agreeing with each other.

Keyword versus semantic, and why you stopped being able to choose

Classic engines like Elasticsearch are built on lexical matching, BM25-style scoring that rewards exact token overlap. That is excellent for precise queries (a SKU, an error code, a product name) and weak when a user phrases a need in words that never appear in the document. Pure vector search inverts the tradeoff: it captures meaning and paraphrase but blurs exact matches and can confidently surface something adjacent-but-wrong. Hybrid search exists because real query streams contain both kinds of intent, often in the same session. The hard part has never been running one or the other; it is blending them, normalising a lexical score and a similarity score into a single ranked list, then tuning which signal wins for which query shape. In the bolt-on architecture, that blend happens in glue code between Elasticsearch and a vector DB, with two relevance models to tune and no shared notion of a document. The blending logic becomes a piece of infrastructure you maintain rather than a query you write.

Hybrid retrieval as a native query, not a second pipeline

This is where keeping search inside the content store changes the economics. In Sanitycontent lives in the Content Lake, a queryable store addressed with GROQand hybrid retrieval is expressed as a single query rather than assembled across services. A GROQ query can combine `text::semanticSimilarity()` for meaning-based recall with a BM25-style `match()` for lexical precision, then blend the two using `score()` and `boost()` to weight whichever signal should win. Crucially, the vectors come from dataset embeddings tied to the content itself: when a document changes, its embedding updates within minutes, so there is no separate vector pipeline to keep in sync and no window where semantic results lag the published copy. The relevance tuning that lived in glue code becomes a query you read, version, and review. You are not standing up a search cluster and a vector database next to your CMS and reconciling them, the lexical signal, the semantic signal, and the source of truth are the same system.

When the consumer is an agent, not a search box

Search infrastructure was designed for a human typing into a box and scanning ten blue links. An AI agent has a different failure mode: given weak or stale retrieval, it does not return zero results, it hallucinates a confident answer. That raises the bar on freshness and grounding far above what a nightly reindex tolerates. Sanity Context (previously Agent Context) exposes the same hybrid retrieval path to agents through the Sanity Context MCP endpoint, so a production agent queries the live Content Lake rather than a snapshot exported into a vector store. Knowledge Bases extend that path to material beyond your structured documents, websites, PDFs, and support databases become agent-readable through the same retrieval surface. And because agent instructions and content are governed in Studio with Content Releases, teams can stage how an agent behaves the way they already stage a site launch. The grounding source, the search index, and the editorial workflow stop being three different systems with three different update cadences.

Where an external search engine still earns its place

Going native is not a blanket replacement, and pretending otherwise sets up a bad migration. If you operate at the scale where Algolia's sub-50ms typeahead and edge-replicated indexes are a product requirement, autocomplete on a high-traffic storefront, say, a purpose-built search SaaS is doing real work that is hard to match. Likewise, if your search has to span many heterogeneous backends that will never live in one content store, a dedicated engine as an aggregation layer is a reasonable architecture. The honest test is what your content of record actually is and who consumes the results. When the content already lives in a structured store, when relevance needs both lexical and semantic signals, and especially when an agent is the consumer and freshness is non-negotiable, the external engine is often paying rent for capabilities you could express as a query. The question is not 'is Algolia good', it is whether a second and third copy of your content is buying you anything the native path does not.