Postgres as a Vector Database vs Dedicated Vector Stores

The vector database boom of 2023 and 2024 rested on one bet: that Postgres, a 30-year-old relational engine, could never keep pace with vectors at real scale. That bet was wrong: it built a multibillion-dollar market for purpose-built vector stores that most teams didn't need. pgvector, first released in 2021 and rebuilt substantially through 2024 and 2026, turned Postgres into a legitimate vector search engine on its own. Most engineers now pick a side in this market without understanding what either side actually costs them, and that's the gap this piece tries to close.

What pgvector adds to Postgres, and how it indexes vectors

pgvector adds a VECTOR data type, a handful of distance operators, and a few index types to a plain Postgres install. Nothing new to deploy, no separate service to babysit, no second set of credentials to manage. The real story lives in how those indexes actually work, and it determines which systems can scale efficiently and which can't, regardless of what the marketing around either camp claims.

Three index types cover almost everything a team will run into, and each one answers a different question. IVFFlat splits the vector space into clusters, then searches only the clusters nearest the query at read time. It builds fast and uses less memory, but recall suffers, so teams choose it when they need an index running quickly and can accept lower search accuracy as a tradeoff. HNSW, a multi-layer graph structure, is what most teams actually run in production: sub-millisecond latency at high recall, tunable through two parameters, m and ef_construction, that trade memory and build time against search quality. Then there's DiskANN, shipped through the pgvectorscale extension, built for the moment an HNSW index outgrows RAM. DiskANN is designed for datasets that outgrow available RAM, keeping index navigation efficient while reducing the memory footprint required for full vector storage. As of pgvectorscale 0.9.0, it also supports CREATE INDEX CONCURRENTLY, so a production table doesn't have to lock while the index builds.

Dimension limits decide which embedding models a team can even use. The standard VECTOR type indexes up to 2,000 dimensions. halfvec, which stores 16-bit floats instead of 32-bit, stretches that to 4,000 dimensions and roughly cuts storage in half. Binary quantization through bit vectors pushes the ceiling to 64,000 dimensions. OpenAI's smaller embedding model outputs 1,536 dimensions, well inside range, but its larger model outputs 3,072, so halfvec or quantization becomes the practical path for a team that wants to index that model's output efficiently.

One more fix deserves attention, because it fixed a real production headache. pgvector 0.8.0 introduced Iterative Scan, which solved overfiltering: before 0.8.0, if you asked for the top 10 nearest neighbors and then applied a metadata filter, the ANN index might hand back fewer than 10 results, because it stopped searching before finding enough matches after the filter. Iterative scan keeps searching until it actually has a full result set, and it improves on the correctness problems present before 0.8.0.

The operational case for keeping embeddings inside Postgres

Splitting data across two systems creates a dual-write problem, and it's not a theoretical one. Every time a document changes, both the Postgres row and the vector store entry need to update. If the Postgres write succeeds and the vector store write fails, even for a second, the two systems disagree about the state of the world, and nothing forces them back into agreement on its own.

Closing that gap takes real engineering: event queues, the Outbox pattern, change data capture pipelines. Each one is a moving part, and each moving part is one more thing that can break at 2 a.m. A single-system architecture avoids this by construction, not by discipline, which is a meaningfully different guarantee.

The economics rarely favor the second system either. A team indexing 50,000 customer support documents in a dedicated vector store, paying something like $300 a month for the privilege, can query those same vectors from a Postgres instance they already run, in 8 milliseconds, for nothing extra. At that scale the dedicated service buys a bill and a second thing to operate. It does not buy capability.

Then there's the transactional guarantee that goes unnoticed until the day it's needed. pgvector inherits Postgres's full ACID compliance, so deleting a document and its embedding happens as one atomic operation. None of the major purpose-built vector databases, not Pinecone, not Qdrant, not Weaviate, not Milvus, offer that same guarantee across vector and relational data at once. That's a different design point, not a flaw in those systems, but it carries real consequences for anyone who needs vector writes and relational writes to succeed or fail together.

Where pgvector genuinely performs at production scale

At tens of millions of vectors, 1,536 dimensions, and a 99% recall target, pgvectorscale running DiskANN hit throughput in the hundreds of queries per second. That throughput substantially exceeds Pinecone's s1 tier, and Pinecone's p95 latency came in at nearly thirty times higher. That's a benchmark at a size where most engineers assume Postgres has already dropped out of contention, and the assumption is simply out of date.

One caution belongs here. Benchmarks trustworthy in 2026 test across multiple scales, because rankings flip depending on where you look, and a system leading at a smaller scale can trail at a much larger one. Recall target has to get published alongside QPS, because queries-per-second at 99% recall and queries-per-second at some lower recall target describe two different systems, even when the underlying software is identical.

Below roughly 100,000 vectors, none of this matters much. pgvector covers that volume for most teams without the architectural tradeoffs that appear at larger scale. The engineering decisions that actually separate architectures start once a dataset crosses that line, and inside that zone, HNSW is generally preferred over IVFFlat for production query performance, while 0.8.0's iterative scan closes the gap on filtered search, long pgvector's weakest spot.

The three ceilings where dedicated vector stores earn their keep

Three real limits exist, and any team weighing this decision should know them before committing to either path.

Scale beyond roughly tens of millions of vectors is the first ceiling. Even with DiskANN's compression, HNSW's memory footprint eventually outgrows what a single node can carry. Purpose-built systems handle sharding and horizontal scaling as a native feature. pgvector can get there too, through Citus, PgDog, or manual partitioning, but that's operational work a dedicated system absorbs on your behalf. At this size, self-hosting a dedicated vector store also starts to pencil out financially, since managed Pinecone pricing climbs fast once a workload passes tens of millions of vectors.

Complex filtered search at high recall is the second ceiling, and it's the subtler one. Standard pgvector HNSW applies metadata filters after the graph search runs, not during it, so a heavy filter can quietly tank recall well below whatever target got configured, because the index already picked its candidates before the filter ever touched them. Partial indexes using B-tree or GIN help when there are only a handful of filter values, but they don't scale to arbitrary filter combinations, and the schema complexity piles up fast. Qdrant takes a genuinely different approach: its filterable HNSW applies metadata filters while it walks the graph, not after, avoiding the recall collapse by design instead of by workaround.

Native hybrid search is the third ceiling. Postgres has solid full-text search through tsvector and tsquery, but nothing in its extension ecosystem combines BM25 keyword scoring with vector similarity inside a single query plan. Weaviate's hybrid search does exactly that, running BM25 and dense vector search together in one call rather than two calls stitched together in application code afterward. For e-commerce search, product catalogs, or any retrieval system where exact keyword matches carry as much weight as semantic closeness, that gap costs real recall, not just elegance.

A fourth, newer ceiling appears around agent memory, visible when write volume, namespacing, and quantization are pushed at production scale. Continuous-write agent memory doesn't look like classic retrieval-augmented generation: write volume stays constant, namespacing has to hold across thousands of users, and quantization has to scale toward a billion vectors in the more demanding deployments. Under moderate volume, pgvector with IVFFlat handles the write load cheaply, backed by Postgres's write-ahead log for durability. Past that, systems built for payload filtering during graph traversal and native multi-tenancy start to earn their cost.

Profiles of the dedicated options and what each does well

Pinecone is fully managed and closed-source, available cloud-only or, through its BYOC option, deployed inside a customer's own AWS, GCP, or Azure account. It auto-scales without asking anyone to touch infrastructure. Pricing under the Standard plan runs storage at $0.33 per GB per month, read units around $16, write units near $4, with a $50 monthly minimum on Standard and $500 on Enterprise, which adds a an uptime SLA. A metadata-filtered query can burn through multiple read units, not one, so cost forecasting has to account for actual query shape, not raw vector count. SOC 2 and GDPR come standard; HIPAA sits inside Enterprise or costs $190 a month as an add-on on Standard, provided a BAA is in place. That matters for regulated industries that can't easily stand up equivalent controls on a self-hosted database. The tradeoff is plain: no infrastructure to run and steady latency, paid for with vendor lock-in, no ACID guarantees, and a proprietary API that makes leaving expensive.

Qdrant, written in Rust and open-source under Apache 2.0, was built from the ground up for vector search, and its filterable HNSW is the strongest reason to choose it. The 2026 release of Qdrant 1.17 added Relevance Feedback Query along with search latency gains and better visibility into what a cluster is actually doing. Self-hosting costs nothing in license fees; Qdrant Cloud offers a free tier before moving to pay-as-you-go cluster pricing. It fits best where filtered search recall genuinely can't slip, and where a team is comfortable running its own cluster.

Weaviate is open-source and built for generative AI workflows from the start, with built-in vectorization modules and, as covered above, a well-regarded hybrid search implementation. Multi-tenant data isolation is built into its architecture rather than bolted on after the fact. Weaviate Cloud offers paid tiers that scale with vector count and query volume. It's the strongest choice for hybrid search workloads, and for teams that want vectorization and retrieval handled inside one system instead of stitched across two.

pgvector, whether self-hosted or run through a managed layer like Supabase, keeps full ACID compliance, SQL joins, row-level security, and unified backups and access control, with no operational seam between relational data and vector data. HNSW and DiskANN bring its query performance to parity with dedicated systems at small and medium scale, and the pgvectorscale benchmark at tens of millions of vectors, hundreds of QPS with p95 latency in the tens of milliseconds, shows this holds outside toy demos. Supabase, for teams that don't want to run Postgres themselves, offers a managed instance with pgvector preconfigured out of the box. It's the best fit for teams already running Postgres, working with datasets under the scale or filtered-search ceilings described above, or needing transactional consistency between vector and relational writes.

A practical decision framework for choosing between them

Start with whatever answers nearest-neighbor queries correctly at the lowest operational cost, which for most teams is pgvector. Migrate only when a specific, measurable constraint forces the issue.

Three questions do most of the work. First: how many vectors, today and roughly 18 months out? Below 100,000, pgvector, indexed or not, covers nearly every team without a second thought. Between the hundred-thousand range and the tens of millions, pgvector with HNSW or DiskANN competes with dedicated systems on raw performance and wins outright on operational simplicity. Past the tens-of-millions mark, with real throughput demands, a dedicated system deserves serious evaluation, because pgvector's single-node ceiling turns from a theoretical concern into a real constraint.

Second: does the workload need filtered search across arbitrary metadata combinations, at a recall target that has to hold under load? If the filter values are numerous and unpredictable, Qdrant's filterable HNSW or Weaviate is the architecturally sound choice. If the filter set is small and known ahead of time, a partial HNSW index in pgvector solves the problem without adding a second system to operate.

Third: does the workload need hybrid search, semantic and keyword relevance combined, as a core feature rather than an afterthought bolted on later? If BM25 has to run inside the same query plan as the vector search, Weaviate is currently the strongest option on the market. If keyword search can run separately and get merged in application code, Postgres's tsvector and tsquery running alongside pgvector is a perfectly workable answer, one that keeps everything inside a single system most teams already know how to run.