pgvector
PostgreSQL extension that adds a vector data type and approximate nearest neighbor index methods (ivfflat and hnsw) for vector similarity search directly inside PostgreSQL.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Inherits PostgreSQL's mature security model including row-level security, SSL/TLS enforcement, SCRAM-SHA-256 auth, and audit logging; no additional attack surface beyond PostgreSQL itself.
⚡ Reliability
Best When
Your stack already includes PostgreSQL and you need vector search colocated with relational data without adding infrastructure.
Avoid When
Vector search is your primary workload at scale exceeding tens of millions of vectors, or you need a managed API with no database administration.
Use Cases
- • Agent memory systems for teams already running PostgreSQL who want vector search without adding a separate database service
- • RAG pipelines where vector search results need to be joined with relational metadata in a single SQL query
- • Transactional agent workflows that require ACID guarantees across vector upserts and relational updates in one transaction
- • Multi-tenant SaaS agent backends using PostgreSQL row-level security to isolate tenant vector data
- • Hybrid text+vector search using PostgreSQL full-text search (tsvector) and pgvector in a single query plan
Not For
- • Very large vector datasets (100M+) where a purpose-built ANN engine like Qdrant or Weaviate will outperform PostgreSQL
- • Teams without PostgreSQL operational experience who want a zero-admin managed vector search API
- • Workloads requiring advanced vector operations like sparse+dense hybrid search or built-in embedding generation
Interface
Authentication
Uses standard PostgreSQL authentication (md5, scram-sha-256, certificate, LDAP, etc.); no pgvector-specific auth layer; access controlled via PostgreSQL GRANT/REVOKE and row-level security.
Pricing
PostgreSQL extension licensed under PostgreSQL License (permissive); all managed PostgreSQL providers that support extensions can run pgvector.
Agent Metadata
Known Gotchas
- ⚠ HNSW index must be created after data is loaded for best build performance; creating the index on an empty table and then inserting data builds the index incrementally, which is slower and produces lower quality graphs
- ⚠ The <-> (L2), <#> (inner product), and <=> (cosine) distance operators are not interchangeable — using the wrong operator for your embedding model's similarity function silently returns incorrect rankings
- ⚠ IVFFlat requires setting the number of lists at creation time based on dataset size (sqrt(n) heuristic); too few lists reduces recall, too many increases index build time with no query benefit
- ⚠ pgvector does not support indexing vectors with more than 2000 dimensions in the current HNSW implementation; OpenAI text-embedding-3-large at 3072 dimensions requires dimensionality reduction first
- ⚠ Approximate nearest neighbor searches skip the index and perform exact sequential scans if the query planner estimates a small result set — agents relying on ANN speed may get exact-scan latency unexpectedly on filtered queries
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for pgvector.
Scores are editorial opinions as of 2026-03-06.