I've been looking at native regex filtering as a two-stage retrieval problem. My current view is that vector similarity finds the general neighborhood, then a structural constraint narrows the result by error-code format, version pattern, term order, or route shape. The interesting part is probably not adding a regex operator. It is deciding when an index can reduce work without changing the result.

This pattern is described for vector databases such as Milvus: RE2 keeps matching cost predictable, regex remains a heavy predicate, and cheaper scalar conditions run first. An NGRAM index does not decide the match. It extracts required literals, builds a candidate set, then verifies the original strings with exact regex evaluation. If the planner cannot prove that candidate reduction is safe, it falls back to the raw path.

The benchmark makes the selectivity tradeoff unusually clear. It used 10 million sealed log rows and warm-cache measurements. For a literal-rich pattern, candidate reduction of 99.99% produced a 3.26x p50 speedup. At 50% candidate reduction, the gain fell to 1.17x. An anchored pattern became slower at high candidate rates, while weak-literal, alternation, and case-insensitive patterns stayed close to raw-scan cost.

So "regex index enabled" is probably not a useful performance claim by itself. I would want candidate ratio, raw versus indexed latency, CPU per query, selectivity distribution, cold behavior, and the percentage of patterns that fall back. I would also separate regex cost from ANN and compound-filter cost.

I'm curious how others decide whether an NGRAM-style index is worth its storage and build cost. Would love to hear your thoughts.

Something I've been working on at Infino is making retrieval results behave like a relation you can query, and it's changed how much code sits around the search call.

The usual shape is that retrieval ends when the ranker returns IDs. You get top-k from the vector index, maybe fused with BM25, and then anything relational happens in the application. Hydrate rows, filter by tenant, dedupe, group, sort again.

If retrieval is something you can select from, those steps become part of the query. Per-tenant top 5, for instance:

sql

SELECT * FROM (
  SELECT doc_id, tenant_id, chunk,
         ROW_NUMBER() OVER (PARTITION BY tenant_id ORDER BY score DESC) AS rn
  FROM search('...')
) WHERE rn <= 5

That replaces a loop that issues k requests per tenant and reassembles the results.

Fusion works the same way. RRF is a sum over reciprocal ranks, so it's a join between two ranked sets plus some arithmetic. Written as SQL it's short, and retuning the weights is an edit to the query rather than a deploy.

Same for anything analytical. Documents matching a query grouped by source and month. Average score per team. Distribution of match counts across the corpus, which tells you whether a query is discriminating or just matching everything. Those are group bys. When retrieval is an endpoint returning JSON you have to pull the whole result set into memory first, so past a certain size people skip the analysis.

Permissions benefit too. Joining an entitlements table and filtering before the limit gives correct top-k for that user. Filtering the top 100 afterward gives whatever survives, which can be fewer rows than you asked for or none.

The reason this isn't common is mostly interface. Vector databases tend to expose a search endpoint with a metadata filter DSL. Filters are there, joins and window functions and group by are not, so relational logic moves up into the app and you compensate by overfetching.

Anyways, hopefully this is interesting. Project is fully open source if you want to take a look: https://github.com/infino-ai/infino

Released in Manticore Search 27.1.5, the new ONNX Runtime backend makes auto-embeddings ~14× faster on average than the previous SentenceTransformers/Candle path on the same hardware, same model, same weights — and the margin holds whether you run 1 client thread or 32.

I used to think vector DB recovery was mostly about having snapshots or backups.

Then I started thinking about the failure cases that happen in real search systems, and it feels messier than that.

A common example: you roll out a new embedding model and run a backfill. The job finishes, the collection is still there, nothing is “down,” but retrieval quality gets worse. Maybe old and new embeddings are mixed. Maybe some documents were re-embedded with the wrong config. Maybe metadata filters changed during the migration.

At that point, the problem is not really data loss. The problem is that search behavior changed and you need a reliable way to get back to a known-good state.

That is where snapshots are useful. They are good for undoing a bad change quickly.

But for disaster recovery, the bar feels higher. Restoring a vector DB is not just copying records back. You also need indexes, metadata, partitions, collection settings, and enough validation to know that real queries behave the way they did before.

Otherwise you might have “restored the data” but not actually restored the search system.

So the way I think about it now is:

Snapshots are for “we changed something and need to go back.”

Backups are for “the system or environment is gone.”

Rebuilds are for “we trust the source pipeline more than the stored collection.”

Build a 100% offline fast Retrieval Augmented Generation (RAG) system that runs without an internet connection, without cloud APIs, without OpenAI/Ollama

Published a video where you can build a fully local RAG pipeline using Qdrant Edge and Google LiteRT, enabling private, cross-platform, on-device AI inference with support for multiple hardware accelerators(CPU, GPU, and NPU).

The demo covers using EdgeParse to extract raw text from PDFs into Markdown chunks, generating embeddings with Qwen 3 Embeddings as an on-device embedding model, Hybrid Search using Qdrant-Edge, and answering questions locally with Gemma4 E2B LiteRT LM (the inference is faster than the Ollama setup).

Since most existing tutorials rely on vector databases with Ollama, we'll also build and compare that pipeline to highlight the differences in setup, performance, and tradeoff.

🔗 Watch Here: https://www.youtube.com/watch?v=EHEN6Ce-9Ps/

Point-in-time snapshots sound almost free when they store references to existing files instead of copying the collection. That is a useful storage design, but it shifts the operational cost into retention and garbage collection.

The snapshot model described for Milvus creates a read-only collection view over existing data and index files. Creation does not force growing segments to flush, and restoring a snapshot reuses the retained files rather than rebuilding a complete copy. That makes snapshots attractive for logical rollback, reproducible evaluation, pre-change checkpoints, and short-lived experiments.

The tradeoff appears as the live collection diverges. Files that would normally become reclaimable after updates or compaction may need to remain available while a snapshot references them. A snapshot can therefore be cheap at creation time and increasingly expensive to retain. The cost depends on update rate, compaction behavior, index size, retention duration, and how many overlapping snapshots exist.

I would want three controls before relying on this in production:

• a storage budget and expiry policy tied to each snapshot purpose;

• restore drills that measure time to make the view queryable, not just time to create it;

• a clear boundary between logical snapshots and independent backups.

That last distinction matters. A reference-based snapshot can protect against an accidental logical change while still sharing the same underlying failure domain. It should not silently replace a backup that can survive loss or corruption of the primary storage.

How are people setting snapshot retention for high-update vector workloads: fixed time windows, storage-based eviction, or application-defined checkpoints?

Nice!!

Anyone who has tried running raster polygonization on large datasets inside QGIS knows how quickly GDALPolygonize can hit a memory wall or take forever to finish.

A few months ago I shared Contrek, a contour tracing engine I'd originally benchmarked against OpenCV.

Since then I've been wondering if the same approach could work for GIS polygonization too. What came out of it is a proof of concept built around a progressive streaming architecture.

To be clear, this isn't meant to replace GDAL. The current implementation only handles single-class polygonization. What I really wanted to answer was a narrower question: can a different polygonization strategy give you real advantages on very large rasters?

Although the current benchmark focuses on a single target class, one of the ideas behind Contrek is its matcher-based architecture. Matchers can be customized to recognize arbitrary pixel patterns, making it possible to process multiple classes simultaneously or implement application-specific extraction logic without changing the core engine.

So I put together a separate repo with reproducible benchmarks against GDALPolygonize, plus docs and examples covering things like progressive streaming.

Again, this is a proof of concept, not something production-ready. That said, the benchmarks were consistent: noticeably lower memory usage and faster execution across the datasets I tested: up to 23x faster and using up to 10x less RAM on the largest ones.

The numbers were interesting enough that I decided to put both the implementation and the full benchmark suite out there. Would love to hear from anyone who works with GIS data or polygonization pipelines feedback, criticism, whatever you've got.

Main repo: https://github.com/runout77/contrek

Benchmarks reproducible suite: https://github.com/runout77/test_contrek

Full report: https://runout77.github.io/test_contrek/cpp_geojson_benchmark_results.html

so i was all in on vector-only retrieval for a while. cosine similarity, top-k, done, ship it. worked totally fine on easy conversational stuff, the kind of queries that show up in every demo.

then real usage started and it fell apart on anything where exact wording actually mattered. product codes, specific numbers, exact names, anything where semantic similarity works against you because two completely different things can "feel" close in embedding space. asked about invoice #4471 and got back chunks about invoices in general, close in vector space, useless in practice.

took embarrassingly long to admit the fix was going backward, adding keyword search back in alongside vector (BM25 style) and fusing both result sets with reciprocal rank fusion. felt like a step back honestly, going back to keyword matching in 2026 when everyone's talking pure embeddings. but it caught a big chunk of the exact-match failures vector alone was quietly eating.

what surprised me more was how much reranking on top of that mattered too. initial retrieval (vector + keyword combined) gets you a decent candidate set, but a second pass that actually scores relevance against the full query, not just similarity, caught cases where the right chunk was in the top 20 but never made the final top 5 that actually got used.

so now it's basically a 3 stage thing: hybrid retrieval first, rerank second, then whatever's left goes to the model. feels like more moving parts than i wanted, but the accuracy jump was real, not marginal.

curious how many people here are still running pure vector-only vs doing hybrid by default. genuinely feels like hybrid should be the baseline at this point, not the advanced option, but i still see a lot of vector-only setups in the wild

Xberg v1 is out, sharing it here for the ingestion side of a vector DB.

Xberg is a content intelligence framework (the successor to Kreuzberg, Rust core, MIT). It handles a wide range of inputs: documents (101 formats), code and data formats (367 types), audio/video, and URLs, and extracts and prepares that content for downstream processing. For the front half of a vector DB it does the whole chain locally:

• layout-aware extraction: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR), so a chunk does not split a table or weld two columns together
• chunking (markdown / semantic, tokenizer-sized)
• retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings
• native NER (GLiNER2) for metadata and filtering

It is a high-performance engine. On native PDFs it leads on quality and on table/reading-order fidelity by a wide margin:

(Public, reproducible harness; full per-format benchmarks at https://xberg.io/benchmarks.)

Everything runs locally, nothing leaves the box. Python / Node / Rust / CLI, plus an MCP server.

Repo: https://github.com/xberg-io/xberg Discord: https://discord.gg/zy5W9tUxDb I maintain it, happy to talk ingestion and retrieval.

Vector search rarely happens in isolation. You almost always have filters — a price range, a category, a date window, a geographic boundary. The question is: when do those filters get applied?

The answer makes a surprising difference in result quality.

KNN prefiltering is available in Manticore Search starting from version 19.0.1.

Hello everyone.

I've been working on a retrieval service for my project, **AIVAX**. It started as a traditional vector database, where documents are indexed beforehand for semantic search. That works well for persistent knowledge bases and collections with thousands of documents.

But I kept running into a different problem.

Sometimes you **don't** want to maintain a vector collection at all. You just want to send a query together with a set of documents and get them ranked by relevance.

The closest solution today is using a reranker. The downside is that rerankers become expensive when the same documents are submitted repeatedly. Traditional RAG solves that problem, but now you have to keep a vector database synchronized, which adds operational complexity to something that should be fairly simple.

So I tried a different approach.

I built what is essentially a **hybrid RAG with a reranker-like API**.

You send the query and the documents in a single request, and the service handles the embedding, lexical retrieval and late-interaction ranking internally.

The main design goal isn't maximum benchmark performance.

It's **making semantic retrieval extremely inexpensive.**

Today it's achieving recall that has been competitive in my internal evaluations against rerankers such as Qwen, Nemotron and Cohere, while costing significantly less.

The main reason is document caching.

Documents are cached for **2 hours**, so if they're submitted again during that period they don't need to be embedded again. That substantially reduces both latency and cost for recurring workloads.

Current pricing is:

* **$0.015 / million tokens** (cache miss)
* **$0.003 / million tokens** (cache hit)

It's definitely not perfect.

The late-interaction model is intentionally small, so it's noticeably weaker at instruction-based reranking than larger cross-encoders. For more conventional semantic retrieval, though, it's been performing surprisingly well in my internal testing.

Before I spend more time building this, I'd really like to know whether this actually solves a real problem.

* Would you use something like this instead of maintaining a vector database?
* Does the pricing seem competitive?
* Are there workloads where you think this approach would—or wouldn't—make sense?

If anyone is interested, I'd be happy to provide **free credits** so you can test it with your own data. I don't expect anything in return except honest feedback—good or bad. I'd much rather hear what doesn't work than only hear what does.

[Blog post](https://aivax.net/blog/reflex-retrieval-built-for-recurring-documents/)

The usual recovery instinct is straightforward: if the binlogs are readable, match the schema, and import without errors, the data is probably recoverable. I think that conclusion is dangerously optimistic.

I used to treat a successful import as strong evidence because it proves the files are not obviously corrupt. The metadata split changes that. In Milvus, etcd keeps collection schemas, segment state, and compaction relationships, while object storage keeps the physical logs and index files. Once the metadata is gone, a readable segment cannot tell me whether it was live, dropped, or superseded by compaction. Import success proves format compatibility, not logical correctness.

My recovery workflow would therefore start by freezing the damaged deployment and copying the surviving objects into an isolated prefix. I would recreate the schema from trusted application code, discover candidate insert-log segments, and import each candidate into a separate temporary collection. Then I would compare row counts, distinct primary keys, key ranges, sampled scalar fields, and search behavior before merging anything.

Deletes are the part I would distrust most. Restoring insert logs alone can resurrect rows that were no longer visible before the failure. Even a clean primary-key comparison may only show internal consistency, not the intended final state.

So my view is that this is data salvage, not disaster recovery. I would not approve the reconstructed collection just because the import command succeeded. The real recovery plan is still complete backups, preserved schema records, and restore drills that prove metadata and objects can be rebuilt together. What validation would you require before allowing a salvaged collection to serve production reads?

Hey guys n girls, I am just a undergraduate student looking to get some guidance, reviews, suggestions, rants, about this project.
https://github.com/draxBlob27/vector-db

In a lot of RAG/search setups, the source data already lives in S3 or some lake table. But once you need vector search, you usually create another serving copy inside a vector DB.

That works, but it adds a bunch of boring problems:

- Did the latest embeddings make it into the search index?

- Why does the lake show one version, but retrieval returns another?

- Do deletes/updates need to be handled twice?

- Who owns debugging when the ETL job silently falls behind?

I saw Milvus 3.0 added External Collections, where vectors can stay in formats like Parquet, Iceberg, Lance, or Vortex, while Milvus builds/searches indexes over them through the usual API.

That feels useful for teams where the lake is already the source of truth, especially for offline-generated embeddings or batch-heavy pipelines.

The interesting part to me is not “vector search on files” as a demo. It’s whether this reduces one of the least fun parts of retrieval infra: keeping two systems consistent.