Vector search is great for the “kinda similar” part of search. The annoying part is everything else: exact phrases, filters that must be respected, typo tolerance, relevance you can explain to a PM, and results that don’t randomly flip because a model sneezed.

So this isn’t a “vectors vs keywords” post. It’s about the boring, practical combo: vector + full-text, in the same system, with predictable behavior.

Azure AI Search and Manticore Search can both do hybrid search. But they feel very different to operate day-to-day.

Azure optimizes for rapid delivery. Manticore optimizes for living with search over time. That difference shows up less in week one — and a lot more in month six.

Where “generic search” stops working

There’s a whole class of search problems that look simple until you ship them: document search, knowledge bases, internal tools, anything with “small chunks” (paragraphs/sections) and lots of metadata.

This is where managed abstractions start to leak, and where defaults stop being your friend.

You end up caring about stuff like:

• strict filters (workspace/project, region, owner/team, timestamps, doc type, visibility, version)
• phrase/proximity (because wording matters)
• stable ranking (so results don’t wander around week to week)
• highlights/snippets that look like actual citations, not “AI vibes”

And yes, semantic/vector search helps — but it doesn’t replace full-text fundamentals or explainability.

Once you’re in that world (filters, phrases, stable ranking, “why did this rank?”), search stops being a thing you “turn on” and becomes something you’ll tune and debug over time. That’s when the real choice shows up: accept a managed service’s abstraction layer, or run an engine where ranking and execution are more explicit.

That split maps pretty closely to Azure AI Search vs Manticore.

Two ways to solve it

The cleanest way to think about it:

• Azure AI Search is a managed service you rent. You trade control for convenience (and you get Azure-shaped guardrails).
• Manticore Search is a search engine you run. You get knobs and dials, plus responsibility for the box it runs on.

If all you need is “good enough search” plus easy integration, Azure is hard to beat. If you need to argue with relevance and win, Manticore is easier to live with.

Cost comparison: managed vs self-hosted

This is one of the biggest practical differences between these two approaches, and it often only becomes obvious after a few months in production.

Azure AI Search costs

Azure AI Search is billed as a managed cloud service. You provision capacity (replicas and partitions), and you pay for that capacity per hour, whether it’s fully used or not.

That model has a few practical consequences:

• Cost scales with provisioned capacity, not actual query volume.
• High availability and higher throughput multiply costs (replicas × partitions).
• Vector search increases memory pressure, which often pushes you into higher tiers sooner than expected.
• You can’t “scale to zero” — the service costs money as long as it exists.

In real-world setups, teams often start small and then gradually scale up as indexes grow, query volume increases, or latency requirements tighten. Over time, it’s common for Azure AI Search to land in the hundreds of dollars per month, and for more demanding workloads, four figures per month is not unusual.

None of this is surprising — you’re paying for a fully managed service with SLAs, built-in redundancy, and tight Azure integration. But the important thing is that cost growth can feel indirect: you don’t always see a clear, linear connection between “we changed X” and “the bill went up”.

Manticore Search costs

Manticore Search itself is free and open source. There is no licensing cost. What you pay for is infrastructure and operations.

In practice, that usually means:

• one or more VMs (or containers)
• storage
• monitoring and backups
• some ops time

For many document and knowledge-base workloads, a single modest VM is enough. That often puts the monthly infrastructure cost in the tens of dollars, not hundreds. Even with redundancy or horizontal scaling, costs tend to grow in a predictable, hardware-shaped way.

The key difference is visibility: if costs increase with Manticore, it’s usually because you explicitly added RAM, CPU, or machines. There’s no opaque service unit math in the middle.

The tipping point

If your priority is minimal operational effort and deep Azure-native integration, Azure AI Search’s pricing can be a reasonable trade-off.

If your priority is predictable long-term cost, clear performance knobs, and avoiding surprise bills as data grows, running Manticore yourself often ends up significantly cheaper — especially once vector search is in the mix.

Azure AI Search: works fast, gets fuzzy later

Azure has a solid keyword engine: analyzers, stemming, phrases/proximity, synonym maps, scoring profiles, filters, and an optional semantic ranking layer. You can ship something quickly.

Where it starts to sting is when you’re past the demo and now you’re maintaining it:

• Tuning is mostly “turn these weights” (scoring profiles), plus maybe semantic ranking.
• The scoring is less transparent end-to-end than Manticore. You can tune with scoring profiles/analyzers and measure results, but you don’t get the same “read the query, understand the ranking” feeling.
• Hybrid merging is managed; keyword and vector results are fused with Reciprocal Rank Fusion (RRF). It’s convenient. It’s also harder to inspect when the top 10 looks wrong.

In practice, this often turns into compensating logic in the application layer: boosting, filtering, or post-processing results because the search engine won’t quite do what you need. That logic is harder to test, harder to explain, and harder to remove later.

If you’ve never had to explain “why is this #1?” to someone who’s mad, this is fine. If you have, you already know the pain.

Also: the whole thing is defined in service terms — schema JSON, Azure APIs, Azure limits. The practical downside is vendor lock-in: once your indexing model, analyzers, scoring profiles, and query patterns are Azure-shaped, moving later is real work.

Manticore Search: explicit, and honestly… nicer to debug

Manticore comes from the classic IR world and keeps full-text features very upfront: BM25-style scoring, field-level matching, phrases/proximity, filtering, and a SQL-ish query language. You can look at a query and tell what it will do. And more importantly: you can explain it to someone who doesn’t work on search.

Example: a “normal” full-text query

SELECT doc_id, WEIGHT()
FROM documents
WHERE MATCH('"data retention policy"~3')
  AND department = 'Finance'
  AND effective_date >= '2022-01-01'
ORDER BY WEIGHT() DESC
LIMIT 10;

That “WEIGHT()” bit is not magic; it’s part of the mental model. This matters more than people think.

Hybrid search without guesswork

With Azure, hybrid is “run both, fuse with RRF”. With Manticore, hybrid is “do this, then this, then filter and apply secondary ordering”. It’s less elegant on a slide, but it’s very practical.

Example (vector first, then text, then explicit sorting):

SELECT doc_id, knn_dist(), WEIGHT()
FROM documents
WHERE knn(embedding, 50, 'how to rotate api keys safely')
  AND MATCH('"key rotation" | "rotate keys"')
ORDER BY knn_dist() ASC, WEIGHT() DESC
LIMIT 10;

You can read this query out loud and it doesn’t sound like a prayer. That’s the point.

One nuance: KNN results are primarily ordered by vector distance; additional ORDER BY criteria refine within that KNN set (think: tie-breaks / secondary sorting), rather than “fully fusing” scores into a single blended rank.

Also: when ranking changes, you can usually point to the exact part of the query that caused it. Regressions become boring to debug — which is exactly what you want.

Storage-first products don’t replace search (they just force a second system)

This comes up a lot on Azure: you pick a document store (Cosmos DB, DocumentDB/Mongo API, etc.) and hope it’ll cover search too.

It won’t, not for anything chunk-level or relevance-sensitive. You’ll quickly want:

• phrase/proximity
• relevance tuning beyond basic text matching
• better ranking control
• hybrid (vector + keyword) that you can reason about

So you end up bolting on Azure AI Search anyway, and now you’re maintaining two separate things: storage + search, plus an indexing pipeline in between. That can be totally fine. Just don’t pretend it’s one system.

Freshness and “did my update land?”

In Azure, updates are API calls with their own semantics (and you need to be careful with partial updates). When content changes, vector fields need to be handled explicitly. It’s doable, it’s just… application-work.

Manticore’s real-time tables behave more like a database: insert/update/delete and the full-text + vector indexes keep up together. If you’re building something like product search or docs search where things change all the time, this feels simpler.

“We want Azure, preferably managed” (fair)

If your company’s default posture is “managed everything”, Azure AI Search fits that worldview. You plug it in, you accept the service model, you move on.

If you want Manticore with minimal headaches on Azure, the honest pitch is: it’s not managed, but it can be boring.

Azure AI Search works best when search is an infrastructure dependency. Manticore works best when search is a product surface.

Typical setup that doesn’t turn into a science project:

• keep documents in whatever Azure storage you already trust (Blob, a DB, etc.)
• run Manticore on a single VM (or a small VMSS later) in a VNet
• keep chunking/segmentation + indexing as a simple worker pipeline (queue + worker, or whatever you already have)
• treat search as a stateless-ish service: snapshots/backups, metrics, and replacement, not “pet servers”

If you’re in a compliance-heavy environment, this is also the boring win: private networking, predictable data flow, and no “please open the internet so the managed thing can talk to the other managed thing” dance.

You still own it, but you’re not forced into a complex cluster if you don’t need one.

A practical note: why vector search changes the bill

Hybrid search isn’t just “keyword + vector”. It’s also CPU + RAM.

• Keyword-heavy workloads mostly burn CPU.
• Vector-heavy workloads mostly burn memory.
• Chunk-level indexing often multiplies both: more rows, more vectors, more metadata, more filters.

On Azure AI Search, that usually shows up as “we need more capacity” (and the bill follows the provisioned units).
On Manticore, it usually shows up as “we need more RAM/CPU” (and you choose the VM size).

Same physics — different pricing model.

Quick note on “maybe Elastic then?”

Elastic is capable, and on Azure it’s a familiar choice. The trade is usually operational: more moving pieces, more knobs, more “cluster care and feeding”.

If you already run it well, cool. If you don’t, and all you want is chunk-level document search that behaves, it can feel like bringing a whole orchestra because you need a violin.

Developer experience (how it feels in the editor)

A concrete example: clause-level document search

If you want a stress test that exposes search tradeoffs quickly, this is it: split documents into clauses/sections, index those chunks, then ask people to find specific language under strict filters.

Why it’s unforgiving:

• Phrase/proximity really matters. A system that’s merely “similar” will surface lookalikes that waste time.
• Filters are not optional. Users will treat them as hard constraints, and they’ll notice when “almost matching” sneaks in.
• Trust is fragile. If people can’t tell why a result is #1, they stop trusting search and start working around it.

What it usually turns into (roughly):

• each clause becomes a row/document with clause_id, document_id, clause_path (or whatever naming), and the clause text
• metadata fields become hard filters (workspace/matter, jurisdiction/region, dates, version, visibility, etc.)
• optional: an embedding per clause for the “find me similar language” part
• UI pulls the full document separately and shows the clause with a snippet/highlight that’s easy to verify

Full-text baseline (predictable, easy to explain). Use this when people know the wording they’re hunting for:

SELECT clause_id, document_id, WEIGHT()
FROM clauses
WHERE MATCH('"limitation of liability"~3')
  AND jurisdiction = 'AU'
  AND effective_date >= '2022-01-01'
ORDER BY WEIGHT() DESC
LIMIT 10;

Where embeddings fit: they can be great for expanding recall (“find similar language”), but they’re not “thinking”. In practice, semantic search can land in an awkward middle ground: it looks smart at first, then frustrates people because it’s not reliably smart enough.

So here’s the pattern that tends to behave:

• If the user types exact-ish keywords → do pure full-text (BM25/WEIGHT()).
• If the user types an idea (“cap on liability”, “excluded damages”) → use embeddings to pull candidates, then lock it down with full-text + filters.

Hybrid example (semantic candidates → strict text + metadata → distance-first ordering):

SELECT clause_id, document_id, knn_dist(), WEIGHT()
FROM clauses
WHERE knn(embedding, 50, 'cap on liability and excluded damages')
  AND MATCH('"limitation of liability" | "consequential damages"')
  AND jurisdiction = 'AU'
ORDER BY knn_dist() ASC, WEIGHT() DESC
LIMIT 10;

What this actually does:

• knn(...) picks a candidate set by meaning.
• MATCH(...) + filters keep it verifiable (you can point at the words on the page).
• Results are primarily sorted by vector distance; WEIGHT() refines within that KNN set.

If you need real reasoning, do it after retrieval (e.g., run an LLM over the top N candidates).

This is also where RAG-style workflows fit. Manticore’s RAG support is on the roadmap (see issue #2286 ) — and by the time you’re reading this, it might already be shipped.

So which one would I pick?

• If you want “don’t make me run search infra” and you’re already deep in Azure, Azure AI Search is the obvious choice. You’ll move fast.
• If search relevance is a product feature (not a checkbox), and you expect to tune and debug it for months, you’ll probably prefer Manticore. You can be opinionated and precise without fighting managed abstractions.

One slightly unromantic rule: if your team can’t or won’t own search as a system, pick Azure. If your team can own it, pick the option that lets you see what’s going on — which usually means Manticore is the calmer long-term choice.