pgvector is an open-source PostgreSQL extension, not a separate database, that adds vector search to a table you already run, one of the retrieval layers Atlan’s Context Layer for AI sits upstream of, checking what got embedded before a similarity search ever runs against it. The vector database segment of the DBMS market is forecast to grow at a 75.3% CAGR, according to Gartner[8], and Fortune Business Insights puts the global market at $2.58 billion in 2025, rising to $17.91 billion by 2034.[9] A meaningful share of that growth runs straight through pgvector, precisely because adopting it needs no new infrastructure.
pgvector answers “what’s closest to this query vector” extremely well, and it answers that question inside the same database a team already trusts operationally. It has no concept of source certification, sensitivity classification, or lineage: a vector column doesn’t know whether the row it lives next to was ever approved for an AI agent to read, is still current, or contains a field that should never have been embedded.
| Field | Value |
|---|---|
| What it is | Open-source PostgreSQL extension for vector similarity search |
| Maintained by | The pgvector open-source project, on GitHub |
| Deployment | Runs inside any Postgres instance, self-hosted or managed |
| License | MIT |
| Typical practical scale | Single-digit millions comfortably; tens of millions with tuning; pgvectorscale extends further |
| Primary use cases | RAG on data already in Postgres, semantic search bolted onto an existing app |
| Governance gap | No native source certification, sensitivity classification, or lineage |
What is pgvector?
Permalink to “What is pgvector?”pgvector is an open-source PostgreSQL extension, maintained on GitHub, that lets a Postgres table store and search embeddings without a separate database. Enable it with one statement, CREATE EXTENSION vector;, and any existing table can gain a vector column the same way it would gain a text or integer one, no fork, no new engine to operate.[1] The project is MIT licensed and, as of this writing, sits at roughly 22,600 GitHub stars and 1,300 forks, a scale of adoption well ahead of most single-purpose Postgres extensions.[1]
pgvector was built for the moment a team needed embeddings sitting next to the relational data it already trusted, without standing up new infrastructure to get there, the same underlying need that produced dedicated engines like Pinecone, solved from the opposite direction: extend the system you have instead of adding a system next to it. Anyone starting from zero on what a vector database actually is should read that page first; this one assumes the category and goes deep on the Postgres-specific mechanics.
Adoption followed the path of least resistance. AWS added pgvector support to Amazon RDS for PostgreSQL on May 3, 2023, for PostgreSQL 15.2 and later, across every AWS region including GovCloud, explicitly framed around efficient similarity search for machine learning embeddings.[3] Supabase, Google Cloud SQL, Azure Database for PostgreSQL, and Neon followed the same pattern: enabling pgvector is a single CREATE EXTENSION vector; call, not a migration project.[7]
An extension inherits its host database’s operational maturity automatically. It inherits none of that database’s content trustworthiness. Whether the row next to the new vector column was ever approved for an AI agent to read is a separate question, one this page returns to in depth below.
How does pgvector work inside Postgres?
Permalink to “How does pgvector work inside Postgres?”pgvector adds a new column type and a new class of index to Postgres, and both slot into ordinary SQL rather than a separate query language.
Data types and distance operators
Permalink to “Data types and distance operators”pgvector’s core type is vector, which stores up to 16,000 dimensions per value; halfvec stores the same data at half precision for smaller indexes, and sparsevec and bit cover sparse and binary embeddings respectively.[1] Six distance operators ship with the extension: <-> for L2 (Euclidean) distance, <#> for negative inner product, <=> for cosine distance, <+> for L1 (taxicab) distance, and <~> / <%> for Hamming and Jaccard distance on binary vectors.[1] Every one of them is an ordinary SQL operator, usable directly in ORDER BY and WHERE clauses the same way < or = would be.
A typical query embeds the input with a model built on a transformer architecture, then runs something close to:
SELECT id, content FROM documents
ORDER BY embedding <=> '[0.01, -0.02, ...]'
LIMIT 5;
Because the vector lives in the same row as everything else, that query can add any ordinary WHERE clause on another column, a department, a date range, a status flag, joined in a single call rather than merged in application code after two separate network round trips.
Indexing options
Permalink to “Indexing options”Two index types ship with pgvector, HNSW and IVFFlat, each with its own dimension ceiling: HNSW indexes cap at 2,000 dimensions for vector and 4,000 for halfvec; IVFFlat matches those limits on the same two types.[1]
What's actually in your AI context stack?
The AI Context Stack breaks down where retrieval infrastructure like pgvector fits next to the governance layer most teams skip.
Get the AI Context StackHNSW vs. IVFFlat: does pgvector do exact or approximate search?
Permalink to “HNSW vs. IVFFlat: does pgvector do exact or approximate search?”Among vector search systems, pgvector is unusual: it defaults to exact search and only becomes approximate once a team adds an index, a real architectural choice, not a limitation to work around.
Without any index, pgvector performs a sequential scan: it compares the query vector against every row and returns the true nearest neighbors, 100% recall, at a cost that scales with table size.[4][11] For a few thousand rows, or a background job with no latency requirement, that’s often the simplest correct choice.
HNSW (Hierarchical Navigable Small World) builds a multi-layer graph connecting each vector to its close neighbors at several scales, giving pgvector its best recall-versus-speed tradeoff at the cost of a slower build and a larger memory footprint.[4] Qdrant and Weaviate both default to HNSW too; the same tradeoff shows up wherever the algorithm runs. IVFFlat clusters vectors into Voronoi-style lists and searches only the nearest few, building faster and taking less memory, a better fit for indexes that get rebuilt often as data changes.
| Approach | Recall | Build time | Memory | Best for |
|---|---|---|---|---|
| Sequential scan (no index) | 100% (exact) | None | None | Small tables, background jobs |
| IVFFlat | Good, tunable via probes |
Fast | Lower | Frequent rebuilds, moderate scale |
| HNSW | Best, tunable via ef_search |
Slower | Higher | Query-latency-sensitive production workloads |
pgvector 0.8.0 fixed a real problem shared by both index types: “overfiltering,” where a WHERE clause combined with an index scan returned too few rows because the index stopped scanning before it found enough matches that also passed the filter. Iterative index scans, configurable via hnsw.iterative_scan and ivfflat.iterative_scan, keep scanning until the filter is satisfied instead of silently under-returning.[2]
Neither index type has an opinion on whether a vector should have been built in the first place. That’s a retrieval-quality mechanic, not a data-quality one, a distinction the next section makes concrete.
What is pgvector used for in AI and RAG pipelines?
Permalink to “What is pgvector used for in AI and RAG pipelines?”Two use cases account for most pgvector deployments in production, and both share the same motive: don’t add a new system if the one you have can be extended.
RAG on data already in Postgres. A team with product documentation, support tickets, or an internal knowledge base already stored in Postgres embeds that content in place and retrieves it with <=> instead of standing up a parallel vector store and keeping two systems in sync. See what retrieval-augmented generation is and what RAG solves for the pattern this serves, and retrieval orchestration for routing across Postgres alongside other sources.
Semantic search bolted onto an existing app. An application that already queries Postgres for everything else adds a vector column and a similarity ORDER BY clause to queries it’s already running, rather than a second network hop to an external index for every search. Semantic search versus keyword search covers the distinction directly; semantic search implementation covers the practical build, including how a knowledge base for AI agents gets structured around it.
A secondary pattern, hybrid retrieval, combines <=> similarity with Postgres’s own full-text search (tsvector) to approximate hybrid RAG, genuinely useful, though it takes manual setup pgvector doesn’t provide natively, unlike engines built around hybrid search from the start.
None of this explains why retrieval quality still breaks in production. Chunking strategy, embedding model choice, reranking, and stale source data drive RAG accuracy problems just as much as which index sits underneath, and the wider RAG architecture around it.
How far does pgvector scale before you need a dedicated vector database?
Permalink to “How far does pgvector scale before you need a dedicated vector database?”There’s no fixed number for how far pgvector scales. The honest answer is a range that depends on dimension count, available RAM, and which index is doing the work.
The wall shows up as RAM and build time well before it shows up as a hard failure. Building an HNSW index over 10 million 1536-dimension vectors needs roughly 60-70GB of RAM, and query latency moves in the same direction: pgvector runs a p50 latency of 8-15ms at 1 million vectors on a modern Postgres instance, while a purpose-built engine like Qdrant holds a 4ms p50 at 5 million vectors and beyond on comparable hardware.[10]
Atlan’s own pages state pgvector’s ceiling differently: one says under 10 million vectors, another roughly 50 million. Both are directionally right; the number moves with dimension count and tuning, and single-digit millions is comfortable territory well before the tens-of-millions range starts to hurt. Treat any single number here, including this page’s, as a planning estimate rather than a hard spec.
The complication worth knowing: pgvectorscale, a separate open-source extension from Timescale built on top of pgvector, adds a disk-backed StreamingDiskANN index and statistical binary quantization.[6] Timescale’s own benchmark, run on 50 million 768-dimension Cohere embeddings, reports 28x lower p95 latency and 16x higher query throughput than Pinecone’s storage-optimized index, a vendor-published number, not independently audited, but a real reason not to treat 50 million as a hard ceiling for a Postgres-based stack.[5]
| Signal | Reach for |
|---|---|
| Already on Postgres, single-digit millions of vectors | pgvector alone |
| Already on Postgres, tens of millions of vectors, need headroom | pgvector + pgvectorscale |
| Need a fully managed, zero-ops engine past 100M vectors | A dedicated vector database, see the full comparison |
| Need native hybrid search or graph-like relationships out of the box | A dedicated engine built around that from the start |
Is your data estate actually AI-ready?
Run the Context Gap Calculator to see how much of what feeds your retrieval pipeline is certified, current, and actually safe to index.
Run the Context Gap Calculatorpgvector vs. Pinecone vs. Weaviate: which one fits your stack
Permalink to “pgvector vs. Pinecone vs. Weaviate: which one fits your stack”The right choice comes down to one question a team can usually answer in a sentence: are you avoiding a new system, or do you need one built for a job pgvector was never designed to do?
A team already on Postgres, indexing tens of millions of vectors or fewer, gets more from pgvector, paired with pgvectorscale for headroom, than from anything else, because nothing new joins the stack: no second backup job, no second on-call rotation to staff. Past that scale, the calculus flips. Pinecone gives up the “nothing new” story for a serverless engine with no cluster to size or run, built for exactly the scale where pgvector starts asking for more RAM than most teams want to hand it. And a team that needs hybrid search or graph-like relationships alongside vectors, not approximated with tsvector and manual configuration but built in from the start, is choosing a different architecture entirely, not a faster version of the same one.
None of these three wins outright. Each was built for a different constraint, and the honest move is naming which constraint is actually yours before picking a winner. Readers weighing all the options at once should read the full eight-way comparison; anyone starting from zero on the category should read what a vector database is first. This page went narrower on purpose: pgvector specifically, its mechanics above, its limits below.
What a governed context layer adds that pgvector doesn’t
Permalink to “What a governed context layer adds that pgvector doesn’t”That gap is easy to miss with pgvector specifically, because adding a column doesn’t feel like adding a new system that needs its own review. A vector column inherits Postgres’s backups, ACID guarantees, and access control, not whether the row next to it is still accurate or was ever approved for AI use, the same data quality problem that shows up everywhere else in an LLM pipeline.
Atlan’s Enterprise Data Graph carries source certification and lineage upstream of whatever similarity-search layer a team runs, pgvector included. Atlan’s MCP Server exposes that context to agents at runtime over the Model Context Protocol. Whether an agent uses MCP versus a plain API, querying a Postgres table through a connected data catalog means it can check whether the row it just read was ever supposed to be AI-visible. A semantic layer closes a related gap: the distance between “close in embedding space” and “means what the business thinks it means,” a gap that has nothing to do with why LLMs need retrieval in the first place and everything to do with whether the retrieved answer was correct.
None of this is a knock on pgvector, a genuinely good fit for teams that don’t want new infrastructure. The context layer is a different, upstream layer, and context engineering is the discipline of building it deliberately, see how to implement an enterprise context layer end to end, rather than discovering its absence after an agent has already acted on a row nobody re-certified.
See what governed retrieval looks like
Walk through how the Context Layer ROI Calculator estimates the cost of ungoverned retrieval versus a certified, lineage-tracked pipeline.
Try the ROI CalculatorFAQs about pgvector
Permalink to “FAQs about pgvector”1. What is pgvector used for?
Permalink to “1. What is pgvector used for?”pgvector is used for retrieval-augmented generation on data already stored in Postgres and for semantic search bolted onto an existing app, without standing up a separate vector database. Because it’s an extension, a team keeps the same backups, access control, and SQL joins it already runs.
2. Is pgvector free and open source?
Permalink to “2. Is pgvector free and open source?”Yes. pgvector is MIT licensed and free to self-host on any Postgres instance. Every major managed Postgres provider, including AWS RDS, Supabase, Google Cloud SQL, Azure Database for PostgreSQL, and Neon, bundles it at no extra license cost; the database itself still carries its usual bill.
3. How many vectors can pgvector handle?
Permalink to “3. How many vectors can pgvector handle?”Comfortably into the single-digit millions, and tens of millions with careful tuning and enough RAM for the HNSW index to build. pgvectorscale, a separate Timescale extension built on pgvector, extends that range further. Past that, a dedicated vector database usually makes more operational sense.
4. What is the difference between HNSW and IVFFlat in pgvector?
Permalink to “4. What is the difference between HNSW and IVFFlat in pgvector?”HNSW is graph-based, giving pgvector its best recall-versus-speed tradeoff at the cost of a slower index build and more memory. IVFFlat is cluster-based, faster to build and smaller, which suits indexes that get rebuilt often as the underlying data changes.
5. Does pgvector do exact or approximate search?
Permalink to “5. Does pgvector do exact or approximate search?”Both. Without an index, pgvector runs an exact sequential scan with 100% recall, at a cost that scales with table size. Adding an HNSW or IVFFlat index switches to approximate nearest-neighbor search, trading a small amount of recall for significantly faster queries.
6. Can pgvector replace a dedicated vector database like Pinecone or Weaviate?
Permalink to “6. Can pgvector replace a dedicated vector database like Pinecone or Weaviate?”For teams already running Postgres at moderate scale, often yes. Past tens of millions of vectors, or when native hybrid search and zero-ops scaling matter more than avoiding new infrastructure, a dedicated engine like Pinecone or Weaviate usually wins instead.
7. What is pgvectorscale?
Permalink to “7. What is pgvectorscale?”pgvectorscale is a separate open-source Postgres extension from Timescale, built on top of pgvector. It adds a disk-backed StreamingDiskANN index and statistical binary quantization to push past pgvector’s default scale ceiling, without leaving Postgres.
Sources
Permalink to “Sources”- pgvector repository and README, GitHub
- pgvector 0.8.0 Released, PostgreSQL.org
- Amazon RDS for PostgreSQL supports pgvector for storing embeddings, AWS What’s New
- Understanding vector search and the HNSW index with pgvector, Neon
- Pgvector Is Now as Fast as Pinecone at 75% Less Cost, Tiger Data
- pgvectorscale repository, GitHub
- AI & Vectors, Supabase Docs
- Forecast: Database Management Systems, Worldwide, Gartner
- Vector Database Market Size, Share & Industry Analysis, Fortune Business Insights
- Vector Database Comparison, Tensoria
- pgvector: A Deep Dive, Severalnines
