Compare vector stores with your workload, not a ranking table

A comparison table says one vector database is “fastest” and another is “best for production.” Without the dataset, hardware, query settings, and operational requirements, those labels tell you little about your application.

Before you begin: Understand vector records, approximate search, and metadata filters.

Make candidates eligible first

Write the non-negotiable requirements: where data may be stored, supported deployment model, access controls, backup needs, filter behavior, and compatibility with existing infrastructure. Exclude candidates that cannot meet them before running a speed test.

The following map was reviewed against official documentation on September 10, 2026. It describes starting points to investigate, not measured rankings or permanent feature guarantees.

Exact features, limits, and pricing change. Use the linked official references for the version and plan you actually evaluate.

Build one shared test collection

Use the same source records, vectors, IDs, and metadata across candidates. Include selective filters, updated documents, deleted records, and multiple access scopes. Establish exact nearest-neighbor results under the chosen metric before tuning approximate indexes.

Run a separate task-relevance evaluation too. Recovering the exact vector top ten measures index fidelity; finding the evidence a learner needs measures retrieval usefulness. These are different targets.

Measure the request users experience

Record typical and slow-tail latency, successful query rate, filtered recall, ingestion time, update visibility, memory or service usage, and operational failures. Use a realistic query mix and concurrency level. A single warmed query against a tiny unfiltered collection is not representative of every workload.

Keep embedding generation separate when measuring the database, then include it in an end-to-end application measurement. Otherwise one candidate may appear slower because the experiment includes a model call that the other excludes.

Test the lifecycle

Insert a new version of a notice and verify when queries return it. Delete a record and verify it disappears under the intended consistency rules. Restore a backup or rebuild from source records in a test environment. Check what happens during a partial ingestion failure.

For multi-user data, test access scopes in the actual query path. A metadata field named user_id is not automatically an authorization policy. The trusted application or database policy must enforce the scope, including direct record retrieval.

Include the cost of operating the choice

Managed services can reduce infrastructure work while introducing service-specific limits and charges. Self-hosting gives different control but requires upgrades, capacity planning, monitoring, and recovery. An existing database may reduce the number of systems your team operates.

Estimate cost from the measured workload and current pricing or hardware assumptions. Do not publish invented monthly totals or generic requests-per-second numbers. State what is included: replicas, backups, storage, query load, and staff effort where you can estimate it responsibly.

Make the decision reversible

Keep canonical source text and IDs outside an opaque index export alone. Record embedding and chunking versions. Build an adapter around the operations your application actually needs, rather than trying to hide every product-specific feature behind a universal API.

Next, we will examine a decision that often affects retrieval more than the database brand: where a document is split.

Official references

pgvector, Chroma, Qdrant, Weaviate, and Pinecone document their current systems. No cross-vendor benchmark was run for this lesson.

Continue to the next lesson.