pgvector Review (2026): Honest Assessment from BearPlex Engineers
pgvector is our default vector database recommendation for teams already running Postgres at production scale. The simplicity of one database (no separate vector store to operate, transactional consistency between vectors and metadata, easy backup) wins for most workloads under 5-10M vectors. Above that scale, dedicated vector databases (Qdrant, Pinecone) start to win on latency and metadata filtering performance. For the very common pattern of 'add semantic search to an existing Postgres-backed application,' pgvector is an underrated choice that often beats more sophisticated alternatives on total cost of ownership.
What is pgvector?
pgvector is a PostgreSQL extension that adds vector similarity search to Postgres. Open source (PostgreSQL License); installable as an extension on any Postgres deployment (managed cloud Postgres on AWS / Azure / GCP, self-hosted Postgres, Postgres-compatible like AlloyDB / Aurora). Provides vector data type, distance functions, indexing (IVFFlat, HNSW), and SQL integration with the rest of Postgres. Used widely in production for the 'vector search alongside other data' pattern that's common in modern applications.
| License | PostgreSQL License (open source) |
| Implementation | C extension to PostgreSQL |
| Deployment | Any Postgres deployment (RDS, Cloud SQL, Aurora, AlloyDB, Supabase, self-hosted) |
| Index types | IVFFlat, HNSW |
| Distance functions | Cosine, L2, inner product |
| Multi-tenancy | Standard Postgres patterns (schemas, RLS, table-per-tenant) |
| Best for | Existing Postgres applications adding semantic search; under 5-10M vectors |
| Worst for | Workloads above 10M vectors; high-cardinality complex filtering at scale |
| SDK languages | Any Postgres client (Python, TypeScript, Java, Go, etc.) |
| Active alternatives | Qdrant, Pinecone, Weaviate, Milvus |
Hands-on findings from 14+ production projects
We've shipped 14+ production deployments on pgvector at BearPlex. The pattern that emerged: pgvector is dramatically underrated for the very common 'add semantic search to existing Postgres application' pattern. Specific findings: (1) Operational simplicity is the killer feature; one database to operate, one backup story, transactional consistency between vectors and metadata; (2) Performance at moderate scale (1-5M vectors) is excellent: sub-50ms p95 with HNSW index; (3) HNSW index quality matches dedicated vector databases at this scale; (4) Metadata filtering uses standard Postgres SQL: straightforward for developers familiar with Postgres; (5) Migration path is friendly: adding vector data type to existing Postgres tables vs standing up a separate vector database; (6) Cost is excellent: vector search adds marginal cost to existing Postgres infrastructure. Pain points: at large scale (above 5-10M vectors), HNSW index build time and memory requirements become significant; at very large scale (above 50M vectors), dedicated vector databases win on latency; high-cardinality complex filtering can be slower than dedicated vector DBs at scale; advanced features (sparse vectors, hybrid search) aren't native and require additional engineering. For teams already running Postgres, pgvector is our default recommendation up to 5-10M vectors. For workloads above that or with specific advanced needs, dedicated vector databases (Qdrant, Pinecone) start to win.
Pros
- Operational simplicity: one database, one backup story
- Transactional consistency between vectors and metadata
- Performance at moderate scale (1-5M vectors) excellent
- HNSW index quality matches dedicated vector DBs at this scale
- Standard Postgres SQL for metadata filtering
- Easy migration path from existing Postgres applications
- Marginal cost on existing Postgres infrastructure
- Open source with active development
Cons
- Performance edges to dedicated vector DBs at scale (5-10M+ vectors)
- HNSW index build time / memory becomes significant at large scale
- High-cardinality complex filtering can be slower at scale
- Advanced features (sparse vectors, hybrid search) require additional engineering
- Multi-tenancy patterns are Postgres-standard, not vector-DB-optimized
- Less ecosystem of vector-DB-specific tooling than dedicated alternatives
pgvector compared to alternatives
| Alternative | Score | Best for | Worst for |
|---|---|---|---|
| Qdrant | 4.5/5 | Production at scale, sovereignty, advanced features | Teams that want one database for everything |
| Pinecone | 4/5 | Managed simplicity at small-to-medium scale | Teams committed to one-database simplicity |
| Weaviate | 4/5 | Built-in vectorization, GraphQL UX | Teams that want one database |
| Milvus | 3.5/5 | Massive scale (1B+ vectors) | Most production cases |
Pricing analysis
pgvector is free (PostgreSQL License). Cost is incremental on existing Postgres infrastructure. For a typical mid-market application adding semantic search, pgvector usually adds 0-30% to existing Postgres cost depending on vector volume and index strategy. Compared to managed vector databases, pgvector is dramatically cheaper for teams already running Postgres.
When to use
- Existing Postgres applications adding semantic search
- Workloads under 5-10M vectors
- Teams that prioritize operational simplicity over advanced vector DB features
- Cases where transactional consistency between vectors and metadata matters
- Cost-sensitive applications already on Postgres
When NOT to use
- Very large vector workloads (above 10M vectors): dedicated vector DBs win
- Cases requiring advanced features (sparse vectors, sophisticated hybrid search) without additional engineering
- Latency-critical applications where 10-30ms matters and dedicated vector DBs are faster
- Teams not running Postgres at production scale
pgvector — questions answered
Yes: widely used in production at scale. We've shipped 14+ production pgvector deployments. Major Postgres providers (AWS RDS, Azure Database for PostgreSQL, Google Cloud SQL, Supabase) all support pgvector.
Yes: Supabase has native pgvector support. For applications already on Supabase, pgvector is the natural choice for semantic search needs.
Possible but typically not the right choice. At 50M+ vectors, HNSW index build time and memory become significant; dedicated vector DBs (Qdrant, Milvus) handle this scale better. We migrate clients from pgvector to dedicated vector DBs when their workload grows past pgvector's sweet spot.
Hybrid search isn't built-in but achievable via Postgres full-text search (built into Postgres) plus pgvector. The implementation is straightforward but requires more code than dedicated vector DBs that support hybrid natively.
Yes: via standard Postgres multi-tenancy patterns (schema-per-tenant, table-per-tenant, row-level security). Less optimized than dedicated vector DBs designed for multi-tenancy from the ground up but works for typical SaaS multi-tenancy needs.
HNSW for most production cases: better recall, more predictable performance. IVFFlat for cases where index build time matters more than query performance. We default to HNSW for new pgvector deployments.
Yes: pgvector is one of our most-used vector solutions for clients already on Postgres. Typical engagement: 4-8 weeks for adding semantic search / RAG to an existing Postgres application using pgvector.
Related services
Featured case studies
Disclosure: BearPlex is not affiliated with the pgvector project. We have used pgvector in 14+ production client projects since 2023. We do not receive any compensation related to pgvector. Reviewed by Hamad Pervaiz, Founder & CEO, BearPlex.
Need help implementing pgvector at scale?
BearPlex builds production AI systems with pgvector and its alternatives. Outcome-based pricing.