What is the cheapest way to do vector search on a lot of documents?

The cheapest way depends on how often you need to query, how fresh the data must be, and whether you can tolerate some engineering work. But in general, for a large document corpus, the cheapest options are usually:

Cheapest practical options

1) PostgreSQL + pgvector

Best if you already have Postgres or want one system for storage + search.

Why it’s cheap:

• Uses existing infrastructure
• No separate vector database bill
• Easy to scale moderately

Good for:

• Up to millions of embeddings, sometimes more if tuned well
• Low-to-medium query volume
• Simple production setups

Tradeoff:

• Not always the fastest at very large scale
• Needs indexing/tuning
• Can get expensive if you push it hard on one big Postgres instance

---

2) Open-source vector DB on your own server

Examples: Qdrant, Milvus, Weaviate, Vespa

Why it’s cheap:

• Software is free
• You only pay for the servers

Good for:

• Large corpora
• More serious similarity search workloads
• Control over cost/performance

Tradeoff:

• You manage ops, backups, scaling, monitoring
• Cheapest only if you can run it well yourself

Among these, Qdrant is often a nice “cheap + simple” choice.

---

3) Brute force on smaller corpora

If you have a relatively small dataset, you can store embeddings in files or object storage and do approximate or even exact search in memory.

Why it’s cheap:

• Almost no infrastructure
• Good for prototypes

Tradeoff:

• Doesn’t scale well
• Query latency grows quickly

---

Usually most expensive

• Fully managed vector DBs at scale
• Serverless vector services with lots of queries
• Storing huge embeddings without compression or filtering

---

Biggest cost drivers

To make vector search cheaper, focus on:

1. Reduce embedding size
   Use smaller embedding dimensions if quality is acceptable.

2. Chunk less aggressively
   Fewer chunks = fewer vectors to store and search.

3. Filter before vector search
   Metadata filters can drastically reduce search space.

4. Use ANN indexes
   HNSW / IVF / PQ depending on engine and scale.

5. Batch embeddings and queries
   Reduces compute overhead.

6. Store only what you need
   Keep embeddings and minimal metadata; put raw docs elsewhere.

---

Rule of thumb

• Small to medium scale: Postgres + pgvector is often cheapest overall.
• Large scale, self-managed: Qdrant or Milvus on your own hardware.
• Prototype only: file-based / in-memory search.

If you tell me:

• number of documents,
• average chunk count,
• query volume,
• and whether you want managed vs self-hosted,

I can recommend the cheapest architecture more precisely.