Solutions for
Please select
Try the Web App
ki-werkzeuge

Vector Databases Compared

Redaktion ·

Why you need a database built for columns of numbers — and why that matters to you

The moment you build anything around semantic search, RAG or recommendations, you run into a class of database that does not search by strings, IDs or date fields, but by similarity. A vector database does not store “the word apple”; it stores a list of several hundred to several thousand floating-point numbers that represent the meaning of “apple” in a model’s space. And it can find the most similar stored vectors for any query in milliseconds — even across a collection of millions of entries.

That is the difference from classic full-text search. A relational database finds documents that contain the word “notice period”. A vector database finds documents that are about notice periods — even when they say “ending a contract” or “opting out”. This semantic proximity is the foundation of nearly every modern AI retrieval system.

This article explains the core mechanics (embeddings, distance metrics, ANN indexes), compares the five most important options — Chroma, Weaviate, Milvus, Qdrant and pgvector — head to head, and offers a decision aid along the axes the choice actually hinges on. As of June 2026. Feature sets move fast; the selection criteria stay stable.

From text to vector — the embedding

It starts with the embedding: a model turns a piece of text (or an image, an audio snippet) into a fixed vector — roughly 384, 768, 1024 or 3072 dimensions, depending on the model. Similar inputs land close together in that space, dissimilar ones far apart. The vector database stores these vectors together with an ID and optional metadata (source, date, category, access rights).

Important: the database usually does not generate the embeddings itself. You call an embedding model (OpenAI, Cohere, or a self-hosted model) and write the result in. Some databases ship integrated embedding modules that wrap this step — that is convenience, not a mandatory feature.

Distance metrics — how “similarity” is measured

Similarity between two vectors is computed via a distance metric. Three are common:

  • Cosine (cosine similarity): measures the angle between vectors, ignores their length. The default for text embeddings.
  • Dot product: fast, and it also accounts for magnitude. Often used with normalized vectors, in which case it is equivalent to cosine.
  • Euclidean (L2): geometric distance. Common with image embeddings.

Which metric is correct is dictated by the embedding model — not the database. Picking the wrong metric is a frequent and silent mistake: the search still returns results, just worse ones, without anything crashing.

ANN instead of exact search — the actual trick

With a million vectors at 1024 dimensions each, comparing every query against every entry exactly (brute force) would be too slow. So vector databases use ANN (Approximate Nearest Neighbor): index structures that almost always find the right hits, but dramatically faster. The best-known index is HNSW (Hierarchical Navigable Small World) — a multi-layer graph the search navigates from coarse to fine. Alongside it sit IVF (Inverted File, clustering) and disk-based approaches like DiskANN that do not have to keep the whole index in RAM.

The trade-off is recall vs. speed: recall is the fraction of the true nearest neighbors the index returns. 99% recall means 1% of the best hits are missed — invisible for most RAG applications, in exchange for being orders of magnitude faster than exact search. This dial (in HNSW via parameters like ef_search) is the heart of performance tuning.

The axes the choice actually hinges on

Before comparing individual systems, a clear set of axes helps. Marketing pages love to blur them together.

Self-hosted vs. managed

Do you run the database yourself (Docker, Kubernetes, bare metal) or buy it as a cloud service? Self-hosted gives you full control and data sovereignty, but costs operational effort — backups, scaling, updates. Managed takes that off your plate, but ties you to a vendor and moves sensitive data into their cloud. Almost all of the systems mentioned here come in both flavors.

Embedded vs. server

Some systems run as a library directly inside your application’s process (embedded, like SQLite). Others are standalone servers that multiple clients talk to over the network. Embedded is ideal for prototypes and small datasets, server for production and concurrent access.

Filtering — metadata plus vector

In practice you rarely search purely semantically. You want “the most similar documents, but only from 2026, only category Legal, only the ones this user is allowed to see”. This filtered ANN is technically tricky, because filters and index navigation can interfere with each other. How well a system handles pre-filtering (filter first) and post-filtering (filter after the search) is a hard differentiator.

Pure vector search is poor at exact terms, product numbers, rare proper nouns. Hybrid search combines vector similarity with classic keyword search (BM25) and merges the results. For many production applications that is a bigger quality lever than the last percent of recall.

Scaling

Up to a few million vectors almost everything is fast enough. The differences show up in the tens of millions and beyond — that is where what runs on a single node separates from what scales horizontally across a cluster.

The five options in profile

pgvector — vector search inside Postgres

pgvector is an extension for PostgreSQL, not a standalone system. The appeal: if your app already uses Postgres, you get vector search without a second database, without a sync problem, with transactional consistency and full SQL including JOIN and WHERE. Filtering over metadata is trivial — it is simply a SQL condition.

The limit shows up in scaling. Standard HNSW in pgvector becomes noticeably slower above roughly 5–10 million vectors according to benchmarks, and the index should fit in RAM for good performance — for 50 million vectors at 768 dimensions that is roughly 150 GB+ of memory. The pgvectorscale extension (from Timescale) pushes that ceiling up significantly: it brings StreamingDiskANN, a disk-based index, and reaches around 471 QPS at 99% recall on 50 million vectors per the Timescale benchmark (May 2025) — closing the gap to dedicated systems. These figures come from the vendor; measure them in your own workload.

Qdrant — fast and Rust-based

Qdrant is a dedicated vector database written in Rust, focused on speed and mature filtering. In common 2026 benchmarks Qdrant leads among the open-source options: at 10 million vectors a P99 latency around 12 ms is reported, versus 16 ms (Weaviate) and 18 ms (Milvus) — roughly 10–25% faster on comparable workloads. The Rust foundation shows in those latencies. Available self-hosted and as Qdrant Cloud. A good pick when vector search sits at the center of a new app and speed matters.

Weaviate — strong at hybrid search

Weaviate is a dedicated vector database with a particular focus on hybrid search and integrated embedding modules (text, image, multimodal). If you want vector and keyword search combined out of the box without wiring it up yourself, Weaviate plays to its strength. Latency sits just behind Qdrant, but the feature set around hybrid and modularity is richer. Available self-hosted and as a managed cloud.

Milvus — for billion-scale

Milvus is the heavyweight option for very large datasets. The architecture is built for horizontal scaling (distributed nodes, separation of storage and compute) and targets billions of vectors. The price is operational complexity: running Milvus at full tilt presumes an ops team. For small to medium projects it is overkill; for genuine big-scale search with a dedicated operations team it is the right call. The hosted service Zilliz Cloud takes some of the complexity off your hands.

Chroma — the prototyping favorite

Chroma is tuned for developer friendliness: embedded and ready to go in a few lines of Python, ideal for local experiments and small RAG prototypes. Production readiness grew markedly through 2025 and 2026 (server mode, a hosted variant), but for seriously large workloads Chroma still trails Qdrant and Weaviate. Its strength is the fast start, not the last rung of scaling.

Comparison table

| System | Type | Strength | Scaling | Hybrid search | Operations | |---|---|---|---|---|---| | pgvector | Postgres extension | No second DB, full SQL | up to ~10M (much more with pgvectorscale) | via SQL/extensions | low, if Postgres is already there | | Qdrant | dedicated (Rust) | speed, filtering | very good (distributed) | yes | medium | | Weaviate | dedicated | hybrid search, modules | very good | strongly integrated | medium | | Milvus | dedicated (distributed) | billion-scale | extreme | yes | high (ops team) | | Chroma | embedded/server | fast start | small to medium | limited | very low |

The latency and QPS figures in the text come from public 2025/2026 benchmarks (see sources) and depend heavily on hardware, dimensionality and recall target. Treat them as orders of magnitude, not guarantees — measure in your own workload.

Decision aid for four situations

You already have Postgres and under ~50M vectors: pgvector. No second database, transactional consistency, filtering via SQL. As load grows, add pgvectorscale.

Vector search is the core of a new app, medium scale, speed matters: Qdrant. If hybrid search is the lever instead: Weaviate.

You are prototyping in Python and want something working fast: Chroma. Migrate later if needed.

Billions of vectors and a real ops team: Milvus (or Vespa as an alternative).

Pitfalls

  • Wrong distance metric: a metric that does not match the embedding model quietly returns worse hits. Check the model’s spec sheet.
  • Index dimensioned too small: HNSW parameters (m, ef_construction, ef_search) determine recall and speed. Defaults are rarely optimal for your own dataset.
  • Filtering underestimated: realizing late that you need pre-filtering can force a migration. Clarify the filter requirements up front.
  • Embeddings not versioned: if you swap the embedding model, old and new vectors are incompatible. You have to re-embed the entire corpus.
  • RAM demand underestimated: if the HNSW index does not fit in memory, performance collapses. Do the math before scaling.

FAQ

Do I even need a dedicated vector database?
Not necessarily. For a few thousand vectors an in-memory search or pgvector in your existing Postgres instance is often enough. A dedicated vector database pays off once data volume, filtering needs or latency requirements outgrow the simple solution.
What is the difference between a vector database and RAG?
RAG (Retrieval-Augmented Generation) is the overall concept: retrieve relevant documents and hand them to a language model as context. The vector database is one component within it — the store from which retrieval fetches the most similar chunks. RAG additionally needs chunking, embedding and often reranking.
What does HNSW mean?
Hierarchical Navigable Small World — a graph-based ANN index. The search navigates several layers of a graph from coarse to fine neighborhoods and so finds the approximate nearest neighbors very quickly. Today's most widely used index for vector search.
Cosine or dot product — which do I pick?
The embedding model dictates it. For normalized vectors both are equivalent; many text models recommend cosine. When in doubt, follow the model provider's recommendation rather than guessing.
Can pgvector keep up with dedicated databases?
Into the low tens of millions yes, especially with pgvectorscale and the disk-based DiskANN index. At hundreds of millions to billions of vectors with high throughput demands, dedicated distributed systems like Milvus still have the edge.

Conclusion

Vector databases are the backbone of semantic search and of RAG. The mechanics are the same everywhere — embeddings in, ANN index, similarity search with a recall-speed trade-off. The difference lies in operations, filtering, hybrid search and scaling. For most teams the most honest answer is: start with pgvector if Postgres is there; move to Qdrant or Weaviate when vector search becomes the core; reach for Milvus only when scale truly forces it. Choose by your real requirements, not by the benchmark with the biggest number.

Themenuebersicht

KI-WerkzeugeVektor-Datenbanken