Vector Databases Compared: pgvector, Qdrant, or Chroma for Your RAG App?

If you are building a RAG app (retrieval-augmented generation) and are torn between vector databases, the direct answer for most companies: start with the pgvector extension on top of the PostgreSQL you already use, because it is practically enough up to several million vectors without adding a separate database that raises complexity and cost. Move to Qdrant only when you pass tens of millions of vectors, or need high-performance complex filtering, or distribution across several nodes. As for Chroma, its natural place is prototypes and quick experiments on your machine, not serious production.

The practical rule in one line: if you have PostgreSQL and have not passed two to five million vectors, do not complicate your life, pgvector is enough and runs on the same server and the same backups. You need a specialized database when nearest-neighbor search becomes the real bottleneck in your app, not before.

This guide compares the three in a practical table (performance, practical maximum size, ease of operation), then works out the memory per million vectors in numbers, explains when you truly need Qdrant, and how to run any of them on a cloud server as part of AI hosting.

What a vector database actually does

In a RAG app, you convert each chunk of text into a numeric vector (embedding) of fixed length, say 768 or 1536 numbers. When a user asks, you convert their question to a vector too, then search for the stored vectors closest to it to retrieve the most relevant texts and pass them to the language model. The core of the task, then, is fast nearest-neighbor search in a high-dimensional space, and every vector database solves this through an approximate index such as HNSW that balances speed against accuracy.

The common mistake is a developer assuming they need a specialized database from day one, while most apps never pass hundreds of thousands of vectors, a size pgvector handles in fractions of a second on a modest server.

The practical comparison table

Criterion	pgvector	Qdrant	Chroma
Nature	Extension on PostgreSQL	Standalone specialized DB	Lightweight library/DB
Comfortable practical size	Up to a few million	Tens to hundreds of millions	Hundreds of thousands
Filtering with search	Good via SQL	Excellent and optimized	Basic
Distribution across nodes	Limited	Built in	No
Ease of operation	Easiest if you have PostgreSQL	An extra managed service	Easiest for experiments
Backup	With your own database	Separate	Local files
Best for	Most RAG companies	Huge scale and complex filtering	Prototype

The decisive advantage of pgvector is that it lives inside your existing database: the same authentication, the same daily backup, the same monitoring tools, and the same transactions. You can combine vector search with normal SQL queries in one query, such as "the documents closest to this question, within the sales department, for this customer only," which saves you from syncing data between two databases.

Memory per million vectors in numbers

The memory math is simple and useful before choosing a plan. A vector of length 1536 at float32 precision occupies 1536 times 4 bytes, that is 6,144 bytes, roughly 6 kilobytes. So a million vectors at this length need about 6GB raw, plus the HNSW index that stores links between vectors, and at a common connection factor it adds roughly 256 megabytes per million. The table summarizes the need by vector length:

Vector length	Vector size	One million (raw)	With HNSW index (approx.)
384	~1.5KB	~1.5GB	~1.8GB
768	~3KB	~3GB	~3.3GB
1536	~6KB	~6GB	~6.3GB

Practical takeaway: a million vectors at length 768 runs comfortably on a Business plan with 8GB RAM, and even at length 1536 it stays within an Enterprise plan with 16GB RAM. If you need more, reducing vector length (768 models are enough for most Arabic RAG cases) halves the memory versus float32, and half-precision quantization (halfvec) halves the size again at a slight accuracy loss. See pricing and plans to balance RAM, since a 2GB upgrade at 600 SAR is usually enough to absorb hundreds of thousands of extra vectors.

When you truly need Qdrant

Qdrant is an excellent database, but it solves problems most companies only hit late. Move to it when one of these conditions holds:

• Scale: you passed tens of millions of vectors and search time in pgvector started to suffer despite index tuning.
• Complex filtering: you need vector search with heavy filtering across many fields at very high performance, which is Qdrant's specialty.
• Distribution: you need to spread data across several nodes for high availability or to exceed a single server's memory limit.
• Workload separation: you want to separate the vector-search load from your primary database so they do not compete for resources.

Note that Qdrant is an extra service, managed and backed up separately from your database, and this complexity is a price justified only at large scale. If you have not reached these conditions, you are paying complexity for nothing.

Tuning the HNSW index makes the difference

Many "pgvector is slow" complaints come from an untuned index, not the database itself. The HNSW index is controlled by two core parameters that balance build speed, search accuracy, and memory use:

• Connection factor m: the number of links per node in the index. Raising it improves accuracy and increases memory and build time. The common value of 16 is enough for most cases, raised to 32 when accuracy is the top priority.
• Build depth ef_construction: how many candidates the index examines while building. Raising it improves index quality and slows the build only once, so a value between 64 and 200 is a balanced choice.
• Search depth ef_search: set at query time rather than build time, it directly balances speed against accuracy per search. Raise it if you notice important nearby results being missed.

The practical rule: build the index with balanced values, then measure recall on real questions from your app, and raise ef_search gradually until you reach acceptable quality at a reasonable response time. Do not jump to another database before trying this tuning, since much of "pgvector slowness" disappears the moment the index is tuned.

Hybrid search raises RAG quality

Vector search alone sometimes misses important literal matches, such as a product number or a rare term the general meaning does not capture. The answer is hybrid search: combining vector search with traditional keyword search, then merging both results. pgvector's advantage here is clear, because it lives inside PostgreSQL which already supports full-text search, so you combine both kinds in one query with no extra tools. This alone is enough reason to prefer pgvector in apps with precise terms, codes, or product names, since combining both searches in one database is far simpler than coordinating between two separate ones.

Running all three on a Cloud server

All of them run on a Saudi cloud server, and the difference is in how you deploy:

• pgvector: install the extension on your existing PostgreSQL with one command, and create an HNSW index on the vector column. No extra service and no new port.
• Qdrant: run it through Docker from the AI hosting template, and make sure it listens on the private network, not the open internet.
• Chroma: the easiest for experiments, running as a library inside your app directly, suitable for building a prototype before committing to a production solution.

Having the server in Riyadh means the response time between your app and the vector database is around 8ms, which matters because every RAG request includes a vector-search round trip before calling the language model, so geographic proximity cuts the perceived total response time.

Conclusion: a practical decision

Start with the simplest solution that meets your need today, not your imagined need three years out. If you have PostgreSQL and have not passed a few million vectors, enable pgvector on a Business or Enterprise plan and build your app without an extra database. Watch the search time in practice, and only when it becomes the bottleneck despite index tuning, move to Qdrant. Use Chroma for quick experiments on your machine, not for production. This progression saves you early complexity and cost, and leaves you free to upgrade when you truly need it. Try the AI hosting template to start in minutes.