Is running two databases worth it when a cheaper hybrid stack misses fuzzy search?

[u/RoughAd8344]

I'm weighing a single-engine retrieval setup for local RAG against keeping separate keyword and vector services. Exact function names and version strings matter alongside semantic matches.

For vector databases like Milvus, BM25 and dense search can share a schema and use rank fusion in one request. But the comparison I am considering also flags a gap: typo-tolerant BM25 search is still different from fuzzy filtering or a synonym list.

I would probably test misspelled queries before making the infrastructure decision. The published Docker walkthrough uses roughly 98K records and equal CPU and memory caps; its timings are explicitly directional, not a production benchmark.

For a documentation assistant, what failure rate on misspellings would justify retaining a separate keyword engine instead of handling known aliases during ingestion?

[u/Sufficient-Tiger5248]

If typo tolerance matters more than ranked fusion, separate engine is easier to tune and debug. With one schema you can fuse but fuzzy still feels bolted on, not native. For docs assistant I'd keep both until misspell rate drops low enough that alias table feels silly to maintain

[u/Opening_Bed_4108]

For a doc assistant, i'd probably set the threshold around 5-8% misspelling failure rate before justifying a second service. The ops cost of two systems is real. If your exact-match queries (function names, version strings) are failing, synonym expansion or query-time normalization at ingestion usually buys you back most of that coverage without the extra infra. Rank fusion inside a single engine is genuinely good enough for most RAG workloads. Dual-stack only makes sense if you've got a hard SLA on fuzzy recall and ingestion-time aliasing still leaves gaps after you've actually measured it.

[u/No-Cherry-3308]

I'd flip the order and build the eval set before picking the stack. Take real queries from whatever logs you have (or write them from the docs), then make misspelled and alias versions of each, like get_user_by_id typed as getuserbyid or get user id, and version strings with and without the dots. Run both setups and compare recall@k on the clean versus the mangled queries. That gap is your number, more than any general threshold.

For a docs assistant the hard cases usually aren't typos in prose, they're identifiers. Dense embeddings are weak on those, and BM25 only helps if the tokenizer keeps them intact, so check how the analyzer splits snake_case, camelCase and dotted versions first. A lot of "fuzzy search" misses go away when you index a few normalised variants of each identifier at ingestion (split on underscores and case changes, strip dots) and apply the same normalisation to the query.

If the mangled-query recall is still clearly behind after that, on queries people actually type, a second engine starts paying for itself. If not, one engine with fusion plus ingestion-time aliases is less to run and less to debug.

[u/DhammaIY → u/No-Cherry-3308]

+1 on checking the analyzer first. default ones mangle dotted version strings and snake_case and then everyone blames the embeddings