pgvector vs OpenSearch vs Qdrant vs Weaviate: A Database Architect's Decision Matrix

The common failure is not choosing the “wrong” vector database. It is choosing one before the workload is understood. A customer-support RAG system with strict tenant filters, a product catalog with BM25 relevance history, and an internal document assistant over 40,000 pages are three different database problems wearing the same embedding vocabulary.

Short Version

There is no universal winner among pgvector, OpenSearch, Qdrant, and Weaviate.

Use pgvector when the source of truth is already PostgreSQL, consistency matters more than maximum vector throughput, metadata filters are relational, and the team wants one recovery model. Use OpenSearch when keyword search, product search, logs, or relevance-debugging workflows already live in search infrastructure and hybrid retrieval is the main problem. Use Qdrant when the workload is primarily vector retrieval, payload filtering, dense plus sparse retrieval, or multi-stage search with a clean service boundary. Use Weaviate when the object schema, named vectors, hybrid search, and multi-tenant retrieval model fit the application more naturally than relational tables or search indexes.

The decision should be made from the operating model backward: who backs it up, who pages on it, how tenants are isolated, how relevance is debugged, and how data is re-indexed after an embedding model change.

Situation

Vector search arrived through AI application teams, not database architecture review boards. Many first RAG systems were prototypes: chunk documents, embed chunks, store vectors, retrieve top-k, send context to an LLM. That path works until production requirements arrive.

The Problem

Production retrieval asks different questions:

• Does the answer need read-after-write consistency with the source record?
• Are filters selective enough to change recall?
• Is keyword matching still required for SKUs, error codes, names, and legal terms?
• Does every tenant need isolation, auditability, and export?
• Can the team restore the vector index to a known point in time?
• How expensive is full re-embedding and re-indexing?
• Can SREs explain bad results without reading model embeddings by hand?

Those questions are database questions. They are not solved by nearest-neighbor latency alone. Which of pgvector, OpenSearch, Qdrant, or Weaviate answers them depends on workload shape and the team’s existing operating model.

How It Works

The four choices sit at different points on the same architecture map.

flowchart TD
    Workload[retrieval workload] --> Consistency[needs source consistency]
    Workload --> Hybrid[needs lexical relevance]
    Workload --> Vector[mostly vector retrieval]
    Workload --> Object[object schema with many embeddings]
    Consistency --> PG[pgvector in PostgreSQL]
    Hybrid --> OS[OpenSearch search cluster]
    Vector --> QD[Qdrant vector service]
    Object --> WV[Weaviate object store]
    PG --> Ops[one database operating model]
    OS --> OpsSearch[search relevance operating model]
    QD --> OpsVector[vector service operating model]
    WV --> OpsObject[object retrieval operating model]

pgvector extends PostgreSQL with vector types and indexes. The advantage is co-location: documents, embeddings, ownership fields, tenant IDs, permissions, and transactional updates can live together. The risk is that approximate vector indexes and SQL filters interact in non-obvious ways, especially under selective filters.

OpenSearch starts from a search engine model. It is strong when the retrieval problem includes lexical search, analyzers, field boosts, faceting, product relevance, logs, or operational search workflows. The risk is operational gravity: shard sizing, mappings, refresh behavior, replicas, and relevance pipelines become the production surface.

Qdrant starts from vector search as a service. Its core model is collections, points, vectors, and payloads. It is a good fit when vector retrieval and payload filtering are the center of the workload, and when dense plus sparse retrieval or multi-stage query flows are first-class needs. The risk is that the source-of-truth system still has to be integrated, backed up, and reconciled.

Weaviate starts from objects with schema, vectors, filters, hybrid search, and optional named vectors. It can model one object with multiple embedding spaces more naturally than a flat chunk table. The risk is schema and operational commitment: once the application model lives in the vector database, migrations, tenancy, and backfills become platform work.

Decision Matrix

Criterion	pgvector	OpenSearch	Qdrant	Weaviate
Source-of-truth fit	Strong when PostgreSQL owns the data	Usually secondary index	Usually secondary index	Can become application retrieval store
Consistency	Strongest if vectors update in the same transaction	Near-real-time search semantics require design	Depends on ingestion pipeline	Depends on object ingestion and consistency model
Filtering	SQL filters, joins, partial indexes, partitions	Rich search filters, faceting, mappings	Payload filters and vector search	Object filters and tenant-aware queries
Hybrid search	Possible with Postgres full text plus vectors, more custom work	Strong fit when BM25 is already central	Strong fit for dense plus sparse and fusion	Built-in hybrid model with tunable weighting
Operational skillset	DBA team	Search platform team	Vector service platform team	Object/vector platform team
Backup and DR	PostgreSQL backup discipline	Snapshot and index recovery discipline	Snapshot and collection recovery discipline	Backup plus tenant and schema discipline
Cost shape	Database CPU, RAM, storage, index bloat	Cluster nodes, shards, replicas, storage, ingestion	Vector memory, storage, replicas, managed service cost	Vector index memory, object storage, modules, managed service cost
Tenancy	Row-level or schema-level patterns	Index, routing, filter, or cluster patterns	Payload filters, collections, or deployment boundaries	Multi-tenancy features and collection design

Architecture and Operating Model

The most reliable decision process starts with ownership.

If the DBA team already owns PostgreSQL recovery, audit, migrations, and performance tuning, pgvector is the lowest-friction starting point. The operating model is familiar: schema migrations, EXPLAIN, indexes, backups, PITR, connection pools, vacuum, and role-based access.

If a search team already owns OpenSearch for catalog search or log search, OpenSearch may be the right retrieval surface because the operational muscle already exists: analyzers, relevance explain, shard management, index templates, snapshots, and query profiling.

If the application needs a dedicated retrieval service with payload filtering and multiple vector representations, Qdrant can keep the retrieval boundary explicit. Platform engineering then has to treat it like any other stateful system: deployment topology, snapshots, security, client retries, capacity, and restore tests.

If product objects need multiple embedding spaces, object-level filters, hybrid search, and collection-level schema, Weaviate may reduce application plumbing. The cost is that schema evolution and vector backfills become part of the data platform lifecycle.

In Practice

The DBA question is: what is the recovery story?

For pgvector, embeddings are part of the database. A restore can bring back rows and vectors together. That is attractive for auditability, but vector indexes can increase memory pressure, maintenance cost, and query planning complexity.

For OpenSearch, Qdrant, and Weaviate, the vector store is usually a derived system. The source of truth is elsewhere. That means the platform needs a replayable ingestion pipeline, idempotent writes, versioned embeddings, and a tested rebuild path. If the vector store is lost, the business question is not “do we have a snapshot?” only. It is “can we rebuild the retrieval index from the source records and prove the rebuilt index answers the same?”

Security, Cost, Observability, and Failure Notes

Security starts with tenant boundaries and embedding content. Embeddings can leak sensitive source text through retrieval even when the raw document is hidden elsewhere. Every option needs authorization at retrieval time, not only at ingestion time.

Cost is dominated by duplication and rebuilds. Running a second stateful system means paying for storage, replicas, snapshots, monitoring, and ingestion compute. Re-embedding after model changes can become a batch workload with real cloud cost.

Observability should include query latency, index build time, recall sampling, empty-result rate, under-return rate after filters, ingestion lag, failed upserts, snapshot age, restore test age, and top expensive queries.

Failure modes usually come from drift: source row changed but embedding did not, document deleted but chunk remains searchable, tenant moved but payload filter is stale, or a relevance change ships without before-and-after query sets.

Where It Breaks

Bad decision	What happens in production	Better framing
Choose by benchmark only	Fast demo, weak recovery and tenancy model	Choose by workload and operating model
Choose pgvector for all workloads	PostgreSQL becomes search, vector, OLTP, and relevance lab at once	Keep pgvector for consistency-heavy retrieval
Choose OpenSearch for pure vectors	Search cluster complexity without lexical benefit	Use it when search relevance is already central
Choose Qdrant without source replay	Restore depends on undocumented application behavior	Build idempotent ingestion and rebuild tooling
Choose Weaviate without schema planning	Named vectors and collections evolve through risky backfills	Treat schema as a data contract

Decision Checklist

• Is PostgreSQL already the source of truth for the content and authorization model?
• Does the query require exact relational filters before vector ranking?
• Does lexical relevance still matter for identifiers, names, codes, and exact terms?
• Does the team already operate OpenSearch with relevance-debugging workflows?
• Does the retrieval service need dense plus sparse vectors, multivectors, or fusion?
• Does one object need multiple embedding spaces?
• Is every vector store write replayable from an authoritative source?
• Can the team restore from backup and validate retrieval quality after restore?
• Are tenant boundaries enforced in the retrieval layer and tested with negative cases?
• Is there a query set for regression testing relevance before every index change?

What to Do Next

Problem: Teams pick a vector database from a benchmark or a demo before the retrieval workload’s consistency, filtering, and recovery requirements are defined.

Solution: Choose from the operating model backward — start with pgvector when consistency and simplicity dominate, move to OpenSearch when search relevance and BM25 are central, use Qdrant when vector retrieval and payload filtering deserve their own service, and use Weaviate when object schema, named vectors, and hybrid retrieval fit the domain.

Proof: The chosen system’s recovery story can be explained in one sentence, and a restore drill returns the same top results as a saved query set.

Action: This week, write down the retrieval workload’s consistency requirement, filter selectivity, and recovery story before evaluating any vector database, then run the Decision Checklist above against the current or proposed system.

Sources to Verify

• pgvector README: https://github.com/pgvector/pgvector
• OpenSearch vector search documentation: https://docs.opensearch.org/latest/vector-search/
• Qdrant documentation: https://qdrant.tech/documentation/
• Weaviate documentation: https://docs.weaviate.io/weaviate