300+ Tools CoveredSource Data Updated Weeklydates

Tool intelligence profile

pgvector

Open-source PostgreSQL extension for vector similarity search and embeddings storage.

Visit Site →
Type
Vector Database
Category
Vector Databases
Pricing
Free (open source)
Deployment
Cloud or self-hosted
Last updatedSeptember 21, 2026Open Source

Editor's Take

We recommend pgvector for teams already running PostgreSQL that want open-source vector similarity search and embeddings storage without adding a separate vector database such as Pinecone. It is the right choice for small teams or cost-sensitive workloads that value SQL and operational simplicity, but the available context does not establish enterprise-scale adoption or performance at very large vector counts.

— Egor Burlakov, Editor

Evaluate pgvector

Top Alternatives
Substitutes, and when to pick them
Best Vector Databases
Ranked by public evidence
Vector Databases landscape
15 of the 16 in this market, filed under this category
Browse Vector Databases
Every published tool in the category
Stack Recommender
Build a stack around pgvector

Popular comparisons

vs Qdrant
Head-to-head comparison
vs Turbopuffer
Head-to-head comparison
vs ChromaDB
Head-to-head comparison
vs Milvus
Head-to-head comparison
See all 7 pgvector comparisons
vs Pinecone
Head-to-head comparison
vs Weaviate
Head-to-head comparison
vs MongoDB Atlas Vector Search
Head-to-head comparison

pgvector: product and architecture

Our pgvector review verdict: choose pgvector when PostgreSQL is already the operational center of your application and vector search belongs alongside relational data; avoid it when you need a separately operated vector-search platform with evidence-backed requirements beyond what the available product data documents. pgvector is an open-source PostgreSQL extension for vector similarity search and embedding storage, and version 0.8.2 was released as stable on February 25, 2026. Its GitHub repository had 22,616 stars and a last recorded push on August 8, 2026—useful public signals of project visibility and ongoing activity, but not proof of enterprise deployment scale.

Overview

pgvector brings vector similarity search into PostgreSQL rather than asking a team to introduce a distinct database solely for embeddings. It stores high-dimensional embeddings from text, image, or audio models in PostgreSQL tables, then queries them with SQL. That positioning is its decisive advantage: relational records and vectors can be handled through one database environment instead of being split across application systems.

The current package listing identifies pgvector 0.8.2 as stable, following version 0.8.1 from September 5, 2025 and version 0.8.0 from October 30, 2024. The release history also includes 0.7.4 on August 5, 2024, 0.7.0 on April 29, 2024, and 0.6.0 on January 29, 2024. This history shows a project with a long sequence of published releases, not a one-off experimental extension.

For data engineers, pgvector’s practical appeal is operational consolidation. A team that already models entities, permissions, and business metadata in PostgreSQL can keep embeddings in tables with that data and use familiar SQL rather than establish a separate vector data service. The trade-off is equally important: vector search becomes part of PostgreSQL’s workload and operational responsibility.

We recommend pgvector for teams that want retrieval, ranking, or personalization features without making a separate vector database their default architectural boundary. It is especially credible for teams that value SQL-centered workflows and accept that index selection, database capacity, and search behavior still require deliberate engineering. The supplied data does not provide deployment benchmarks, managed-service evidence, or enterprise user counts, so those should be validated directly for any production decision.

Key Features and Architecture

pgvector operates as a standard PostgreSQL extension. That means vector search is performed through familiar SQL syntax and does not require an external dependency merely to store and query embeddings. This is a concrete architectural choice: the vectors live in database tables rather than being delegated by default to another search system.

Key technical capabilities include:

  • Fixed-dimension vector storage: pgvector supports fixed-dimension vector data types for high-dimensional embeddings. Teams can store text, image, or audio embeddings directly in PostgreSQL tables with the associated relational data.
  • Cosine similarity: cosine similarity is available as a vector comparison metric. This supports semantic retrieval designs where directional similarity between embeddings is the relevant measure.
  • Euclidean (L2) distance: pgvector supports L2 distance for vector comparisons. That provides a second retrieval option when distance in the embedding space is the desired measure.
  • Inner product: inner-product comparison is also supported. The availability of cosine, L2, and inner product gives teams a defined set of metric choices rather than a single fixed similarity behavior.
  • IVFFlat indexing: pgvector provides IVFFlat for approximate nearest-neighbor retrieval. The supplied review material describes this as an option for efficient retrieval across millions of vectors.
  • HNSW indexing: pgvector also provides HNSW approximate nearest-neighbor indexing. Version 0.5.0 added the HNSW index type, and that release also added parallel-worker builds for IVFFlat indexes and performance improvements for distance operations.

The repository identifies C as pgvector’s primary language and describes the project as “Open-source vector similarity search for Postgres.” Its listed repository topics include approximate-nearest-neighbor-search and nearest-neighbor-search, which align with the IVFFlat and HNSW capabilities. These are implementation-oriented adoption signals, not a substitute for workload-specific testing.

The architectural strength comes with a clear cost. pgvector gives you one SQL and PostgreSQL environment, but it does not remove the need to choose a similarity metric, decide whether approximate indexing is appropriate, or validate performance against your own embedding count and query pattern. We would treat IVFFlat and HNSW as design decisions to test, not as automatic guarantees of retrieval quality or speed.

Ideal Use Cases

pgvector is best suited to applications where embeddings must stay close to relational records and where PostgreSQL is already a trusted part of the team’s operating model. A RAG application is a strong example: document records and their high-dimensional embeddings can be kept in PostgreSQL, and retrieval can be incorporated into a SQL-oriented data workflow. The available review data explicitly identifies RAG as a suitable use case.

A second fit is semantic search for documents, products, or content. A product organization with a PostgreSQL-backed catalog can store product metadata and embeddings together, then use cosine similarity, L2 distance, or inner product according to its retrieval design. This reduces the number of systems involved, but it does not eliminate the need to evaluate relevance and index behavior.

A third fit is recommendation, ranking, and personalization systems where the relational context matters as much as vector similarity. The supplied third-party material specifically identifies retrieval, ranking, and personalization as intended patterns. For an analytics engineering team, the value is that the embedding-bearing records remain within a familiar relational environment rather than creating a disconnected vector-only data store.

pgvector can also serve teams working with text, image, or audio embeddings that prefer to govern those records through their existing PostgreSQL tables. This does not imply that every embedding workload belongs in PostgreSQL. The product data says IVFFlat and HNSW support approximate nearest-neighbor retrieval across millions of vectors, but it provides no benchmark, latency target, throughput target, or hardware configuration.

Don’t use pgvector if the decisive requirement is independently verified large-scale vector-search performance, because the supplied evidence does not establish that requirement. Also look elsewhere if your organization does not want vector indexing and similarity-search behavior coupled to its PostgreSQL operation. pgvector is compelling precisely because it is a PostgreSQL extension; teams seeking a separate vector-service boundary should choose a tool designed and evaluated for that boundary.

Pricing and Licensing

pgvector’s pricing model is Open Source. The provided pricing details describe it as open-source and self-hosted, with no paid tiers mentioned. The repository’s listed license field is PostgreSQL, so teams that need a confirmed legal license position should verify the current licensing terms in the official project materials before adoption.

Open source does not mean zero cost. With a self-hosted PostgreSQL extension, the direct software price may not include a vendor subscription, but the organization still bears the infrastructure and operational cost of running PostgreSQL, storing embedding vectors, building indexes, maintaining backups, applying upgrades, and handling availability. For pgvector specifically, IVFFlat and HNSW are index choices that can affect the amount of database work a team must plan for.

In this category, the most important pricing question is often not per-seat pricing. It is the total cost of ownership: database compute, storage consumed by relational records and embeddings, index-building work, backup and recovery capacity, monitoring, and the engineering time needed to operate a production PostgreSQL environment. A separate vector platform may package more operations into a service price, while pgvector places more of those responsibilities with the team running PostgreSQL.

The supplied data contains no dollar prices, subscription tiers, usage rates, support packages, or managed pgvector plan. We therefore do not assign dollar amounts to pgvector or infer a typical category price range. Any estimate would be invented rather than decision-useful. Check the official pgvector website for current release and pricing-related information, and obtain current infrastructure pricing from the PostgreSQL environment you plan to use.

Our recommendation is to model pgvector as an infrastructure-backed open-source choice, not as a free line item. Compare the cost of incremental PostgreSQL capacity and operational ownership against the cost and control trade-offs of a separately operated vector tool.

Strengths & Trade-offs

Pros

  • Native PostgreSQL operation: pgvector works as a standard PostgreSQL extension, so teams can run vector search through familiar SQL rather than introducing an external dependency for basic embedding storage and retrieval.
  • Relational data and embeddings can stay together: fixed-dimension vector types allow text, image, and audio embeddings to be stored directly in database tables. This is valuable when retrieval must remain tied to existing relational records and metadata.
  • Three stated similarity options: cosine similarity, Euclidean (L2) distance, and inner product give engineers defined metric choices for semantic search, ranking, and retrieval implementations.
  • Two approximate nearest-neighbor index options: IVFFlat and HNSW are available for ANN retrieval. Version 0.5.0 specifically introduced HNSW and parallel-worker builds for IVFFlat indexes.
  • Visible project activity: version 0.8.2 was released on February 25, 2026, and the repository’s last push was recorded on August 8, 2026. Its 22,616 GitHub stars are a public interest signal, though not a deployment metric.
  • No paid tiers are listed: the supplied pricing information identifies pgvector as self-hosted open source with no paid tiers mentioned, which can simplify software procurement.

Cons

  • No standalone vector-service boundary: pgvector is specifically a PostgreSQL extension. Teams that need vector search operationally separated from PostgreSQL will find this architecture restrictive rather than simplifying.
  • Indexing still requires engineering judgment: IVFFlat and HNSW are available, but the product data provides no benchmark showing which is best for a given workload, no latency result, and no recall metric.
  • Operational cost moves into PostgreSQL: self-hosting means capacity, storage, backups, upgrades, and database operations remain the team’s responsibility. The absence of listed paid tiers is not the same as the absence of operational cost.
  • License evidence needs verification: the repository’s listed license is NOASSERTION. Organizations with strict license-review requirements should not treat the supplied metadata as a completed legal assessment.
  • Enterprise evidence is limited in the supplied data: GitHub stars and release activity are public adoption proxies, but the data does not include customer counts, support commitments, or independently measured production scale.

The key trade-off is straightforward. pgvector makes vector search more accessible to PostgreSQL-centric teams, but it requires those teams to own the consequences inside their PostgreSQL environment. That is a good bargain when consolidation is the goal and a weak fit when independent vector infrastructure is the goal.

Alternatives to pgvector

The reviewed substitutes for pgvector among the vector databases, and what would make each one the better answer.

Direct alternatives

Reviewed substitutes: products bought for the same job, where a team picks one.

LanceDB
Choose this if you work with multimodal data, need versioned datasets, or want an embedded database that scales to petabytes without a server process.Applies to: Choosing between these two for the vector databases decision.
Marqo
Two products of the same kind on one reviewed shortlist, answering the same purchase. 2026 vector database comparison guides rank these stores side by side on scale, filtering and hosting, and a team adopts one, so the comparison is a substitution.Applies to: Choosing between these two for the vector databases decision.
Qdrant
Choose this if you value Rust-level performance, need rich filtering on metadata alongside vector search, and want both self-hosted and managed options.Applies to: Choosing between two products of the same kind for one job.
Turbopuffer
Two products of the same kind on one reviewed shortlist, answering the same purchase. 2026 vector database comparison guides rank these stores side by side on scale, filtering and hosting, and a team adopts one, so the comparison is a substitution.Applies to: Choosing between these two for the vector databases decision.
Zilliz
Two products of the same kind on one reviewed shortlist, answering the same purchase. 2026 vector database comparison guides rank these stores side by side on scale, filtering and hosting, and a team adopts one, so the comparison is a substitution.Applies to: Choosing between these two for the vector databases decision.

Other approaches

A different approach to the same problem. Each substitutes only for the workload named beside it.

Milvus
Choose this if you need open-source flexibility with true horizontal scaling beyond what a single PostgreSQL instance can handle.Applies to: Whether embedding search can reuse an existing datastore or needs a dedicated vector service.
Pinecone
Choose this if you want zero operational overhead and need to scale beyond 50 million vectors without managing infrastructure.Applies to: Whether embedding search can reuse an existing datastore or needs a dedicated vector service.
Weaviate
Choose this if you want built-in embedding generation, hybrid search out of the box, and a GraphQL-based query interface.Applies to: Whether embedding search can reuse an existing datastore or needs a dedicated vector service.
HelixDB
Build 10x faster with the first fully native Graph-Vector Database combining the power of graph and vector types natively in Rust to build RAG and AI applications easilyApplies to: Moderate-scale similarity search over data already in a Postgres OLTP database, where relational joins matter more than peak ANN throughput or graph traversal. pgvector stands in for HelixDB there; HelixDB stands in once scale, latency or the graph model outgrow it.

Head to head

See detailed alternatives analysis

If you are running pgvector in PostgreSQL and hitting its scaling limits, dealing with operational complexity, or need features beyond what a database extension can provide, several strong pgvector alternatives exist across the vector database landscape. Whether you need a fully managed service, better multi-tenancy, or purpose-built distributed architecture, the right choice depends on your scale requirements, team expertise, and budget.

Top Alternatives Overview

Pinecone is a fully managed, purpose-built vector database that eliminates all infrastructure management. It supports billions of vectors with consistent low-latency queries and offers a free tier alongside usage-based pricing starting at $0.15 per hour for 4 cores. Pinecone handles index optimization, replication, and scaling automatically, which removes the PostgreSQL tuning burden entirely. Choose this if you want zero operational overhead and need to scale beyond 50 million vectors without managing infrastructure.

Milvus is an open-source distributed vector database written for horizontal scalability, with a cloud-native architecture separating storage and compute. It supports IVF, HNSW, and DiskANN index types, and scales to tens of billions of vectors. Milvus offers deployment flexibility from a lightweight pip-installable version (Milvus Lite) to full distributed clusters, with Zilliz Cloud providing a managed option starting free. Choose this if you need open-source flexibility with true horizontal scaling beyond what a single PostgreSQL instance can handle.

Qdrant is a high-performance vector search engine written in Rust, offering both self-hosted and cloud deployments. It provides advanced filtering capabilities, payload indexing, and efficient memory usage through quantization. Qdrant Cloud starts with a free tier and scales to $1 per month for basic usage, with enterprise options available. Choose this if you value Rust-level performance, need rich filtering on metadata alongside vector search, and want both self-hosted and managed options.

Weaviate is an open-source vector database with built-in vectorization modules that can generate embeddings automatically using integrated ML models. It supports hybrid search combining vector and keyword approaches, with multi-tenancy built in. Weaviate Cloud offers a free 14-day sandbox, Flex plans from $45/month, and Premium at $400/month. Choose this if you want built-in embedding generation, hybrid search out of the box, and a GraphQL-based query interface.

LanceDB is an open-source, serverless vector database built on the Lance columnar format designed for multimodal AI workloads. It runs embedded (no server needed), supports zero-copy versioning, and handles text, images, video, and point cloud data natively. LanceDB stores data on S3-compatible object storage for up to 100x cost savings compared to in-memory solutions. Choose this if you work with multimodal data, need versioned datasets, or want an embedded database that scales to petabytes without a server process.

Vespa is an open-source AI search platform that combines vector search with machine-learned ranking, real-time inference, and native tensor support. It handles both structured and unstructured data at enterprise scale with built-in distributed computing. Vespa is free to self-host, with managed cloud pricing available separately. Choose this if you need a full search and recommendation platform with real-time ML ranking, not just a vector store.

Architecture and Approach Comparison

pgvector operates as a PostgreSQL extension, meaning it inherits PostgreSQL's single-node architecture, ACID compliance, and WAL-based replication. This is a strength for teams already running PostgreSQL: you get vector search alongside relational data with full JOIN support, transactions, and point-in-time recovery. However, pgvector's HNSW index supports vectors up to 2,000 dimensions at full precision (4,000 at half-precision), and performance degrades beyond roughly 50 million vectors on a single node.

Purpose-built vector databases like Milvus and Qdrant use distributed architectures with separated storage and compute layers. Milvus distributes data across shards with stateless query nodes, while Qdrant uses a Rust-based engine optimized for memory-efficient vector operations. Both handle billions of vectors natively without the single-node bottleneck.

Pinecone and Turbopuffer take the fully managed approach. Turbopuffer stores vectors on S3-compatible object storage with SSD caching, achieving 10x reduced costs at the expense of slightly elevated cold-query latency (Launch tier at $16/month, Scale at $256/month). Pinecone abstracts everything behind an API with automatic index management.

LanceDB takes a fundamentally different approach with its embedded, serverless architecture built on the Lance columnar format. There is no server process to manage; it runs in-process and persists to object storage. Vespa, by contrast, is a full application platform with built-in document processing, tensor computation, and real-time ML model serving.

Pricing Comparison

ToolSelf-Hosted CostManaged/Cloud Starting PricePricing Model
pgvectorFree (open-source)Included with managed PostgreSQL providersOpen Source
MilvusFree (open-source)Free tier via Zilliz CloudOpen Source / Enterprise
QdrantFree (open-source)Free tier, then from ~$1/moFreemium
LanceDBFree (open-source)Contact for cloud pricingOpen Source
VespaFree (open-source)Cloud pricing on vespa.aiOpen Source
WeaviateFree (open-source)$45/mo (Flex), $400/mo (Premium)Freemium
PineconeN/A (managed only)Free tier, then $0.15/hr per 4 coresUsage-Based
TurbopufferN/A (managed only)$16/mo (Launch), $256/mo (Scale)Paid
TypesenseFree (open-source)$7.20/mo (Cloud)Freemium
ZillizN/A (managed Milvus)Free tier, Enterprise $155/moFreemium

pgvector has the lowest total cost of ownership when you already operate PostgreSQL infrastructure, since the extension itself is free. The managed alternatives add hosting costs but remove operational burden. Pinecone and Turbopuffer charge only for managed services with no self-hosted option, making them more expensive at scale but simpler to run.

When to Consider Switching

Switch from pgvector when your vector dataset exceeds 50 million rows and query latency becomes unacceptable despite HNSW tuning. Single-node PostgreSQL cannot horizontally shard vector indexes, so you hit a hard ceiling that purpose-built databases like Milvus or Pinecone handle natively.

Consider alternatives when you need vectors beyond 2,000 dimensions at full precision. pgvector caps HNSW indexing at 2,000 dimensions for standard vectors, while Milvus and Qdrant handle high-dimensional embeddings without architectural constraints.

If your team spends significant time tuning maintenance_work_mem, hnsw.ef_search, and ef_construction parameters, a managed service like Pinecone or Zilliz Cloud removes that operational burden entirely. The time saved on index tuning and PostgreSQL performance optimization often justifies the hosting cost.

Move to Weaviate or Marqo if you need built-in embedding generation. pgvector requires you to compute embeddings externally and insert them, while these platforms generate vectors from raw text or images using integrated ML models.

Choose LanceDB or Vespa when your workload involves multimodal data (images, video, audio) alongside text embeddings, or when you need real-time ML ranking as part of the retrieval pipeline.

Migration Considerations

Migrating from pgvector means exporting your vector data, which is stored as standard PostgreSQL arrays. Use COPY to export vectors in CSV or binary format, then convert to the target database's ingestion format. Most alternatives (Milvus, Qdrant, Weaviate) accept vectors as float arrays, making the data conversion straightforward.

The biggest migration cost is rewriting queries. pgvector uses SQL operators like <-> for L2 distance and <=> for cosine distance, all within standard PostgreSQL queries with JOINs and WHERE clauses. Purpose-built vector databases use their own query APIs (REST, gRPC, or client SDKs), so any application code using SQL-based vector search needs rewriting.

If you rely on pgvector's ACID transactions to keep vector data consistent with relational data in the same database, migration becomes more complex. You will need to manage data synchronization between your PostgreSQL tables and the external vector database, introducing eventual consistency concerns.

The learning curve varies significantly. Pinecone and Zilliz Cloud have the gentlest onboarding with simple API-based interfaces. Milvus and Qdrant require understanding their collection, partition, and index configuration models. Vespa has the steepest learning curve due to its application-platform approach with custom configuration language and document processing pipelines.

For teams not ready to fully migrate, a hybrid approach works well: keep pgvector for smaller vector datasets that benefit from SQL JOINs, and offload large-scale similarity search to a dedicated vector database. This avoids the all-or-nothing migration risk while addressing pgvector's scaling limitations.

Public signals

About these signals

Verified factual signals from public sources. They indicate observable activity or interest, not total adoption, product quality, or cost.

153 GitHub commits 90d23.1k GitHub stars0 vulnerabilities across 2 packages

See all signals from 8 sources
Source
Signals
Last updated
GitHub
Commits 90d:153↓23Stars:23.1k↑106
September 21, 2026
Docker Hub
Pulls:194.8M↑10.5M
September 21, 2026
PyPI
Weekly downloads:6.7M↓387.8k
September 21, 2026
npm
Weekly downloads:369.9k↓96
September 21, 2026
Google Trends
Search interest:Top 24%overallTop 10%in Vector Databases
September 21, 2026
Hacker News
Matching stories, 90d:10
September 21, 2026
Stack Overflow
Questions:90
September 21, 2026
OSV
Package vulnerabilities:0 vulnerabilitiesacross 2 packages

npm · pgvector@0.3.0 · PyPI · pgvector@0.5.0

September 21, 2026

Discussed on Hacker News

Recent Hacker News threads mentioning pgvector.

Frequently asked questions

Is pgvector free?

Yes, pgvector is open-source under the PostgreSQL license. It's free to use on any PostgreSQL 12+ installation.

How many vectors can pgvector handle?

pgvector works well up to 10-50 million vectors with HNSW indexes. Beyond that, purpose-built vector databases like Milvus or Pinecone provide better performance.

Does pgvector support HNSW?

Yes, pgvector supports HNSW indexes (added in version 0.5.0) for fast approximate nearest neighbor search, as well as IVFFlat indexes. HNSW provides good recall and query performance for most workloads, while IVFFlat is quick to build and uses little memory.

Related Vector Databases

Other vector databases in the catalog. Same kind of product, not a substitution recommendation.

Vector Databases

Milvus

Milvus is an open-source vector database built for GenAI applications. Install with pip, perform high-speed searches, and scale to tens of billions of vectors.

View tool profile
Vector Databases

Pinecone

Search through billions of items for similar matches to any object, in milliseconds. It’s the next generation of search, an API call away.

View tool profile
Vector Databases

Marqo

Marqo optimises search conversion using click-stream, purchase and event data, creating a personalised experience that knows what your customers are looking for - better than they do.

View tool profile
View all Vector Databases
← Back to all tools