Choosing a vector store for financial documents

The vector store matters less than the pipeline feeding it. For finance retrieval under a few million chunks, pgvector on your existing Postgres is usually the right answer: it puts embeddings next to the metadata you filter on, and it removes a system from your operational diagram. You reach for a dedicated store when index build time, memory, or query concurrency start to hurt. The choice sets your latency and cost, not your accuracy.

That last point is where most selection debates go wrong. Teams argue about HNSW versus IVF, or which managed vendor has the fastest recall benchmark, while the actual quality of retrieved passages is being decided upstream by chunking, the embedding model, and how well the metadata lets you scope a query. A perfect index over badly segmented documents returns confident garbage. So before comparing stores, be honest about what the store is responsible for and what it is not.

What the store is actually on the hook for

A vector store does three jobs: it holds embeddings, it finds approximate nearest neighbors fast, and it filters candidates by metadata. In finance, the third job is the one people underweight and the one that breaks projects.

Almost every real query is scoped. You are not searching all documents ever ingested. You are searching this counterparty’s filings, or this fund’s term sheets, or policy versions effective in Q2. That scoping is metadata filtering, and how a store implements it decides whether your latency holds up. Two patterns exist, and they behave very differently:

• Pre-filtering narrows the candidate set by metadata first, then runs vector search over what remains. Correct results, but if the filter is selective the HNSW graph gets sparse and recall drops, sometimes badly.
• Post-filtering runs vector search first, then discards candidates that fail the filter. Fast, but if your filter is selective you can retrieve fifty neighbors and keep three, missing relevant passages entirely.

For a bank asking about one obligor out of forty thousand, naive post-filtering will quietly return nothing useful. You want a store that does filtered HNSW well, meaning it prunes the graph traversal by the metadata predicate rather than bolting the filter on either end. pgvector’s iterative index scan, Qdrant’s payload-aware search, and Weaviate’s filtered search all handle this; a store that only offers post-filtering is disqualified for scoped finance retrieval regardless of its benchmark numbers.

Point-in-time correctness is not optional

Financial documents get restated, superseded, and corrected. A 10-K gets amended. A credit policy has versions. A term sheet gets redlined four times before signing. If your store cannot answer “what did we know as of this date,” you have built a lookahead machine that leaks future information into answers about the past.

This is the same discipline you apply to a feature store, moved into retrieval. Concretely, it means every chunk carries at least an effective date, an ingestion timestamp, and a document-version identifier, and every query can filter on them. The store does not need temporal features built in. It needs metadata filtering that is fast and correct enough that adding effective_date <= :as_of AND superseded_at > :as_of to every query does not wreck your latency. That requirement pushes you toward stores with strong filtered search, and it is another reason keeping embeddings in Postgres is attractive: the temporal predicates live in SQL you already trust, and lineage from chunk back to source document is a join, not a second system to reconcile.

Get this wrong and the failure is invisible in a demo and catastrophic in an audit. An answer built on a restated figure, retrieved because the store had no notion of which version was current, is exactly the confident-sentence-with-a-wrong-number problem. No reranker saves you from it, because the wrong passage was genuinely the closest match.

Hybrid search, because finance runs on exact tokens

Dense vectors are good at meaning and bad at identifiers. Financial documents are full of identifiers that must match exactly: CUSIPs, ISINs, LEIs, ticker symbols, defined terms, section numbers, basis-point figures. Embed “SR 11-7” and a pure vector search will happily surface passages about model risk in general while missing the one that names the guidance. That is a retrieval miss no amount of embedding-model upgrade fixes, because the signal is lexical, not semantic.

So build hybrid search in from the start. You run dense retrieval alongside a sparse or keyword retrieval (BM25, or a learned sparse model like SPLADE) and fuse the results, usually with reciprocal rank fusion. When you evaluate a store, check what it gives you here:

• Native BM25 or full-text alongside vector search, so you are not standing up a separate search cluster to reconcile.
• A fusion step you control, or at least clean access to both result sets and their scores so you can fuse them yourself.
• The ability to keep the exact-match fields (identifiers, dates, defined terms) as filterable metadata, so identifier matches can be enforced rather than merely ranked.

Weaviate and Qdrant ship hybrid natively. Postgres gives you tsvector full-text next to pgvector and you fuse in application code, which is more work but keeps everything in one place with one consistency model. Elasticsearch and OpenSearch come at it from the search side and now do vectors competently, which makes them reasonable if your organization already runs and staffs them.

How the decision actually goes

Order the questions so the disqualifying ones come first. Does it do filtered HNSW correctly, so scoped queries keep their recall? Can it enforce point-in-time correctness through fast metadata predicates? Does it support hybrid retrieval without a second system? Only after those do the familiar operational questions matter: index build time at your document volume, memory footprint (HNSW is memory-hungry, and quantization trades recall for RAM), horizontal scaling if you are past a single node, and whether you want a managed service or self-hosted for data-residency reasons that DORA and your own controls will ask about.

Build a small eval set of real queries with known-correct passages before you commit, and measure recall at the scoping and filtering your production queries will actually use, not on an open benchmark. Most teams discover the stores rank about the same on retrieval quality and diverge entirely on operational cost. That is the honest shape of this decision: pick the store that is cheapest to run correctly against the constraints above, then spend the time you saved on the chunking and eval work that actually moves your answers.