4 Postgres vector search options compared: pgvector, pgvectorscale, ParadeDB, Lantern (2026)

Summary. For most retrieval-augmented generation (RAG) workloads in 2026, the vector database you already run is Postgres. The real question is which extension goes on top. pgvector 0.8.2 is the default and covers similarity search with HNSW and IVFFlat indexes. pgvectorscale adds a disk-backed StreamingDiskANN index: in Timescale's own 50-million-vector benchmark it reached 1,252 queries per second at 99% recall against Qdrant's 354, and 28x lower p95 latency with 16x higher throughput than Pinecone's storage-optimised index at roughly 75% lower cost when self-hosted. ParadeDB adds BM25 full-text search for hybrid retrieval. Lantern targets fast index builds, claiming a 90x quicker HNSW build than pgvector through external indexing. This guide compares the four on recall, latency, hybrid search, quantization and cost, and marks the ceiling near tens of millions of vectors where a dedicated engine starts to earn its bill.

Why Postgres is the 2026 default for vector search

Two years ago the standard advice was to bolt a separate vector database next to your application database. That advice has aged. By 2026 the four extensions in this comparison all run inside a normal PostgreSQL instance, which means one system to back up, one to secure, one transaction boundary, and one bill. Cost comparisons published in 2026 put pgvector 70 to 85% cheaper than hosted Pinecone, Weaviate Cloud or Qdrant Cloud at 1 to 10 million vectors, because it adds nothing beyond the Postgres you already pay for, as ClickHouse's engineering write-up on scaling vector search in Postgres and several 2026 vector database cost comparisons document.

The decision is no longer Postgres versus a dedicated store for every project. We cover that split in detail in pgvector versus a dedicated vector database. This article assumes you have chosen Postgres and now need to pick the right extension for your recall, latency and hybrid-search requirements. The four candidates are pgvector, pgvectorscale, ParadeDB (pg_search) and Lantern.

pgvector: the baseline every stack starts from

pgvector is the reference extension and the one every managed provider ships. AWS RDS and Aurora, Google Cloud SQL, Supabase and Neon all support it out of the box, so on most platforms you enable it with a single CREATE EXTENSION. It stores embeddings in a vector column and searches them with two index types: HNSW for high recall at query time, and IVFFlat for faster builds at lower memory.

The pgvector 0.8.0 release in late 2024, now at 0.8.2, sharpened the two weak spots that hurt RAG apps. Iterative index scans fix "overfiltering", where a query with a WHERE clause plus a nearest-neighbour sort returned too few rows; the planner now keeps scanning the index up to a configurable threshold until it has enough candidates. The release also improved how Postgres estimates when to use an approximate index versus a B-tree, which AWS documented on Aurora. Half-precision halfvec columns, added in the earlier 0.7.0 series per the pgvector changelog, store each dimension in 2 bytes instead of 4 and roughly halve index size with little recall loss.

pgvector's limit is structural. Its two indexes are both memory-resident: for acceptable latency the HNSW graph needs to sit in shared_buffers or the OS page cache. A 10-million-row table of 1,536-dimensional embeddings can take hours to build on a single core and produce an index tens of gigabytes in size. pgvector has no native disk-based ANN or GPU index. That is the exact gap the next extension fills.

pgvectorscale: disk-backed ANN when pgvector runs out of RAM

pgvectorscale is an open-source extension from Timescale (now Tiger Data) that layers two ideas on top of pgvector. The first is StreamingDiskANN, a disk-based index inspired by Microsoft's DiskANN research, so the graph no longer has to fit entirely in memory. The second is Statistical Binary Quantization (SBQ), a compression scheme that shrinks vectors while holding recall. Together they push the practical ceiling of a single Postgres node well past what stock pgvector handles.

The headline numbers come from Timescale's own benchmark on 50 million Cohere embeddings of 768 dimensions, so read them as vendor-reported rather than neutral. Against Qdrant, Tiger Data measured 1,252 queries per second at 99% recall versus Qdrant's 354, more than 250% higher, while keeping latency under the 100 ms bar during parallel queries. Against Pinecone's storage-optimised s1 index at 99% recall, Tiger Data reported 28x lower p95 latency and 16x higher throughput at about 75% lower cost when self-hosted. Qdrant still won on index build speed and tail latency in the same tests, so the picture is a trade, not a rout.

If your embeddings have outgrown a comfortable in-memory HNSW index but you do not want to run a second database, pgvectorscale is the first upgrade to reach for. It is the same reasoning we apply to model-serving hardware in AI compute capacity planning: move the bottleneck, do not move the whole system.

ParadeDB: when you need keyword and vector in one query

pgvector and pgvectorscale solve semantic similarity. They do not do lexical search well, and plenty of RAG systems need both: exact keyword matches for product codes, names or error strings, plus semantic matches for meaning. ParadeDB fills that role through its pg_search extension.

pg_search is a Rust extension built on Tantivy, the Rust equivalent of Apache Lucene, and it brings real BM25 full-text scoring inside Postgres. ParadeDB introduced it as the first stable release of a Postgres search extension (the project renamed pg_bm25 to pg_search at v0.6.0), and it supports every PostgreSQL version the community still maintains, 12 and up. Paired with pgvector, it enables hybrid search: BM25 for lexical precision and vector similarity for semantic recall, fused with Reciprocal Rank Fusion in a single SQL query, as ParadeDB describes in its hybrid search guide. The company launched from Y Combinator's S23 batch and has run pg_search in production since December 2023, per its GitHub repository.

Choose ParadeDB when your retrieval quality depends on getting exact terms right, not only on semantic closeness. If your RAG relevance problems are really embedding-model problems, fix that first; our guide to RAG embedding model selection covers that decision.

Lantern: fast index builds and external indexing

Lantern is an open-source Postgres extension that competes with pgvector on the operational pain point of index creation. It adds a lantern_hnsw index type and, more distinctively, lets you build that index outside the database and import it as a file. With external='true' on the CREATE INDEX statement, Lantern offloads the build to a separate indexing server running Usearch, then transfers the finished index back using Postgres large objects, as its external indexing post explains.

The point is resource isolation. Building an HNSW index consumes CPU that would otherwise serve live queries, so a large in-database build degrades production latency for hours. Moving the build off-box keeps the primary responsive. Lantern claims this makes index creation up to 90x faster than pgvector; treat that as a vendor figure tied to their own setup. Lantern also supports product quantization to cut index memory. Reach for it when frequent re-indexing, not query throughput, is your operational headache.

The decision: which extension for which job

The four are not strict rivals. pgvectorscale and pg_search both build on pgvector rather than replace it, so real stacks often combine them. Use the matrix to place each one, then the scenario table to choose.

Cost: what each option actually bills

pgvector's cost advantage is that it has almost none of its own. It runs on the Postgres instance you already operate, so the marginal cost of adding vector search is the extra storage and memory for the index. pgvectorscale, pg_search and Lantern are all open-source extensions, so they carry no license fee either; the cost is the compute you give them.

Managed dedicated stores bill separately, and the gap widens with scale. Third-party cost comparisons in 2026 put the numbers in these bands (treat them as approximate, since usage-based pricing varies with traffic).

The takeaway is not that Postgres is always cheaper. It is that Postgres stays cheaper until you hit a scale or latency wall, after which a dedicated engine's price buys real performance. Keeping the vector store inside your own database also keeps it inside your existing cloud-cost controls, which matters if you already run the disciplines in our cloud FinOps guide for Indian teams.

The scale ceiling: when to leave Postgres

Every Postgres vector stack has a ceiling. Knowing where it sits stops you from either over-engineering a small app or shipping a large one on the wrong foundation. The bands below come from ClickHouse's engineering analysis and ParadeDB's write-up of pgvector limitations.

Around 1 million vectors, a naive pgvector setup usually just works. Approaching 10 million, quantization and partitioning start to matter, and an in-memory HNSW index becomes expensive to build and hold. Near 100 million, it is worth asking whether stock in-memory HNSW is still the right structure, which is where pgvectorscale's StreamingDiskANN earns its place. Beyond a billion vectors, a pure Postgres design is often no longer the simplest or cheapest option.

Three signals say move to a dedicated engine regardless of raw count: a hard requirement for sub-20 ms p99 latency, scaling into the billions of vectors, or high write churn from frequent re-embedding that causes severe MVCC bloat in Postgres. The last one is easy to miss. If you re-embed a large corpus on every model change, the update-heavy pattern bloats tables and vacuum cannot always keep up. The related decision of whether to store agent state as vectors at all is covered in always-on memory versus a RAG vector database.

Config snippets you can copy

Enable pgvector and create an HNSW index with a half-precision column to cut index size:

            CREATE EXTENSION IF NOT EXISTS vector;

ALTER TABLE docs ADD COLUMN embedding halfvec(1536);

CREATE INDEX ON docs
  USING hnsw (embedding halfvec_cosine_ops)
  WITH (m = 16, ef_construction = 64);
          

Turn on iterative scans so filtered queries stop overfiltering:

            SET hnsw.iterative_scan = 'relaxed_order';

SELECT id, title
FROM docs
WHERE tenant_id = 42
ORDER BY embedding <=> :query_vector
LIMIT 10;
          

Add pgvectorscale's StreamingDiskANN index instead of HNSW when the corpus outgrows memory:

            CREATE EXTENSION IF NOT EXISTS vectorscale CASCADE;

CREATE INDEX ON docs
  USING diskann (embedding);
          

These are illustrative shapes; check each extension's current documentation for the exact operator classes and parameters your version ships.

India-specific considerations

For teams building under India's Digital Personal Data Protection (DPDP) Act 2023, the location of your embeddings is a design decision, not an afterthought. Embeddings derived from personal data are still linked to that data. Keeping them inside a Postgres instance you run in an in-country region, for example an ap-south-1 deployment, keeps the vectors within your own infrastructure and data-handling controls rather than shipping them to a third-party SaaS vector store in another jurisdiction. That is a practical argument for the Postgres-native path beyond cost.

The economics also read differently for Indian startups watching burn. The self-hosted saving of 70 to 85% at 1 to 10 million vectors applies whether the bill lands in dollars or rupees, and it lands on infrastructure your team already manages. If personal data sits in the corpus, name the DPDP obligation explicitly in your architecture and describe how consent, retention and deletion flow through the embedding pipeline, not only the source tables.

FAQ

How eCorpIT can help

eCorpIT designs and ships production RAG systems on Postgres for teams that want retrieval they can own and audit. We benchmark pgvector, pgvectorscale, ParadeDB and Lantern against your own corpus and latency targets, size the index and instance correctly, and build the embedding, hybrid-search and re-indexing pipeline around DPDP-aligned data handling. If you are choosing a vector stack or hitting a scale wall on your current one, talk to our engineering team and we will map the right option to your data.

References

1. pgvector 0.8.0 released, PostgreSQL news

1. pgvector changelog, GitHub

1. Supercharging vector search with pgvector 0.8.0 on Amazon Aurora, AWS

1. pgvectorscale, Timescale/Tiger Data GitHub

1. pgvector versus Qdrant benchmark, Tiger Data

1. pgvector as fast as Pinecone at 75% less cost, Tiger Data

1. Introducing pg_search, ParadeDB

1. Hybrid search in PostgreSQL, ParadeDB

1. ParadeDB repository, GitHub

1. pgvector limitations, ParadeDB

1. Offloading pgvector indexing with external indexing, Lantern

1. 90x faster HNSW index creation, Lantern

1. Scaling vector search in Postgres, ClickHouse engineering

1. Vector database cost comparison 2026, LeanOps

_Last updated: 2 August 2026._