Vector Databases for Bank RAG: pgvector vs Qdrant vs Pinecone

A bank that puts its policies, credit memos and product documents behind an AI assistant lives or dies by its retrieval layer, and that layer is the vector database. The model sitting on top matters less than people think: if retrieval returns the wrong chunks, or returns chunks the asker is not allowed to see, the best language model in the world will still produce a wrong or non-compliant answer. For a typical bank or insurer corpus of one to ten million document chunks, the realistic shortlist is pgvector, Qdrant, Milvus or Pinecone, and the decision turns on permission filtering, data residency and three-year cost, not on benchmark latency.

This guide walks through those criteria with real numbers, gives a worked sizing example, and states plainly when each option is the wrong one.

What the vector database does in a document RAG stack

A retrieval augmented generation system has four moving parts: a document pipeline that chunks and embeds text, a store that holds the vectors plus metadata, a query path that turns a staff question into a vector and finds the nearest chunks, and a language model that answers from those chunks. Our complete guide to retrieval augmented generation covers the whole pattern; this post is only about the store.

The store carries four jobs that matter to a regulated institution:

• Similarity search. Find the k chunks closest to the question vector, fast enough that staff do not notice.
• Metadata filtering. Restrict that search to chunks the asker may see: their department, their client segment, documents that are still in force.
• Durability and audit. The corpus is derived from records of the institution. Losing it means re-embedding everything, and every answer must be traceable back to a source chunk.
• Freshness. A policy updated this morning must be searchable this afternoon, which means cheap, continuous writes.

General comparisons of vector databases obsess over the first job. Bank deployments are decided by the second and third.

The four criteria that actually decide the choice

Permission-scoped filtering

Every serious query in a bank is filtered. A credit officer in SME lending should not retrieve board minutes, and a relationship manager should not retrieve another client segment's pricing exceptions. That means the database must apply metadata filters inside the approximate nearest neighbour search, not after it. Post-filtering (retrieve 100, keep the 8 the user may see) both leaks information through result counts and destroys recall when the filter is selective.

This is where the contenders differ most, and where independent benchmarks get interesting. One 2026 benchmark run on one million 768-dimensional vectors found unfiltered p99 latencies of 12 ms for Qdrant and 32 ms for pgvector, but with filters applied pgvector's p99 rose to 61 ms and Pinecone's to 53 ms. At ten million vectors with selective filters, the same benchmark measured pgvector degrading roughly eight-fold. Filtered performance, not headline speed, is the number to test on your own data.

Data residency and deployment model

Bank regulators and data protection law across Africa, the EU and most other markets condition or restrict cross-border transfer of customer data, and many institutions simply require that document stores stay in their own cloud account or on premises. Embeddings are derived from personal data and can leak information about it, so treat them with the same residency controls as the source documents.

Deployment options split cleanly:

• Self-host anywhere: pgvector (a Postgres extension), Qdrant and Milvus (both open source) run in your VPC, on premises, or at a local host.
• Managed in your cloud: Qdrant Hybrid Cloud, Zilliz BYOC and Pinecone BYOC run the data plane in your account with a vendor control plane.
• Vendor cloud only: standard Pinecone and Zilliz managed tiers run in the vendor's AWS, Azure or GCP accounts.

Total cost at your corpus size

Vector pricing is wildly non-linear between vendors. Section five works a full example, but the pattern is: self-hosting is cheap in compute and expensive in engineer time; managed serverless is cheap at pilot scale and climbs steeply past ten million vectors.

Operational burden

A vector database is infrastructure someone must patch, back up, monitor and restore. pgvector rides on Postgres, which most banks already run well. Qdrant is a single Rust binary with snapshots. Milvus is a distributed system that, per its own architecture documentation, needs etcd for metadata, MinIO or S3 for object storage, and Kafka, Pulsar or Woodpecker as a write-ahead log, across several node types. That is a Kubernetes platform team's job, not a side project.

The contenders

pgvector: the default when you already run Postgres

pgvector adds vector types and indexes to Postgres. You get exact and approximate search with HNSW, single and half-precision vectors (half-precision supports up to 4,000 dimensions), plus binary and sparse vectors. Filtering is ordinary SQL: a WHERE clause over indexed columns, with hnsw.iterative_scan = strict_order to keep filtered approximate search honest, and partial indexes or table partitioning when you filter on many distinct values. Hybrid search (vector plus keyword) comes free via Postgres full-text search.

The strengths are transactional consistency with the rest of your data, one fewer system to run, and a mature backup and audit story. The ceiling is real: community experience and the benchmarks above put comfortable territory at up to five or ten million vectors with moderate query rates, and filtered search degrades first. Timescale's pgvectorscale extension adds a DiskANN-style index that pushes that ceiling higher while keeping the Postgres operational model.

Qdrant: the self-hostable specialist

Qdrant is a purpose-built vector database written in Rust, open source, and trivially deployable as a single node or a cluster. Its filtering is first-class: match, range, datetime, nested keys, full-text and phrase match on payloads, all applied inside the HNSW traversal. Its quantization options are the best documented in the field: scalar quantization cuts memory four-fold with usually under one percent recall loss, binary quantization cuts memory up to 32-fold and reaches 0.98 recall@100 on OpenAI's 1536-dimensional embeddings when paired with rescoring, and the newer TurboQuant method targets eight-fold compression at scalar-like recall.

Qdrant's pricing spans a free open-source tier, a usage-based managed cloud at a 99.5 percent SLA, a premium tier with SSO, private VPC links and 99.9 to 99.95 percent SLA, and Hybrid or Private Cloud for regulated workloads that must stay on your own infrastructure, including air-gapped setups.

Milvus and Zilliz: the scale play

Milvus is the heavyweight open-source option, built for hundreds of millions of vectors with fully disaggregated storage and compute. It is genuinely excellent at that scale and genuinely overbuilt below it. Zilliz Cloud is its managed sibling, and the Zilliz pricing page is unusually transparent: a capacity-optimized compute unit holds about eight million 768-dimensional vectors, works out to roughly $16 per million vectors per month, and the Enterprise tier at a 99.95 percent SLA adds audit logs, SAML SSO, granular RBAC and private networking. Business Critical targets regulated finance and healthcare with customer-managed keys and HIPAA eligibility.

Pinecone: the managed incumbent

Pinecone pioneered managed vector search and remains the lowest-ops way to start. The current pricing is serverless and usage-based: a $50 monthly minimum on the Standard plan, storage at $0.33 per GB per month, reads at $16 to $18 per million units, and an Enterprise tier at a $500 monthly minimum with SSO, RBAC, a 99.95 percent SLA and a HIPAA add-on. There is no self-hosted Pinecone; BYOC puts the data plane in your cloud if residency demands it. The trade-off is cost at scale: independent production cost analyses, such as this engineering comparison, put pod-based Pinecone at roughly $70 per month per million vectors and $700 to $900 per month at ten million, several times the self-hosted equivalent.

Worked example: sizing a real bank corpus

Take a mid-size bank digitising its knowledge base: credit policy manuals, product sheets, regulatory circulars, past credit memos and procurement documents.

• Corpus: 120,000 documents, averaging 15 chunks each, gives 1.8 million chunks.
• Embeddings: 1,536 dimensions at 32-bit float. Raw vector data is 1.8 million times 1,536 times 4 bytes, about 11 GB.
• Index: full-precision HNSW adds graph overhead, so plan for 15 to 18 GB in memory. Scalar quantization brings that to roughly 4 GB; binary quantization to under 1 GB with rescoring from disk.
• Load: 200 staff asking 30 questions a day is about 6,000 queries daily, well under one query per second on average. Throughput is irrelevant here; capacity and filtering dominate.

What that costs per month, approximately:

• Self-hosted Qdrant or pgvector: the corpus with scalar quantization fits comfortably on a 32 GB RAM server. Entry cloud instances at budget European providers such as Hetzner start at EUR 5.99 per month with 20 TB of traffic included, and a 32 to 64 GB node there or at a local cloud costs a small fraction of any managed minimum. The honest cost line is engineer time: figure half a day a month for patching, backups and monitoring once set up.
• Zilliz Cloud: one capacity-optimized dedicated unit covers up to eight million 768-dimensional vectors for about $126 per month; this corpus fits in one unit even at 1,536 dimensions with headroom.
• Pinecone Standard: storage of 12 GB costs about $4 per month, reads and writes at this volume add a few dollars, so the $50 minimum covers the workload. The bill only becomes interesting at ten times this corpus size.

At 1.8 million chunks every option is affordable. The decision at this scale is operational: who runs it, where it sits, and how well it filters. At 20 million chunks the arithmetic inverts and managed per-vector pricing becomes the thing to model carefully. For fund administration, research and advisory teams, the same retrieval architecture underpins the document workflows we implement in our Claude for Financial Services engagements.

Setting up permission-scoped retrieval: the procedure

Whichever store you choose, the pattern for compliant retrieval is the same:

1. Attach an entitlement payload to every chunk at ingest time. Department, client segment, confidentiality tier, document owner, and a valid-from and valid-until date. This metadata must come from the source system of record, not from the documents themselves.
2. Index the filter fields. In Qdrant, create payload indexes on each filter key so filtered search stays inside the graph traversal. In pgvector, add ordinary or partial indexes, or partition the table by department if filter values are few and stable.
3. Resolve the user at query time. Look up the asker's entitlements in your identity provider or core banking system, build a filter (department is one of theirs, segment matches, valid-until is in the future), and pass it with the vector query.
4. Filter inside the search, never after. Over-fetching and post-filtering leaks through counts and breaks recall on selective filters.
5. Log the filter and the returned chunk IDs with every answer. When audit asks why a staff member saw a paragraph, you need the chain: user, filter, chunks, source document.

Two refinements pay off quickly. First, add keyword search alongside vectors: queries containing policy numbers, account identifiers or regulation citations behave badly in pure vector search, and hybrid retrieval (BM25 plus dense vectors, fused) fixes that, as the team at semantic.io's comparison documents. Second, keep the original text and a model version tag on every chunk so you can re-embed the corpus when you change embedding models.

When each option is the wrong choice

• pgvector is wrong when you expect tens of millions of vectors with heavy concurrent filtered traffic, or when nobody on the team runs Postgres well. Its filtered-search degradation is the first wall you will hit.
• Qdrant is wrong when the corpus is tiny (under 100,000 chunks, where even a flat index in Postgres or SQLite is fine) or when you need embeddings to participate in the same ACID transactions as financial records. Two systems means two consistency stories.
• Milvus is wrong below roughly ten million vectors unless you already operate Kubernetes well. You will spend more time running etcd, object storage and the WAL than you will save on query latency.
• Pinecone is wrong when residency rules keep document data in-country and BYOC is not acceptable to your risk team, or when you need predictable cost past ten million vectors. Usage-based read pricing rewards prototyping and punishes scale.
• Any vector database is wrong if your real problem is 50,000 documents and full-text search: start with Postgres full-text or OpenSearch and add vectors when semantic recall demonstrably beats keywords on your evaluation set.

Common mistakes

• Benchmarking unfiltered search. Every bank query is filtered. Test p99 latency with your real entitlement filters on your real corpus; expect several-fold degradation from headline numbers and design for it.
• Post-filtering for permissions. It leaks and it under-retrieves. Native filtered search only.
• Storing only vectors. Keep the source text, document ID, version and embedding model version on every chunk. Audit and re-embedding both depend on it.
• Skipping the re-embedding plan. Embedding models improve yearly. If swapping models means a big-bang rewrite, you will never do it. Pipeline the corpus so re-embedding is a batch job, and read up on handling hallucinations in production for the evaluation discipline that should gate any model swap.
• Ignoring hybrid search. Identifiers, names and codes need keyword matching; concepts need vectors. Fuse both.
• Comparing sticker prices instead of three-year TCO. Include engineer time for self-hosting and the growth curve of usage-based pricing for managed. The orchestration framework you choose matters less than either.

Frequently asked questions

Is pgvector good enough for production RAG at a bank?

Yes, for corpora up to roughly five to ten million chunks with moderate query rates, provided you tune filtered search with strict iterative scans and partial indexes or partitioning. Beyond that, or under heavy concurrent load, a dedicated engine such as Qdrant or Milvus holds latency better. Many institutions start on pgvector because they already operate Postgres and migrate only if measurements force it.

How much does a vector database cost for one million document chunks?

Self-hosted Qdrant or pgvector fits on a single mid-range VPS costing tens of euros per month. Zilliz Cloud's capacity-optimized tier prices at roughly $16 per million 768-dimensional vectors per month with a full compute unit minimum around $126. Pinecone's $50 monthly minimum covers a pilot of that size, with costs rising steeply past ten million vectors on usage-based pricing.

Can we keep embeddings on premises or in-country?

Yes. pgvector, Qdrant and Milvus are open source and run anywhere, including air-gapped environments, and Qdrant, Zilliz and Pinecone all offer bring-your-own-cloud options where the data plane stays in your account. Standard managed tiers run in vendor cloud regions, so check region availability against your residency obligations before committing.

Are embeddings personal data?

Treat them as such. Embeddings are derived from personal data, and research has shown they can leak information about the source text. Apply the same residency, access control, retention and deletion controls to the vector store as to the document store, and record both in your data protection impact assessment.

Which embedding size should we choose: 768 or 3,072 dimensions?

Storage and memory scale linearly with dimensions, so 3,072-dimensional vectors cost four times the RAM of 768. For policy and memo retrieval, 768 to 1,536 dimensions from a strong model is usually sufficient, and scalar or binary quantization recovers most of the memory difference with minimal recall loss. Measure recall on your own question set before paying for extra dimensions.

Do we need a separate vector database if we already run Postgres?

Not at first. pgvector plus hybrid search handles a corpus of a few million chunks well, with the enormous advantage that backups, access control and audit piggyback on infrastructure your team already trusts. Add a dedicated vector database when measured filtered-search latency or corpus growth demands it, not before.

Where to go from here

The vector database decision is one workstream in a larger architecture: document pipelines, entitlements, evaluation, and the governance documentation your regulator will ask for all have to land together. For the infrastructure side beyond retrieval — environments, identity, networking and observability — our enterprise AI agent deployment playbook is the companion read, and the enterprise AI implementation guide covers the path from strategy to production. Our enterprise AI practice for banks and insurers covers exactly this kind of engagement: private deployment, RAG architecture, evaluation harnesses and the paperwork that makes risk committees comfortable. If you are scoping a document assistant for a regulated environment, that page describes how we work and what an engagement looks like.