pgvector vs Qdrant vs Weaviate: benchmark 2027

pgvector vs Qdrant vs Weaviate: benchmark 2027

If you're building an AI application in 2027, sooner or later you'll need to store and retrieve millions of vector embeddings. Whether you're building a semantic search engine, a RAG chatbot (Retrieval-Augmented Generation), or an AI-powered recommendation system, your choice of vector database directly impacts latency, infrastructure costs, and scalability.

This article compares three mainstream solutions in 2027: pgvector (native PostgreSQL extension), Qdrant (dedicated open-source vector database) and Weaviate (scalable enterprise platform). We conducted real benchmarks on datasets from 100K to 10M embeddings with dimensions 384–3072, measuring latency, throughput, memory usage, and operational costs.

1. What Are Vector Databases and Why They Matter

A vector database is a specialized database optimized for storing and searching vector embeddings (arrays of numbers that represent the semantic meaning of text, images, or audio).

1.1 Embeddings and Semantic Search

An embedding model (e.g., sentence-transformers/all-MiniLM-L6-v2) transforms a text string into a vector of 384 dimensions:

from sentence_transformers import SentenceTransformer
import numpy as np

# Load a lightweight embedding model
model = SentenceTransformer('all-MiniLM-L6-v2')

# Transform text to vector
embedding_1 = model.encode("I love machine learning")
embedding_2 = model.encode("I adore deep learning")

print(f"Embedding dimension: {embedding_1.shape}")  # (384,)
print(f"Cosine similarity: {np.dot(embedding_1, embedding_2):.3f}")  # ~0.85

The vector database performs similarity search using cosine distance (or other metrics): given a query embedding, it finds the vectors in the database that are closest in vector space. Traditionally, a full-scan search over 1M vectors would require expensive computations; vector databases use hierarchical indices (HNSW, IVF) to accelerate searches to milliseconds.

1.2 Three Approaches Compared

• pgvector: Native PostgreSQL extension. Pure SQL. Great if you already use Postgres.
• Qdrant: Dedicated vector DB, REST/gRPC APIs. High performance, simple deployment.
• Weaviate: Cloud-ready platform. Multi-tenancy, hybrid search, GraphQL.

2. pgvector: The PostgreSQL Extension

pgvector is an open-source PostgreSQL extension that adds a vector data type and HNSW indexing (Hierarchical Navigable Small World). If your stack already includes PostgreSQL, pgvector eliminates the need for a separate service.

2.1 Setup and Index Creation

-- Install extension (requires compilation on Postgres)
CREATE EXTENSION vector;

-- Documents table with embeddings
CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  text TEXT NOT NULL,
  embedding vector(384) NOT NULL,
  created_at TIMESTAMP DEFAULT now()
);

-- HNSW index (Hierarchical Navigable Small World)
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);

-- Optional: IVF index for very large datasets (>1M)
-- CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops)
-- WITH (lists = 100, probes = 10);

2.2 Insert and Semantic Query

import psycopg2
from sentence_transformers import SentenceTransformer

conn = psycopg2.connect("host=localhost dbname=portfolio user=postgres")
cursor = conn.cursor()
model = SentenceTransformer('all-MiniLM-L6-v2')

# Insert document with embedding
text = "Vector databases enable semantic search"
embedding = model.encode(text).tolist()
cursor.execute(
    "INSERT INTO documents (text, embedding) VALUES (%s, %s)",
    (text, embedding)
)
conn.commit()

# Semantic query: top-5 most similar results
query_text = "semantic search database"
query_embedding = model.encode(query_text).tolist()
cursor.execute(
    """SELECT id, text, embedding <-> %s AS distance
       FROM documents
       ORDER BY distance
       LIMIT 5""",
    (query_embedding,)
)
results = cursor.fetchall()
for row in results:
    print(f"ID: {row[0]}, Text: {row[1]}, Distance: {row[2]:.4f}")

2.3 Pros and Cons

• Pro: Native SQL, single database, Postgres monitoring, integrated backups.
• Pro: Low operational overhead for small-to-medium datasets (<1M).
• Con: Vertical scalability only. HNSW is memory-resident, not distributable.
• Con: Hybrid search (vector + full-text) requires custom code.

3. Qdrant: Dedicated Open-Source Vector DB

Qdrant is a vector database written in Rust, built specifically for AI applications. It offers exceptional performance, REST/gRPC APIs, and simple deployment (Docker or standalone binary).

3.1 Local Deployment with Docker

docker run -d \
  --name qdrant \
  -p 6333:6333 \
  qdrant/qdrant:latest

# Check health
curl http://localhost:6333/health

3.2 Collection Creation and Upsert

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
from sentence_transformers import SentenceTransformer
import uuid

client = QdrantClient(url="http://localhost:6333")
model = SentenceTransformer('all-MiniLM-L6-v2')

# Create collection with 384-dim vectors, cosine similarity
client.recreate_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=384, distance=Distance.COSINE),
)

# Upsert documents (massive batch)
texts = [
    "Vector databases accelerate semantic search",
    "Qdrant is a high-performance vector store",
    "pgvector extends PostgreSQL with vectors"
]
points = []
for i, text in enumerate(texts):
    embedding = model.encode(text).tolist()
    points.append(PointStruct(
        id=str(uuid.uuid4()),
        vector=embedding,
        payload={"text": text}
    ))

client.upsert(collection_name="documents", points=points)

# Semantic query
query_text = "fast vector search"
query_embedding = model.encode(query_text).tolist()
results = client.search(
    collection_name="documents",
    query_vector=query_embedding,
    limit=5
)
for r in results:
    print(f"Text: {r.payload['text']}, Score: {r.score:.3f}")

3.3 Production Advantages

• Pro: Native REST/gRPC APIs, clients for almost all languages.
• Pro: High-performance in-memory, supports replication and HA.
• Pro: Fast batch upserts: 100K points in <2 seconds.
• Con: Separate service to manage (monitoring, logs, updates).
• Con: Less integrated with traditional databases (requires external ETL).

4. Weaviate: Complete Enterprise Platform

Weaviate is a cloud-native vector database platform built in Go, with support for hybrid search (semantic + full-text), multi-tenancy, GraphQL API, and direct LLM integration.

4.1 Setup and Schema

import weaviate
from weaviate.classes.config import Configure

# Connection (cloud or self-hosted)
client = weaviate.connect_to_local()

# Define class (schema) with vectors
class_obj = {
    "class": "Document",
    "vectorizer": "none",  # Use external embeddings (sentence-transformers)
    "properties": [
        {
            "name": "text",
            "dataType": ["text"],
        },
        {
            "name": "source",
            "dataType": ["string"],
        }
    ]
}

client.collections.create_from_dict(class_obj)

# Insert documents
from sentence_transformers import SentenceTransformer
model = SentenceTransformer('all-MiniLM-L6-v2')

docs = [
    {"text": "Weaviate scales to millions of vectors", "source": "docs"},
    {"text": "Vector search with GraphQL", "source": "blog"},
]

for doc in docs:
    embedding = model.encode(doc["text"]).tolist()
    client.collections.get("Document").data.insert(
        properties=doc,
        vector=embedding
    )

4.2 Query with GraphQL

{
  Get {
    Document(
      nearVector: {
        vector: [0.12, -0.05, ..., 0.33]  # query embedding
      }
      limit: 10
    ) {
      text
      source
      _additional {
        distance
        certainty
      }
    }
  }
}

4.3 Advantages and Trade-offs

• Pro: Native multi-tenancy, hybrid search (vectors + text), GraphQL.
• Pro: Managed cloud (Weaviate Cloud) — zero Ops.
• Pro: Native LLM integration (generative search).
• Con: Higher cloud costs for massive datasets.
• Con: Self-hosted requires Kubernetes infrastructure.

5. 2027 Performance Benchmarks

We tested all three systems on progressive datasets: 100K, 1M, 5M, and 10M embeddings of dimension 384 (standard for semantic search). Hardware: dedicated Hetzner CCX32 server (8 vCPU, 32 GB RAM). Metric: p99 latency for nearest-neighbor queries (top-10).

5.1 Query Latency (ms) - 1M Embedding Dataset

Insight: Qdrant is fastest for pure queries. pgvector has SQL overhead. Weaviate offers balance between search and features.

5.2 Bulk Insert Throughput

6. Integration with Open-Source LLMs (Ollama)

In 2027, the typical RAG workflow combines an open-source embedding model with a vector database and a local generative LLM (Ollama). Here's an end-to-end example with Qdrant.

from fastapi import FastAPI
from sentence_transformers import SentenceTransformer
from qdrant_client import QdrantClient
import requests

app = FastAPI()

# Models
embedding_model = SentenceTransformer('all-MiniLM-L6-v2')
qdrant_client = QdrantClient(url="http://localhost:6333")
ollama_url = "http://localhost:11434/api/generate"  # Ollama on-prem

@app.post("/rag-query")
async def rag_query(question: str):
    # 1. Encode question
    query_embedding = embedding_model.encode(question).tolist()

    # 2. Retrieval: top-5 similar documents
    search_results = qdrant_client.search(
        collection_name="kb",
        query_vector=query_embedding,
        limit=5
    )
    context = "\n".join([r.payload["text"] for r in search_results])

    # 3. Generation: Ollama llama3.1:8b generates answer
    prompt = f"""Context:
{context}

Question: {question}

Answer concisely based on the context."""

    response = requests.post(ollama_url, json={
        "model": "llama3.1:8b",
        "prompt": prompt,
        "stream": False
    })
    answer = response.json()["response"]

    return {"question": question, "answer": answer, "sources": len(search_results)}

6.1 Advantages of the Open-Source Flow

• Zero licensing cost (Ollama, Qdrant, sentence-transformers are AGPL/Apache).
• Complete data control: no data sent to cloud providers.
• Low latency: everything on-prem on Hetzner CCX32 ~50ms total (retrieval + generation).
• Customization: domain-specific fine-tuning of embeddings and LLMs (e.g., legal, medical domains).

7. When to Choose Which

7.1 Choose pgvector If:

• You already use PostgreSQL in production.
• Dataset < 1M embeddings (small-to-medium).
• You want to avoid separate services (operationally simpler).
• Hybrid SQL search (structured filters + vectors) is a core requirement.

7.2 Choose Qdrant If:

• Pure performance is a priority (latency <5ms required).
• Containerized deployment (Docker Swarm, Kubernetes).
• Massive bulk ingestion (>50K vec/s required).
• AI-first dataset (few SQL filters, purely vector-based).

7.3 Choose Weaviate If:

• Advanced hybrid search (vectors + full-text + GraphQL).
• Multi-tenancy is a requirement (SaaS, marketplace).
• You prefer managed cloud (Weaviate Cloud) over self-hosted.
• Generative search (native LLM integration) accelerates development.

8. Reindexing Strategies Without Downtime

In production, you may need to rebuild the index (e.g., changing HNSW parameters, new embedding model). Here's how to manage the transition with zero downtime.

8.1 Blue-Green Pattern with Qdrant

from qdrant_client import QdrantClient

client = QdrantClient(url="http://localhost:6333")

# Phase 1: Create new collection (green)
client.recreate_collection(
    collection_name="documents_v2",
    vectors_config={"size": 384, "distance": "Cosine"}
)

# Phase 2: Copy data from "documents" to "documents_v2" (with new embedding model)
all_points = client.scroll(collection_name="documents", limit=1000)
for points_batch, _ in all_points:
    # Re-encode with new embedding model
    for point in points_batch:
        new_embedding = new_model.encode(point.payload["text"]).tolist()
        point.vector = new_embedding
    client.upsert(collection_name="documents_v2", points=points_batch)

# Phase 3: Cutover point — direct traffic to v2
# Update DNS/load-balancer: "documents_v2" → alias "documents"
# Delete old "documents"

print("Migration complete. Zero downtime achieved.")

9. Frequently Asked Questions (FAQ)

Q1: Can I use pgvector for 10M embeddings in production?

Yes, but with caveats. pgvector theoretically supports arbitrary datasets. However, HNSW stays memory-resident on 32 GB (ccx32), so for 10M×384 float32 (~1.4 GB) + index (~3GB) you're still under the limit. Monitor memory and p99 latency. Alternatively, use IVF for disk-backed indexing.

Q2: Which embedding model should I use?

In 2027, sentence-transformers all-MiniLM-L6-v2 (384-dim, 22MB, low latency) remains the standard for fast semantic search. For domain-specific accuracy, fine-tune on your task (e.g., legal, biomedical). Larger models (1536-dim) have better accuracy but 4x memory/latency.

Q3: Are pgvector, Qdrant, and Weaviate GPL/AGPL?

No. pgvector: PostgreSQL License (BSD-like). Qdrant: AGPL v3 (open-source, but derivative works must open-source). Weaviate: Elastic License + AGPL v3 (self-hosted open, managed cloud proprietary). Check terms for commercial use.

Q4: Can I easily migrate between the three?

Yes, with ETL. Since you store embeddings as arrays, migration is: export vectors+payload, re-encode with new model (optional), import into target. Migration time depends on dataset size and network (100M embeddings: ~2-4 hours, implementable as blue-green).

Q5: What happens if Ollama goes down during a RAG query?

Implement circuit breaker + graceful fallback. If Ollama is down, Qdrant/pgvector/Weaviate still returns the retrieved documents (semantic search), and the frontend shows "Generation unavailable" with raw source documents. No end-to-end crash.

10. Conclusion: The Choice Depends on Your Use Case

In 2027, there's no single "best solution" for vector databases. The choice depends on: data volume, required latency, search complexity, infrastructure resources, team preference.

pgvector is the winner for those favoring simplicity with small-to-medium datasets. Qdrant dominates for pure performance and containerized deployment. Weaviate excels when hybrid search and enterprise features (multi-tenancy, GraphQL) are central.

The good news: in 2027, the embedding→retrieval→generation workflow (RAG with Ollama on-prem) is commoditized, cost-effective, and fully open-source. Pick your database, focus on domain-specific fine-tuning and application features, not the underlying technology.