pgvector vs Pinecone, Weaviate, Qdrant in 2026

pgvector, Pinecone, Weaviate and Qdrant all serve the same function, finding the closest vectors to a query, with incompatible architectures between them. The table below compares what remains true over time: deployment model, data location, search capabilities. Prices and precise version numbers for Pinecone, Weaviate and Qdrant are deliberately absent: check them on the official sites before making any purchasing decision.

Conceptual diagram of the two possible topologies. It does not encode any encrypted data, only the deployment architecture.

Element checked in the Aurabase code: the pgvector version embedded in the Postgres image of each project is 0.8.6. It is delivered by the standard upstream CNPG image, not added specifically by Aurabase. This fact is noted in the Dockerfile of the repository, on August 23, 2026. The official pgvector repository also confirms a maximum dimension of 16,000 per vector. This is well above the three dimension classes (768, 1536, 3072) used by Aurabase's native RAG pipeline. This pipeline is an application addition specific to Aurabase, built on top of pgvector.

pgvector adds a vector(n) column type and distance operators (<=> cosine, <-> euclidean, <#> dot product) to a normal Postgres base. Your vectors share the same table, the same transaction and the same constraints as the rest of your schema: nothing to synchronize to an external system.

For fuzzy searching, pgvector offers two index types to choose from. IVFFlat divides the vector space into lists by clustering and searches only in the lists closest to the query. Its construction is lighter, but you must choose a number of lists adapted to the volume of data. HNSW constructs a multi-level neighbor graph, without a prior training step, at the cost of a more memory-intensive construction. For details of the adjustment parameters (m, ef_construction), see our guide dedicated to the HNSW index.

-- Extension and vector column (dimension 1536, e.g. text-embedding-3-small)
CREATE EXTENSION IF NOT EXISTS vector;
ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- HNSW index for fuzzy searching
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- Vector search joined to a relational table, filtered by RLS
SELECT d.id, d.content
FROM documents d
JOIN projects p ON p.id = d.project_id
WHERE p.owner_id = auth.uid()
ORDER BY d.embedding <=> $1
LIMIT 5;

The last line is the structuring point: the WHERE p.owner_id = auth.uid() clause applies to vector search exactly as it does to any other query. No dedicated vector database reproduces this behavior natively, since your RLS policies live in Postgres, not in a third-party service. To build a complete RAG pipeline based on this, see our RAG pipeline tutorial with pgvector.

Pinecone is a vector base offered exclusively as a proprietary cloud service. There is no public self-hosted version: your vectors live in Pinecone's infrastructure, not yours. This is an architectural choice assumed by the publisher, not a temporary limitation.

The compromise is direct. Zero vector infrastructure operations to manage: no cluster to size, no indexes to run yourself. In exchange, two hidden costs often appear after the fact. First, a synchronization pipeline to build and maintain between your main database and the Pinecone index, with its own consistency logic in the event of partial failure. Next, a proprietary format and API: migrating out of Pinecone means re-exporting the entire vectors and rebuilding the integration elsewhere.

Weaviate is a dedicated, open source and self-hosting vector database, also available as a managed cloud offering (Weaviate Cloud) for those who prefer not to operate it themselves. Its feature most highlighted by the publisher is native hybrid search. It merges, in a single classification of results, a vector similarity score and a BM25 type keyword correspondence score.

Concretely, this avoids writing the fusion logic between semantic search and keyword search yourself, a step that other approaches leave to the application. Weaviate also offers a system of modules to directly connect external embedding providers at the time of ingestion. The compromise remains the same as for any dedicated database: an additional system to operate or pay for, to keep synchronized with your main data source.

Qdrant is a dedicated vector database, open source and written in Rust, also available in self-hosting or in a managed cloud (Qdrant Cloud). Like the core of Aurabase, Qdrant is written in Rust: a shared language choice, not an argument of superiority in itself.

Two points come up most often in feedback on Qdrant. First, a rich payload filtering system: it allows you to combine structured filters (category, date, status) and vector search in the same query. Next, quantization options (scalar or binary), intended to reduce the memory footprint of a large-scale index. Same compromise as Weaviate: a system separate from your main database, with its own synchronization logic to maintain.

Choose pgvector if…

• Your vectors must remain attached to your relational data (users, permissions, products)
• Your RLS policies should also apply to vector search results
• You don't want to add a system to sync on top of Postgres

Choose Pinecone if…

• You want zero vector infrastructure operations
• Locking in a closed proprietary format is not a problem for your team
• You agree to build a sync pipeline to an external service

Choose Weaviate if…

• You want a hybrid keyword + native vector search, without rebuilding it yourself
• Your use case is a standalone search engine, not a functionality added to an existing app
• You are ready to operate or pay for a dedicated service in addition to your main base

Choose Qdrant if…

• Rich filtering by payload is a determining criterion at your scale
• Memory quantization counts for a very large vector index
• You want an open source engine where you maintain control of the code

Aurabase does not add pgvector: the extension is already present in the standard Postgres image provided by CloudNativePG, the foundation used for tenant clusters. What Aurabase builds on top is application functionality: an ingestion pipeline with network error management, an embeddings module, and vector search by HNSW index. This capability is natively exposed in the aura-aiservice, verified in the repository code on August 23, 2026.

The Aurabase RAG pipeline supports three classes of embedding dimensions (768, 1536, 3072), corresponding to the most common output sizes of current embedding models. Each vector remains a column of a normal Postgres table, in the project schema, under the same RLS policies as the rest of this project's data. This is the same logic as the SQL example in section 02, applied to an entire pipeline rather than an isolated query.

pgvector, Pinecone, Weaviate and Qdrant do not cover the same need. pgvector removes synchronization by keeping the vectors in Postgres, at the cost of a less specialized engine than a dedicated product. Pinecone withdraws all infrastructure operations, in return for total proprietary lock-in. Weaviate adds native hybrid search out of the box. Qdrant emphasizes rich filtering and large-scale memory footprint. The deciding criterion remains the same in all four cases: where your data should live, and who should be able to filter it.

To build a complete RAG pipeline on this basis, our RAG pipeline tutorial with pgvector details ingestion, embeddings and vector search step by step. For the overview of Aurabase's native AI pillar, see the Native AIpage.