pgvector
RepositoryFreeVector search for PostgreSQL — HNSW indexes, similarity queries in SQL, use existing Postgres.
Capabilities13 decomposed
native vector type storage with multiple precision formats
Medium confidenceImplements four distinct vector data types (vector/float32, halfvec/float16, sparsevec/sparse, bit/binary) as first-class PostgreSQL types via custom type system integration in src/vector.c, src/halfvec.c, src/sparsevec.c, and src/bitvector.c. Each type includes input/output functions, binary serialization (vector_recv/vector_send), and automatic casting between formats, enabling memory-efficient storage of embeddings directly in table columns alongside relational data without external serialization.
Implements four vector types (float32, float16, sparse, binary) as native PostgreSQL types with automatic casting and binary serialization, rather than storing vectors as JSON/BYTEA blobs. This enables query planner optimization and direct operator dispatch without deserialization overhead.
Faster than Pinecone/Weaviate for queries combining vector similarity with relational filters because vectors are stored inline with row data, eliminating network round-trips and join operations.
six-metric distance operator system with simd acceleration
Medium confidenceProvides six distance metrics (L2 Euclidean, inner product, cosine, L1 Manhattan, Hamming, Jaccard) exposed as SQL operators (<->, <#>, <=>, <+>, <~>, <%>) with C implementations in src/vector.c using CPU-specific SIMD dispatch (AVX-512, AVX2, SSE2 fallback). Each operator is registered as a PostgreSQL operator class enabling index-aware query planning and automatic selection of the fastest implementation for the host CPU architecture.
Implements CPU-aware SIMD dispatch (AVX-512 > AVX2 > SSE2) at runtime, selecting the fastest distance implementation for the host CPU without recompilation. Operators are registered as PostgreSQL operator classes, enabling the query planner to push distance calculations into index scans.
Faster than Redis/Elasticsearch for distance calculations because SIMD operations execute in-process without serialization, and query planner can optimize distance computation order based on selectivity.
index maintenance with vacuum and incremental updates
Medium confidenceIntegrates with PostgreSQL's VACUUM process to maintain index consistency as vectors are inserted, updated, or deleted. VACUUM removes deleted vectors from indexes and reclaims space, while INSERT/UPDATE operations incrementally update HNSW graph structure or IVFFlat cluster assignments. Index maintenance is automatic and transparent — no manual index rebuild required for normal operations. VACUUM can be run manually or automatically via autovacuum daemon, with configurable aggressiveness via vacuum_cost_delay and related parameters.
Integrates index maintenance into PostgreSQL's VACUUM process, enabling automatic cleanup of deleted vectors and incremental index updates without manual intervention. Maintenance is transparent and requires no application code changes.
More reliable than manual index maintenance because VACUUM is integrated into PostgreSQL's transaction system, ensuring consistency between table and index state even during concurrent operations.
multi-language client support via standard postgresql wire protocol
Medium confidencepgvector works with any PostgreSQL client library (psycopg2 for Python, pg for Node.js, pq for Go, etc.) via the standard PostgreSQL wire protocol. Vector types are transmitted as binary data using PostgreSQL's vector_send/vector_recv functions, requiring no special client-side code beyond standard parameterized queries. Clients can pass vectors as text literals (e.g., '[0.1, 0.2, 0.3]') or binary data, with automatic conversion handled by pgvector's type system.
Works with any PostgreSQL client library without requiring language-specific adapters, leveraging the standard PostgreSQL wire protocol for vector transmission. This enables seamless integration into polyglot applications.
More flexible than specialized vector DB clients because pgvector uses standard PostgreSQL protocols, enabling use from any language with PostgreSQL support without vendor-specific SDKs.
type casting and conversion between vector formats
Medium confidenceSupports automatic and explicit casting between vector types (vector ↔ halfvec ↔ sparsevec ↔ bit) via PostgreSQL's CAST system. Casting from float32 to float16 rounds to nearest representable value (7 significant digits), casting to sparse requires external sparsification, and casting to binary uses threshold-based quantization. Casts are implemented in src/vector.c and registered via CREATE CAST statements, enabling implicit conversion in some contexts and explicit conversion via CAST() operator.
Implements type casting between four vector formats (float32, float16, sparse, binary) via PostgreSQL's CAST system, enabling format conversion without re-computing embeddings. Casting is lossy in some directions (float32 → float16, float32 → bit) but enables memory optimization.
More flexible than specialized vector DBs because PostgreSQL's CAST system enables arbitrary format conversions, allowing experimentation with different representations without data movement.
hnsw approximate nearest neighbor indexing with configurable parameters
Medium confidenceImplements Hierarchical Navigable Small World (HNSW) index as a PostgreSQL access method (hnswhandler in src/index.c) supporting approximate nearest neighbor search with configurable M (max connections per node) and ef_construction (search width during build) parameters. Index is built incrementally during INSERT operations and supports parallel construction via PostgreSQL's parallel index build framework, storing the hierarchical graph structure in PostgreSQL's B-tree storage with layer information and neighbor lists.
Implements HNSW as a native PostgreSQL access method with full integration into the query planner and WAL replication system. Supports parallel index construction via PostgreSQL's parallel workers, and stores the hierarchical graph structure directly in PostgreSQL's storage layer rather than as external files.
More reliable than Pinecone for mission-critical systems because HNSW indexes participate in PostgreSQL transactions, point-in-time recovery, and replication — no separate index durability concerns.
ivfflat inverted-file approximate indexing with clustering-based partitioning
Medium confidenceImplements Inverted File Flat (IVFFlat) index as a PostgreSQL access method (ivfflathandler in src/index.c) using k-means clustering to partition vectors into lists, storing cluster centroids and flat lists of vectors per cluster. Query execution performs exact distance calculation only within the top-k nearest clusters (determined by ef_search parameter), reducing search space from full dataset to typically 1-5% of vectors. Index is built via k-means clustering during CREATE INDEX and supports list-level parallelization during queries.
Uses k-means clustering to partition vectors into inverted lists, then performs exact distance calculation only within top-k nearest clusters. This approach trades recall for memory efficiency and index build speed, making it suitable for billion-scale deployments where HNSW memory overhead is prohibitive.
More memory-efficient than HNSW for 10M+ vectors (1-2x vs 8-12x overhead), and faster to build (O(n) vs O(n log n)), making it better for cost-sensitive cloud deployments where storage is the primary constraint.
hybrid filtering with vector similarity and relational predicates
Medium confidenceEnables combining vector similarity queries with standard SQL WHERE clauses via PostgreSQL's query planner, which can push distance calculations into index scans and apply relational filters before or after index lookups. The planner estimates selectivity of both vector and relational predicates, choosing between index-first (if vector predicate is selective) or filter-first (if relational predicate is selective) execution strategies. Supports re-ranking patterns where approximate index results are re-scored with exact distance calculations.
Leverages PostgreSQL's query planner to optimize execution order of vector and relational predicates based on estimated selectivity. Supports re-ranking patterns where approximate index results are re-scored with exact distance calculations, enabling multi-stage ranking pipelines.
More flexible than specialized vector DBs (Pinecone, Weaviate) because PostgreSQL's query planner can optimize arbitrary combinations of vector and relational predicates, rather than being limited to pre-defined filter types.
binary quantization for 8x memory reduction with minimal recall loss
Medium confidenceImplements binary quantization (bit type) that converts float32 vectors to single-bit representations via threshold-based quantization, reducing memory footprint from 4 bytes per dimension to 0.125 bytes (8 dimensions per byte). Supports Hamming distance for binary vectors and Jaccard distance for sparse binary vectors. Binary quantization is lossless for similarity ranking (preserves relative ordering) but lossy for absolute distance values, making it suitable for approximate search where only ranking matters.
Implements bit type as a first-class PostgreSQL type with Hamming and Jaccard distance operators, enabling 8x memory reduction while preserving ranking quality. Binary quantization is lossless for similarity ranking (relative ordering preserved) but lossy for absolute distances.
More memory-efficient than product quantization or scalar quantization for similarity search because single-bit representation is maximally compact, and Hamming distance is faster to compute than L2 on binary data.
parallel index construction with multi-worker cpu utilization
Medium confidenceIntegrates with PostgreSQL's parallel index build framework to parallelize HNSW and IVFFlat index construction across multiple worker processes. For HNSW, parallel workers build independent graph sections that are merged during finalization. For IVFFlat, parallel workers perform k-means clustering iterations and assign vectors to clusters concurrently. Parallelization is controlled via max_parallel_workers_per_gather and maintenance_work_mem settings, with automatic work distribution based on vector count and available memory.
Leverages PostgreSQL's parallel index build infrastructure to distribute HNSW graph construction and IVFFlat k-means clustering across worker processes. Parallelization is automatic and requires no application code changes — controlled entirely via PostgreSQL configuration.
Faster index construction than standalone tools (Faiss, Annoy) because parallelization is integrated into PostgreSQL's transaction system, enabling consistent snapshots and avoiding external data movement.
acid-compliant vector data with wal replication and point-in-time recovery
Medium confidenceIntegrates vector data fully into PostgreSQL's transaction system, ensuring ACID compliance for all vector operations (INSERT, UPDATE, DELETE). Vector changes are logged to PostgreSQL's Write-Ahead Log (WAL), enabling replication to standby servers and point-in-time recovery (PITR) of vector data. Index changes are also logged, allowing replicas to maintain consistent indexes. This integration means vector data participates in transactions, savepoints, and rollbacks like any other PostgreSQL data.
Vector data participates fully in PostgreSQL's transaction system, WAL replication, and point-in-time recovery — no separate durability mechanism required. This is fundamentally different from external vector DBs where vector data is stored separately from relational data.
More reliable than Pinecone/Weaviate for mission-critical systems because vector data is protected by PostgreSQL's proven ACID guarantees, replication infrastructure, and backup/recovery tools rather than relying on vector DB-specific durability mechanisms.
query optimization with cost estimation and index selection
Medium confidenceIntegrates with PostgreSQL's query planner to estimate cost of vector operations (distance calculations, index scans) and select optimal execution plans. The planner estimates the number of distance calculations required for HNSW (based on ef_search parameter) and IVFFlat (based on nlist and ef_search), comparing against sequential scan cost. For hybrid queries, the planner chooses between index-first and filter-first strategies based on selectivity of vector and relational predicates. Cost estimates are based on vector dimensionality, index parameters, and table statistics.
Integrates vector cost estimation into PostgreSQL's query planner, enabling automatic selection of HNSW vs IVFFlat vs sequential scan based on estimated cost. Cost estimates account for index parameters (ef_search, nlist) and vector dimensionality.
More transparent than specialized vector DBs because PostgreSQL's EXPLAIN output shows exactly why a particular execution plan was chosen, enabling developers to understand and optimize query performance.
sparse vector support with efficient storage and jaccard distance
Medium confidenceImplements sparsevec type for storing sparse vectors (vectors with mostly zero values) using a compressed format that stores only non-zero indices and values. Sparse vectors are stored as (index, value) pairs, reducing storage from O(d) to O(k) where k is the number of non-zero elements. Supports Jaccard distance for sparse vectors, which measures set overlap rather than Euclidean distance. Sparse vectors can be indexed with HNSW or IVFFlat, with distance calculations optimized to skip zero elements.
Implements sparsevec as a first-class PostgreSQL type with compressed storage of (index, value) pairs, reducing memory from O(d) to O(k). Supports Jaccard distance optimized for sparse vectors, enabling efficient search on high-dimensional sparse embeddings.
More memory-efficient than dense vectors for sparse embeddings (e.g., TF-IDF with 10K dimensions and 99% sparsity), and Jaccard distance is more appropriate for set-based similarity than cosine distance.
Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.
Related Artifactssharing capabilities
Artifacts that share capabilities with pgvector, ranked by overlap. Discovered automatically through the match graph.
@zvec/zvec
A lightweight, lightning-fast, in-process vector database
lancedb
Developer-friendly OSS embedded retrieval library for multimodal AI. Search More; Manage Less.
zvec
A lightweight, lightning-fast, in-process vector database
closevector-node
CloseVector is fundamentally a vector database. We have made dedicated libraries available for both browsers and node.js, aiming for easy integration no matter your platform. One feature we've been working on is its potential for scalability. Instead of b
vectoriadb
VectoriaDB - A lightweight, production-ready in-memory vector database for semantic search
ruvector
Self-learning vector database for Node.js — hybrid search, Graph RAG, FlashAttention-3, HNSW, 50+ attention mechanisms
Best For
- ✓teams building RAG systems on existing PostgreSQL infrastructure
- ✓applications requiring sub-4GB memory footprint for embeddings via halfvec/bit types
- ✓organizations needing ACID guarantees and point-in-time recovery for vector data
- ✓high-throughput similarity search applications requiring <10ms query latency
- ✓teams optimizing for specific embedding models (e.g., cosine for OpenAI embeddings)
- ✓systems needing Hamming distance for binary embeddings or Jaccard for sparse vectors
- ✓production systems with continuous INSERT/UPDATE/DELETE operations
- ✓applications where manual index maintenance is impractical
Known Limitations
- ⚠vector type fixed at creation time — cannot dynamically change dimensionality per row
- ⚠halfvec precision loss (~7 significant digits vs 24 for float32) acceptable only for similarity search, not for downstream ML tasks
- ⚠sparsevec format overhead makes it slower than dense vectors for low-sparsity data (<90% zeros)
- ⚠bit type limited to binary (0/1) vectors only — no continuous values
- ⚠SIMD optimization requires CPU support — falls back to scalar on older CPUs (pre-SSE2), adding 3-5x latency
- ⚠distance calculations are approximate for IVFFlat indexes (see IVFFlat capability) — exact only for sequential scans
Requirements
Input / Output
UnfragileRank
UnfragileRank is computed from adoption signals, documentation quality, ecosystem connectivity, match graph feedback, and freshness. No artifact can pay for a higher rank.
About
Open-source vector similarity search extension for PostgreSQL. Add vector columns, create HNSW or IVFFlat indexes, and run similarity queries in SQL. Use your existing Postgres infrastructure for AI. Supported by Supabase, Neon, and all major Postgres hosts.
Categories
Alternatives to pgvector
Are you the builder of pgvector?
Claim this artifact to get a verified badge, access match analytics, see which intents users search for, and manage your listing.
Get the weekly brief
New tools, rising stars, and what's actually worth your time. No spam.
Data Sources
Looking for something else?
Search →