pgvector vs Azure AI Search vs Qdrant: Choosing a Vector Store

Choose pgvector if your data is already in PostgreSQL and a single database server can hold your vectors, choose Azure AI Search if you want a managed search service on Azure with hybrid search, indexers and integrated vectorization, and choose Qdrant if vector search is the core of your workload and you want a purpose-built engine with features such as named vectors, sparse vectors and sharding. The right answer depends on where your data lives, how you filter, and who will operate the system.

Who this is for and what you will have

This article is for engineers choosing a vector store for retrieval-augmented generation (RAG), semantic search or recommendations. By the end you will have a side-by-side comparison, a short list of questions that decide the choice, and a test plan you can run on your own data. It is based on the products' own documentation and makes no benchmark claims, because the right numbers are the ones from your corpus and queries.

What a vector store has to do

Whatever you pick, the store must do five jobs:

1. Hold embeddings, which are arrays of numbers produced by an embedding model, next to the text and metadata they came from.
2. Find the nearest neighbours of a query vector quickly, usually with an approximate index.
3. Combine similarity with filters such as tenant, language or date.
4. Optionally combine vector results with keyword results (hybrid search), which helps with product codes, names and jargon.
5. Stay operable: back up, secure, monitor and scale.

The differences between the three options mostly come down to how well each handles jobs 3 to 5 for your situation.

The three options at a glance

pgvector

pgvector adds vector types, distance operators and indexes to PostgreSQL. Per its README it supports Postgres 13 and later, and you enable it once per database:

CREATE EXTENSION vector;

What it offers

• Types and limits. vector indexes up to 2,000 dimensions, halfvec up to 4,000, bit up to 64,000, and sparsevec up to 1,000 non-zero elements for HNSW. Storage limits are higher: 16,000 dimensions for vector and halfvec.
• Distance operators. <-> for L2 distance, <#> for negative inner product, <=> for cosine distance, <+> for L1, and Hamming and Jaccard for bit vectors.
• Index types. HNSW and IVFFlat, with defaults such as m of 16, ef_construction of 64 and hnsw.ef_search of 40. The companion article pgvector on PostgreSQL: Setup, HNSW vs IVFFlat and Tuning goes deeper.
• Everything Postgres gives you. Joins, transactions, row-level security, backups, replication and the tooling your team already knows.

Where it needs care

Approximate indexes apply filters after the index scan. The README gives an example: with the default hnsw.ef_search of 40 and a filter that matches 10 percent of rows, about 4 rows match on average. Remedies include iterative index scans (added in 0.8.0), a standard index on the filter column for selective conditions, partial indexes for a few distinct values and partitioning for many values.

Vector search shares CPU, memory and I/O with your transactional workload. Build time for HNSW indexes depends on whether the graph fits in maintenance_work_mem. If vector search will dominate your database load, size or separate that workload deliberately.

Best fit

Applications that already run on PostgreSQL, need transactional consistency between records and their embeddings, filter heavily by relational attributes, and have a corpus that fits on one well-sized server.

Azure AI Search

Azure AI Search is a managed search service that supports vector, keyword and hybrid queries in one index. Its documentation describes the main building blocks:

• Hybrid search. A single request with both search and vectorQueries runs full-text and vector queries in parallel and merges results with Reciprocal Rank Fusion. Microsoft notes that hybrid retrieval with the optional semantic ranker offers significant relevance benefits, and that keyword search is stronger for exact matches such as product codes, specialised jargon, dates and names.
• Filtered vector search. Filters apply to text and numeric fields. A vector field itself isn't filterable, but the engine can process the filter before or after executing the vector query.
• Algorithms. HNSW for approximate search and exhaustive KNN. Fields using HNSW must reside in memory during queries; exhaustive KNN fields load into memory in pages and don't consume vector quota.
• Ingestion. You can push pre-computed embeddings, or use indexers with integrated chunking and vectorization from supported sources such as Azure Blob Storage, Azure Cosmos DB for NoSQL, Azure Data Lake Storage Gen2, Azure Table Storage and Microsoft OneLake. See Azure AI Search Integrated Vectorization from Blob Storage for that workflow.
• Pricing note. Vector search is available in all regions and on all tiers at no extra charge, although embedding generation or AI enrichment can incur charges from the model provider. You pay for the search service itself.

Sizing and limits

Vector index size quotas are set per partition, so adding partitions raises the quota. Quotas are based on the memory needed for approximate nearest neighbour search. Microsoft gives a formula for estimating size: raw size is documents multiplied by dimensions multiplied by the data type size (4 bytes for Edm.Single, 2 for Edm.Half, 1 for Edm.SByte), then multiplied by an algorithm overhead (1 to 20 percent for uncompressed float32 HNSW vectors, lower as dimensions rise) and a deleted-documents factor. Scalar and binary quantization and narrower data types reduce quota consumption. In the portal, the Overview page's Usage tab and the Scale page show partition and vector quota usage.

Best fit

Azure-centred applications that want a managed service, indexers for common Azure data sources, strong hybrid retrieval and no database to operate. It pairs naturally with enterprise RAG designs such as RAG over SharePoint Documents and the architecture in Production LLMOps and Enterprise RAG Architecture.

Qdrant

Qdrant is an open-source vector database. A minimal local start from its README is:

docker run -p 6333:6333 qdrant/qdrant

What it offers

• Collections and distance metrics. All vectors in a collection share one dimensionality and one distance metric: Dot, Cosine, Euclid or Manhattan. Cosine is implemented as a dot product over normalised vectors, normalised automatically on upload.
• Named vectors. One point can hold several vectors, each with its own size and distance metric, optionally with its own HNSW or quantization configuration.
• Sparse vectors. Supported since v1.7.0 and always scored with dot product, which enables hybrid search that combines dense and sparse vectors in one query, merged with fusion strategies such as Reciprocal Rank Fusion and Distribution-Based Score Fusion.
• Payload filtering. Metadata attached to each point can be filtered with must, should and must_not conditions.
• Quantization and memory tiers. Built-in quantization trades speed against precision; the project's README claims it can cut RAM usage by up to 97 percent, which you should verify on your own data. Vectors are always stored on disk, with a per-vector memory tier controlling how much is also held in memory.
• Scale-out. Sharding and replication for horizontal scaling.

Where it needs care

It is another system to run, secure, back up and monitor, whether self-hosted or through a managed offering. Keeping it in sync with your system of record is your responsibility.

Best fit

Workloads where vector retrieval is central, you need features such as multiple vectors per item or sparse-dense hybrid search, and you can run or buy a dedicated service.

How to decide

Answer these questions in order and stop when one gives a clear answer.

1. Where is your source of truth? If it is PostgreSQL and the corpus is moderate, start with pgvector. Removing a network hop and a sync pipeline is a real advantage.
2. Are you on Azure and want managed hybrid search with indexers? Azure AI Search removes most of the plumbing, and vector search adds no separate charge on top of the service tier.
3. Is vector retrieval your product? If search quality and vector-specific features drive the application, evaluate Qdrant.
4. How selective are your filters? If most queries filter down to a small slice, test filtered recall in every candidate. This is where approximate indexes behave differently.
5. Who operates it? A managed service costs money; a self-hosted one costs attention.

Run a fair test

Don't pick from feature tables alone. Build a small test set and run the same steps on each candidate:

1. Take 1,000 to 10,000 real chunks and 50 to 100 real questions, with the correct source chunks marked by a person.
2. Embed them with one embedding model. Use the same model for every store.
3. Index them in each store with its default settings, then with tuned settings.
4. Measure recall at the top 5 or 10 results, query latency at your expected concurrency, and filtered-query recall.
5. Estimate cost at your target corpus size, including index memory, replicas and operations time.

The same dataset becomes the start of your regression suite; see Building a Golden Dataset to Regression-Test LLM Features.

Common mistakes

• Choosing by benchmark blog posts instead of your own data and filters.
• Ignoring filtered queries, then discovering low recall in production.
• Changing the embedding model without re-embedding stored vectors. Stored and query vectors must come from the same model.
• Forgetting that HNSW indexes consume memory, whether that is Postgres maintenance_work_mem, Azure AI Search vector quota or Qdrant memory tiers.
• Treating the store as the source of truth for documents instead of keeping originals elsewhere, which makes migration painful.

Checklist

• You know where your source data lives and who owns the pipeline.
• You decided whether you need hybrid (vector plus keyword) retrieval.
• You tested filtered queries with realistic selectivity.
• You estimated memory and storage for your target corpus size.
• You compared operating effort, not just features.
• You kept originals and embedding-model choice separate from the store.

References

• pgvector README: https://github.com/pgvector/pgvector
• Azure AI Search vector search overview: https://learn.microsoft.com/en-us/azure/search/vector-search-overview
• Azure AI Search hybrid search overview: https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview
• Azure AI Search vector index limits: https://learn.microsoft.com/en-us/azure/search/vector-search-index-size
• Qdrant collections: https://qdrant.tech/documentation/concepts/collections/
• Qdrant hybrid queries (RRF and DBSF): https://qdrant.tech/documentation/concepts/hybrid-queries/
• Qdrant indexing: https://qdrant.tech/documentation/concepts/indexing/
• Qdrant README: https://github.com/qdrant/qdrant