pgvector

pgvector is an open-source extension for PostgreSQL that adds vector similarity search to any existing Postgres database. Created by Andrew Kane in 2021 and released under the PostgreSQL License (a permissive open-source license similar to MIT), it lets you store high-dimensional embeddings as a native column type and run approximate nearest-neighbor queries using standard SQL operators. The extension is available at github.com/pgvector/pgvector, has over 13,000 GitHub stars as of April 2026, and is supported natively by Amazon RDS, Amazon Aurora, Google Cloud SQL, Azure Database for PostgreSQL, Supabase, and Neon, among others. There is no vendor, no subscription, and no per-query fee: cost is whatever you pay to run Postgres.

The extension adds three distance operators: <-> for L2 (Euclidean) distance, <#> for inner product, and <=> for cosine distance. It supports two index types: IVFFlat (partition-based approximate search requiring a training step) and HNSW (Hierarchical Navigable Small World, added in v0.5.0 in October 2023, which builds incrementally and delivers higher recall without a training phase). You can store vectors up to several thousand dimensions depending on version, making it compatible with embedding models from OpenAI, Cohere, Google, and others. Queries run inside Postgres, so you can JOIN vector results with your regular relational tables, apply row-level security policies, and use your existing connection pool and ORM without any new infrastructure.

What pgvector actually does in April 2026

pgvector's current stable release (v0.8.x) ships as a standard Postgres extension: one CREATE EXTENSION vector; command enables it in any compatible database. You define a vector column with a declared dimension count (embedding vector(1536) for OpenAI ada-002 embeddings, for example), insert embeddings alongside your regular data with a standard INSERT, and query using distance operators in a WHERE clause or ORDER BY. The HNSW index, added in October 2023, is now the recommended index type for production workloads over roughly 100,000 vectors. It supports concurrent inserts without a rebuild step and consistently delivers recall above 95 percent at reasonable query speeds. IVFFlat remains available for workloads where the training-phase cost is acceptable and memory is constrained. Both index types support parallel index creation in newer Postgres versions. The extension is actively maintained, with commits landing regularly and major cloud providers tracking new releases within weeks of publication.

Where pgvector sits versus Pinecone and Qdrant

The vector database market in April 2026 splits roughly into three camps: purpose-built managed services (Pinecone), open-source dedicated databases (Qdrant, Weaviate, Chroma), and Postgres extensions (pgvector). The tradeoffs are concrete and architectural.

pgvector vs. Pinecone: Pinecone is a closed-source, managed-only service built from the ground up for approximate nearest-neighbor search at scale. Its distributed architecture handles billions of vectors more smoothly than pgvector can inside a single Postgres instance. It ships real-time index updates, built-in metadata filtering wired directly into the index (not a post-query SQL WHERE clause), and a REST/SDK interface with no SQL. Serverless Pinecone starts nominally free but paid tiers begin around $70 per month once index sizes grow. The core tradeoff is performance ceiling and vendor lock-in versus the simplicity of staying inside Postgres. If you already have a Postgres application, Pinecone requires a new service, a new API client, a new billing relationship, and application code that queries two different data stores and correlates results. pgvector keeps everything in one place.

pgvector vs. Qdrant: Qdrant is an open-source, self-hostable vector database written in Rust, also available as a managed cloud service. It uses HNSW as its primary index (the same algorithm pgvector adopted in v0.5.0) but implemented specifically for vector workloads, which translates to higher raw QPS at equivalent recall, particularly under heavy concurrent load. Qdrant treats payload filtering as a first-class indexing primitive: metadata filters are wired into the HNSW traversal, not applied as a post-query filter. Benchmarks consistently show Qdrant outperforming pgvector on throughput at high concurrency. The cost is operational: Qdrant is a separate stateful service with its own deployment, storage format, API, and monitoring. You cannot JOIN Qdrant results with your Postgres user table in a single query; you fetch from Qdrant, then correlate in application code or with a second database round-trip. For teams with the DevOps bandwidth to manage another service and vector workloads that will push past 20-50 million rows, Qdrant is the stronger technical choice. For everyone else, pgvector's "it's just your Postgres" argument is hard to dismiss.

"We migrated from Pinecone to pgvector last quarter. Our p99 query latency is higher, but we eliminated an entire infra dependency and our monthly bill dropped by about $400. For our scale, under 5M vectors, it's been the right call." -- throwaway_ml_eng, Hacker News, November 2023

What the day-to-day workflow reality looks like

The most common pgvector workflow is a RAG (retrieval-augmented generation) pipeline: chunk documents, generate embeddings via an API call to OpenAI or Cohere, store the embedding and source text in a Postgres table, and then at query time generate an embedding for the user's question and retrieve the top-K closest chunks to inject into an LLM prompt. With pgvector this is a single SQL query. The embedding lives in the same database as your users, documents, permissions, and audit logs. Row-level security applies automatically. Your existing Postgres monitoring (pg_stat_statements, slow query logs, Datadog, etc.) covers vector queries. Migrations are just ALTER TABLE statements.

The October 2023 v0.5.0 release, which added HNSW indexing, was the moment the community broadly judged pgvector production-ready. Before that release, IVFFlat was the only approximate index option. IVFFlat requires an explicit training step (SET ivfflat.probes) after loading your data, degrades recall at low probe counts on large datasets, and cannot update incrementally without periodic retraining. Multiple production outages and blog posts from 2022-2023 traced back to IVFFlat recall degradation as collections grew. HNSW eliminated the training requirement and raised the bar on practical recall. The GitHub issue thread announcing v0.5.0 accumulated hundreds of comments within days, with teams reporting immediate relief from long-standing production issues.

"The HNSW index support in 0.5.0 was the thing that made pgvector actually usable for us. Before that we were hitting full table scans on anything over a million rows. After HNSW it's night and day." -- datasci_pete, GitHub issue thread, pgvector/pgvector, late 2023

Who pgvector is built for

pgvector fits teams who already operate Postgres and want vector search without adding a new service to their stack. This covers a large portion of the startup and scale-up market: anyone on Supabase, Neon, RDS, Cloud SQL, or a self-managed Postgres instance can enable pgvector with a single command and start storing embeddings the same day. It fits RAG pipelines, semantic search features, recommendation engines, and duplicate-detection workflows at scales up to roughly 10-20 million vectors with acceptable query performance. It is particularly well-suited for multi-tenant SaaS applications where Postgres's row-level security policies provide per-customer data isolation without any custom access control layer in the vector layer. Teams with limited DevOps bandwidth who cannot justify managing another stateful service will find pgvector's operational simplicity compelling even when the performance numbers are not the best in class.

What pgvector is not

pgvector is not a replacement for purpose-built vector databases at high scale or under heavy concurrent write loads. At 50 million vectors and above, or in applications where the vector store is queried thousands of times per second, pgvector's Postgres query planner overhead and MVCC-based concurrency become measurable constraints. Teams in this situation consistently report migrating to Qdrant (self-hosted) or Pinecone (managed) rather than tuning their way around pgvector's limits.

pgvector does not ship native hybrid search. For RAG pipelines that need BM25 keyword ranking combined with vector similarity (a pattern increasingly standard in production retrieval systems as of 2025-2026), you have to assemble the pieces yourself using Postgres full-text search, pg_trgm, or an external BM25 index, then fuse scores in application code. Dedicated systems like Weaviate and Elasticsearch ship hybrid search as a first-class mode with tunable alpha parameters. If hybrid retrieval is central to your product, pgvector requires meaningful extra engineering to match what dedicated systems provide out of the box.

pgvector also does not help you if your application is not on Postgres. If your primary datastore is MongoDB, MySQL, Cassandra, or a pure object store, there is no pgvector for you: you need a dedicated vector database or a managed service.