pgvector vs Qdrant vs LanceDB: On-Prem RAG Vector Search (2026)

You already decided you’re self-hosting. That rules out the “should we even run our own vector
database” debate — you’ve read the ADRs, you know the compliance reasons, and the workload isn’t
leaving your VPC. What’s left is a narrower, harder question: pgvector vs qdrant vs lancedb 2026
— which of these three actually fits the retrieval-augmented generation (RAG) pipeline you’re about
to put into production? Postgres with pgvector gives you HNSW and IVFFlat indexes inside a database
you probably already operate. Qdrant gives you a purpose-built vector server with a filtering engine
built for exactly this problem. LanceDB gives you an embedded, Arrow-native columnar store that skips
the server process entirely. Each of these is a legitimate default for a different shape of team and
workload, and the wrong pick shows up months later as p99 latency spikes, over-filtered result sets,
or a Kubernetes StatefulSet nobody wants to own. What this covers: indexing algorithm trade-offs,
metadata filtering performance (pre-filter vs post-filter vs filter-aware graph traversal),
operational overhead of running a server versus an embedded library, and where each system’s scale
ceiling actually sits.

Context and Background

RAG systems live or die on retrieval quality and retrieval latency, and both are downstream of the
vector index you pick. In 2024–2025 most teams defaulted to a managed vector database (Pinecone,
Weaviate Cloud, Milvus-as-a-service) because self-hosting vector search was immature. That’s no
longer true. pgvector shipped iterative index scans and parallel HNSW builds, Qdrant hardened its
filterable HNSW and payload-index query planner, and LanceDB matured from a research project into a
production-grade embedded store with a real enterprise deployment mode. All three are now credible
on-prem choices, which is exactly why the choice got harder, not easier.

The pressure toward self-hosting isn’t purely technical. Compliance regimes that gate where embeddings
of regulated documents can live, egress costs on corpora that run into the hundreds of millions of
chunks, and the plain fact that a RAG pipeline’s retrieval layer sits on the critical path of every
user-facing request all push teams toward owning the vector store outright. Once that decision is
made, the three systems in this piece stop competing with managed SaaS offerings and start competing
with each other on a much narrower axis: how well each one’s indexing and filtering model matches your
actual query shape, and how much operational surface area you’re willing to add to your stack to get
there.

This piece assumes you’ve already read (or written) the pgvector vs dedicated vector database
ADR that asks
whether to bolt vector search onto Postgres at all, and that you’ve settled on self-hosting. If you
haven’t, read that first — it covers the org-level trade-offs (team size, existing Postgres
investment, compliance posture) that should gate this decision before you get into index tuning. The
question here is narrower and more mechanical: given three self-hostable systems, which indexing
algorithm, filtering model, and operational footprint fits your retrieval workload. For grounding on
current index internals, the PostgreSQL pgvector 0.8.2 release
notes are the canonical source —
treat vendor blog posts and Medium tutorials as secondary.

Indexing Algorithms and Recall/Latency Trade-offs

Direct answer: pgvector’s HNSW gives you the best recall-per-CPU-cycle inside Postgres but pays a
build-time and memory tax; Qdrant’s HNSW is tuned specifically for filtered queries via a
filter-aware graph; LanceDB defaults to IVF-PQ (inverted file + product quantization), trading some
recall for dramatically smaller on-disk footprint and faster cold-start on large, rarely-updated
corpora.

Figure 1: Three self-hosted architectures side by side — pgvector runs inside the Postgres process
and inherits its WAL, replication, and backup story; Qdrant runs as a dedicated server process with
its own storage engine and gRPC/REST API; LanceDB runs in-process as an embedded library reading and
writing Lance-format files directly, with no server to operate unless you opt into LanceDB
Enterprise’s separated compute/storage mode.

pgvector: HNSW and IVFFlat inside Postgres

pgvector supports two ANN (approximate nearest neighbor) index types. IVFFlat partitions vectors into
lists clusters via k-means and searches only the probes nearest clusters at query time — it’s
cheap to build but recall degrades sharply if the data distribution shifts after the index is built,
because the cluster centroids go stale. HNSW (Hierarchical Navigable Small World) builds a
multi-layer proximity graph and delivers materially better recall at a given latency budget, which is
why it’s the default recommendation for anything shipping in 2026. The catch is build cost: HNSW
index builds are CPU- and memory-intensive, and until pgvector 0.6 they were single-threaded, making
multi-million-row tables painful to reindex. Parallel HNSW builds (stabilized through 0.7–0.8.x)
closed most of that gap, and 0.8.2 fixed a parallel-build buffer overflow (CVE-2026-3172) that could
leak data from other relations — if you’re running an older 0.7.x or 0.8.0 build in production,
patching to 0.8.2 is not optional.

Storage footprint is the other axis worth planning around before you commit to HNSW at scale. A raw
vector(1024) column costs 4 bytes per dimension in float4 storage, so a 10-million-row table with
1024-dimensional embeddings needs roughly 40GB just for the vectors, before the HNSW graph itself
(which typically adds 20–40% on top depending on m). pgvector’s halfvec type stores each dimension
in 2 bytes instead of 4, roughly halving both the raw storage and the index size with a small, usually
acceptable recall cost — worth benchmarking against your embedding model before assuming you need the
full-precision column. Binary quantization is also available for extreme compression at a steeper
recall cost, useful mainly as a coarse first-pass filter ahead of a full-precision re-rank rather than
as your only index.

The feature that actually matters for RAG-with-filters is iterative index scans, added in
pgvector 0.8.0. Before that, HNSW simply doesn’t know about your WHERE clause — it walks the graph
using hnsw.ef_search candidates, then applies the filter afterward. If your filter matches 10% of
rows and ef_search is the default 40, you get roughly 4 rows back when you asked for 10, silently.
Iterative scans fix this by having pgvector keep walking the graph, expanding the candidate set, until
either the query is satisfied or hnsw.max_scan_tuples is hit. You enable it per-session:

SET hnsw.iterative_scan = relaxed_order;
SET hnsw.max_scan_tuples = 20000;

SELECT id, content, metadata
FROM chunks
WHERE tenant_id = 'acme-corp' AND doc_type = 'contract'
ORDER BY embedding <=> '[0.012, -0.048, ...]'
LIMIT 10;

relaxed_order trades a small amount of ordering precision for speed; strict_order guarantees exact
ranking among returned rows at higher cost. Either way, this single knob is the difference between
pgvector being filter-blind and filter-aware — know it exists before you conclude pgvector “can’t do
metadata filtering well.”

Two more knobs decide most of your recall/latency curve. ef_construction controls how thorough the
graph build is — higher values produce a better-connected graph and higher recall at query time, at
the cost of a slower build; 64 is a reasonable starting point for most embedding dimensionalities, and
it’s rarely worth pushing past 200 except for corpora where recall is the only thing that matters.
ef_search (renamed hnsw.ef_search at query time) is the equivalent knob for the search itself —
raise it when recall is too low, lower it when latency is too high, and treat it as a per-query-class
setting rather than a single global value, since a compliance-search query and a chatbot’s live RAG
lookup often have very different acceptable latency budgets on the same table.

Qdrant: a filtering-first HNSW implementation

Qdrant was designed around the assumption that vector search without metadata filters is a toy
problem — real RAG queries almost always carry a tenant ID, a document-type filter, an ACL check, or
a recency window. Its HNSW implementation builds filterable edges: when payload indexes exist at
collection-creation time (or are backfilled before the vector index is built), Qdrant can bias the
graph so filtered traversal doesn’t degrade into a near-linear scan. This is the single biggest
architectural difference from pgvector’s approach — Qdrant treats filtering as a first-class index
concern, not an afterthought applied post-scan.

At query time Qdrant’s planner picks a strategy per segment based on filter cardinality: high-cardinality
filters (matching many points) use HNSW traversal that skips non-matching nodes; low-cardinality
filters (a handful of matches) bypass the graph entirely and use the payload index directly, because
graph traversal for 50 matching points out of 10 million is wasted work. For adversarial cases where a
filter fragments the graph — sparse tenants, rare document types — Qdrant added ACORN, an HNSW
extension that hops through non-matching neighbors-of-neighbors to keep recall stable when direct
neighbors get filtered out. This is the mechanism to reach for when a specific tenant’s filtered
recall craters despite the collection overall performing well.

Qdrant also scales horizontally in a way neither of the other two does natively: collections can be
sharded across nodes, with replication factor configured per shard, and the Raft consensus layer
handles leader election and cluster membership changes. For teams outgrowing a single node, that’s a
meaningfully different operational model than “add a read replica” — you’re running a distributed
system with its own consistency and failover characteristics, which is exactly the cost referenced
later in this piece’s operational-overhead discussion.

LanceDB: IVF-PQ and the columnar-native index

LanceDB indexes by default with IVF-PQ: vectors are clustered (IVF) and then compressed via product
quantization, so the index itself is a fraction of the raw vector size on disk. This matters
disproportionately for LanceDB because its value proposition is embedding vector search directly into
a data lake — Lance files sit next to your Parquet-adjacent columnar data, and PQ compression keeps
multi-hundred-million-row tables queryable without a dedicated server holding everything in RAM. The
trade-off is the same one IVF always carries: recall depends on the nprobes value at query time and
on how well the IVF partitions match your actual query distribution, and it needs periodic
optimize() calls as data grows or drifts, or recall degrades quietly. LanceDB has also added HNSW as
an index option for workloads that need pgvector/Qdrant-like recall curves, but IVF-PQ remains the
default because it’s the option that plays best with the columnar, batch-oriented access pattern the
whole project is built around. Recall tuning in LanceDB is mostly a function of num_partitions and
num_sub_vectors at index-build time and nprobes/refine_factor at query time — more partitions
means finer-grained clustering and better recall but slower builds and more per-query overhead scanning
partition metadata, while a higher refine_factor re-ranks the PQ-approximate top-k against
full-precision vectors, recovering much of the accuracy quantization gives up at a modest latency cost.
Teams migrating from a brute-force flat index often find that a moderate refine_factor closes most of
the recall gap without needing to abandon PQ’s storage savings.

LanceDB’s other structural difference is that every write produces a new immutable version of the
dataset — the Lance format is versioned by design, which gives you time-travel queries (read the table
as it existed at a prior version) and cheap, consistent snapshots almost for free. That’s a genuine
advantage for RAG pipelines that need reproducible evaluation runs (compare retrieval quality against
the exact corpus snapshot a given answer was generated from) but it also means naive INSERT-per-row
ingestion patterns generate a lot of small versions; production pipelines batch writes and call
compact_files() periodically, or version growth turns into its own maintenance burden.

Metadata Filtering and Operational Overhead at Scale

Indexing algorithm choice only matters in the context of two things RAG systems can’t avoid:
filtering (every real query has a WHERE clause) and the operational shape of running the system at
scale for months, not a demo.

Figure 2: Pre-filtering (shrink the candidate set first, then search) is exact but can miss the
index entirely on low-selectivity predicates; post-filtering (search first, filter after) is fast but
risks returning fewer rows than requested; filter-aware traversal (Qdrant’s approach, and pgvector’s
iterative scan) blends the two by making the filter part of the graph walk itself.

The filtering spectrum in practice

Naive pre-filtering — running the metadata WHERE clause first to produce a row set, then computing
distances against only those rows — guarantees correctness but throws away the ANN index for anything
but the smallest candidate sets; at scale it degenerates into a brute-force scan. Naive post-filtering
— running ANN search first, then discarding rows that fail the filter — is fast but returns
unpredictable counts, exactly the overfiltering problem iterative scans were built to solve. Qdrant’s
filter-aware HNSW and pgvector’s iterative scan both aim at the same target from different angles:
make the index itself filter-conscious rather than treating filtering as a separate pass. LanceDB, by
contrast, mostly still relies on pushing filters down into the scan over IVF partitions plus a
post-filter pass — effective for coarse filters (a date range, a source column) but weaker for
high-selectivity per-row filters like tenant isolation on a shared table, where you’re better off
partitioning data into separate Lance datasets per tenant than relying on filter pushdown alone.

Decision matrix: indexing, filtering, ops, latency

Dimension	pgvector (Postgres)	Qdrant	LanceDB
Default index	HNSW (recommended) / IVFFlat	HNSW with filterable edges	IVF-PQ (HNSW optional)
Filter model	Iterative scan (post-scan, graph-aware since 0.8)	Filter-aware graph + payload index + ACORN	Filter pushdown over IVF partitions, post-filter
Pre- vs post-filter fit	Best with iterative scan enabled	Adapts strategy by filter cardinality automatically	Best with coarse filters; partition for high-selectivity
Deployment model	In-process with Postgres; inherits its HA/replication	Dedicated server (Docker/K8s StatefulSet, Raft-based cluster mode)	Embedded library; no server unless using LanceDB Enterprise
Ops overhead	Low if you already run Postgres; index rebuilds need care	Moderate: separate service, its own backup/monitoring/upgrade cadence	Lowest for single-node; rises with distributed/Enterprise mode
Sweet-spot scale	Up to tens of millions of vectors per table with tuned HNSW	Tens of millions to low billions with sharding	Hundreds of millions to 100B+ rows (lakehouse-scale, batch-heavy)
Multi-tenant isolation	Row-level via tenant_id column + RLS	Native payload filters, per-collection or shared-collection	Dataset-per-tenant partitioning generally outperforms shared-table filters

Scaling past a single node looks different for each system, and that difference should factor into
the decision as much as raw index performance. pgvector scales the way Postgres scales: read replicas
for read-heavy fan-out, and either logical partitioning or an extension like Citus if you need true
horizontal write scaling — none of that is vector-search-specific, it’s the same playbook you’d use
for any large Postgres table, which is either a comfort (your team already knows it) or a limitation
(vector search doesn’t get bespoke scaling primitives). Qdrant was built distributed from the start:
sharding and replication are first-class collection settings, and the query planner accounts for
cross-shard fan-out automatically. LanceDB’s scaling story is the most different from the other two —
single-node embedded deployments scale by throwing more disk and RAM at a bigger Lance dataset, and
genuine multi-node scale requires LanceDB Enterprise’s separated compute/storage architecture, which
reintroduces a service layer you were trying to avoid by picking an embedded library in the first
place. If you expect to outgrow one machine, factor that reintroduced complexity into the decision now
rather than discovering it during a migration.

Real config: standing up each system for a filtered RAG query

pgvector — create the table, HNSW index, and a supporting b-tree for the filter column so Postgres’s
planner has the option to use either path:

CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  tenant_id text NOT NULL,
  doc_type text NOT NULL,
  content text,
  embedding vector(1024)
);

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

CREATE INDEX ON chunks (tenant_id, doc_type);

Qdrant — create a collection, add payload indexes before bulk ingest (order matters for filterable
HNSW edges to form correctly), then query with a filter:

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PayloadSchemaType

client = QdrantClient(url="http://qdrant:6333")

client.create_collection(
    collection_name="chunks",
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE),
)
client.create_payload_index("chunks", "tenant_id", PayloadSchemaType.KEYWORD)
client.create_payload_index("chunks", "doc_type", PayloadSchemaType.KEYWORD)

results = client.query_points(
    collection_name="chunks",
    query=query_vector,
    query_filter={
        "must": [
            {"key": "tenant_id", "match": {"value": "acme-corp"}},
            {"key": "doc_type", "match": {"value": "contract"}},
        ]
    },
    limit=10,
)

LanceDB — open (or create) a dataset, build an IVF-PQ index once enough rows exist, and query with a
where pushdown:

import lancedb

db = lancedb.connect("/data/lancedb")
tbl = db.create_table("chunks", data=records)  # records include tenant_id, doc_type, vector

tbl.create_index(
    metric="cosine",
    num_partitions=256,
    num_sub_vectors=64,
)

results = (
    tbl.search(query_vector)
    .where("tenant_id = 'acme-corp' AND doc_type = 'contract'")
    .limit(10)
    .to_list()
)

None of these are drop-in production configs — m, ef_construction, num_partitions, and
num_sub_vectors all need tuning against your own recall/latency curve, measured with your actual
embedding model’s vector distribution, not a generic benchmark.

Figure 3: The query path differs structurally in each system — pgvector’s planner chooses between
the HNSW index and a sequential scan inside the normal Postgres executor; Qdrant’s planner picks a
per-segment strategy (graph traversal, payload-index-only, or ACORN) based on filter cardinality
before touching the vector index; LanceDB scans the relevant IVF partitions, applies quantized
distance computation, then pushes the metadata filter down over the candidate set.

Trade-offs, Gotchas, and What Goes Wrong

The failure modes here are less about “which system is slow” and more about mismatches between a
system’s design center and your actual access pattern. pgvector’s biggest gotcha is that people ship
it without enabling iterative scans, hit the overfiltering problem, conclude “pgvector can’t filter,”
and migrate to a dedicated vector DB for a problem that was one SET statement away from fixed. The
second-biggest is index rebuild cost on UPDATE-heavy tables: HNSW graphs degrade gracefully but not
infinitely, and a table with continuous re-embedding (say, from an evolving document set) needs a
reindex cadence baked into the operational runbook, not discovered during an incident.

Qdrant’s gotcha is sequencing: filterable HNSW edges only form correctly if payload indexes exist
before the vector index is built (or before bulk ingest, for growing collections). Teams that add
payload indexes after the fact get correct results but lose the filter-aware graph optimization
silently — the collection still works, it’s just not as fast as it should be, and nothing in the API
response tells you this happened. The other real cost is that Qdrant is a service: you now own a
Raft-based cluster, its upgrade path, its snapshot/backup story, and its own monitoring surface
distinct from whatever you already run for Postgres. If your team’s operational muscle is already
built around Postgres, that’s a second production database to keep healthy, on top of a message
queue, an object store, and whatever else the RAG pipeline touches.

LanceDB’s gotcha is the opposite direction: because it’s embedded, there’s no server to isolate
concurrent writers from each other, and Lance’s versioned, copy-on-write format means concurrent
writes from multiple processes need explicit coordination (or a single writer process) to avoid
version conflicts. It’s also the newest of the three in terms of production battle scars — the
filtering-under-IVF story is less mature than Qdrant’s purpose-built filtering engine, and teams that
need per-row ACL-style filtering at high selectivity should expect to do more of the work themselves
(dataset partitioning, careful where clause design) rather than leaning on the index to handle it
transparently. And because LanceDB’s default deployment is a library, not a service, you lose the
“restart the pod and it’s fine” operational simplicity you get from a stateless query layer in front
of Qdrant or Postgres — a crashed process taking down in-flight writes needs the same care any
embedded-database write path does.

Cost is the trade-off that rarely gets its own line item but shapes the decision as much as latency.
pgvector’s marginal cost is close to zero if Postgres is already sized for the workload — you’re
adding an index type, not a bill. Qdrant’s cost is the compute and memory for a dedicated cluster sized
for your vector count plus replication factor, plus the engineering time to operate a stateful
distributed service well. LanceDB’s cost curve is the flattest at small-to-medium scale (no server to
provision) but climbs again once you need LanceDB Enterprise’s separated compute/storage tier for true
multi-node scale — at which point its cost profile starts to resemble Qdrant’s rather than staying
uniquely cheap. None of these costs are prohibitive on their own; the point is to model them against
your actual growth curve, not your launch-day data volume.

Practical Recommendations

Pick based on what you’re already operating and what your filter selectivity actually looks like in
production traffic, not in a demo notebook. If you run Postgres already and your filters are coarse
to moderate (tenant, doc type, a handful of enum-like columns), pgvector with HNSW and iterative scans
enabled is the lowest-total-cost option — you get vector search inside a database your team already
backs up, monitors, and understands, with one new index type to learn. If your filters are
high-cardinality, ACL-shaped, or your query mix genuinely needs sub-50ms p99 at tens of millions of
vectors with complex boolean filter combinations, Qdrant’s purpose-built filtering engine is worth the
extra service to operate — that’s precisely the problem it was designed to solve, and retrofitting
equivalent behavior onto a general-purpose database is a losing trade past a certain scale. If your
corpus is huge, mostly read-heavy, updates in batches rather than continuously, and already lives
alongside other columnar/lakehouse data, LanceDB’s embedded model removes an entire service from your
architecture and scales cleanly into the hundreds-of-millions-of-rows range without a cluster to
babysit.

Figure 4: Start from what you already operate and how selective your filters are — existing Postgres
plus coarse filters points to pgvector, high-selectivity or ACL-style filters at scale points to
Qdrant, and large batch-oriented lakehouse-adjacent corpora point to LanceDB.

Before committing, validate with your own data:

• [ ] Benchmark recall@10 and p99 latency with your real embedding model’s vectors, not synthetic data.
• [ ] Test filtered queries at the selectivity your production traffic actually has, not an unfiltered baseline.
• [ ] Confirm your team can operate the failure mode each system implies — WAL bloat and reindex cadence for pgvector, a Raft cluster for Qdrant, write coordination for LanceDB.
• [ ] Load-test index rebuild time against your actual ingest/update rate, not a one-time bulk load.
• [ ] Re-check this decision at 10x your current data volume — sweet spots shift, and the system that wins at 1M vectors is not automatically the one that wins at 100M.

None of this needs to be a permanent commitment. Because all three systems are open source and speak
either standard SQL, gRPC/REST, or a Python/Arrow API, migrating between them later is real work but
not a rewrite of your whole retrieval layer — the embedding model, chunking strategy, and re-ranking
logic upstream of the vector store stay the same regardless of which one you pick. Treat the initial
choice as reversible-but-costly rather than irreversible, and revisit it explicitly at each scale
milestone rather than assuming the system you picked at 500K vectors is still the right one at 50M.

Frequently Asked Questions

Can pgvector’s HNSW index match Qdrant’s filtered query latency at scale?

For coarse-to-moderate selectivity filters, yes, once iterative scans are enabled — pgvector 0.8.x
closes most of the gap that used to exist. For high-selectivity, ACL-shaped filters at tens of
millions of vectors and above, Qdrant’s filter-aware graph and ACORN extension generally hold latency
more consistently, because filtering is built into the graph traversal itself rather than layered on
top of a general-purpose index. Benchmark both against your real filter distribution before deciding;
generic recall/latency numbers from vendor blogs rarely reflect your actual selectivity mix.

Is LanceDB production-ready for RAG, or still mostly for research and prototyping?

LanceDB moved past prototype status through 2025–2026: it now supports HNSW as an index option
alongside its default IVF-PQ, ships an enterprise deployment mode with separated compute and storage,
and publishes IOPS benchmarks at 100B+ row scale. It’s genuinely production-ready for read-heavy,
batch-updated, lakehouse-adjacent RAG corpora. It’s less mature than Qdrant specifically for
high-concurrency, high-selectivity filtered write-heavy workloads — validate write concurrency and
filter performance against your access pattern before committing.

Do I need a separate payload index in Qdrant, or does the vector index handle filtering automatically?

You need explicit payload indexes on every field you plan to filter on, created before bulk ingest.
Qdrant’s filterable HNSW edges only form correctly when payload indexes exist ahead of the vector
index build; adding them afterward still returns correct results but silently loses the filter-aware
graph optimization. This is the single most common Qdrant misconfiguration teams hit in production —
check collection setup order before troubleshooting latency.

What happens if I don’t enable iterative scans on pgvector’s HNSW index?

Filtered queries can silently return fewer rows than your LIMIT requests — the classic
“overfiltering” problem. HNSW walks the graph for ef_search candidates, then applies your WHERE
clause afterward; if the filter matches only 10% of rows and ef_search is 40, you get roughly 4
rows back, not 10, with no error. Iterative scans (pgvector 0.8.0+) fix this by continuing the graph
walk until the query is satisfied or hnsw.max_scan_tuples is hit — enable it explicitly per session
or as a database default before shipping filtered RAG queries.

Which system has the lowest total operational overhead for a small team?

LanceDB, if your access pattern fits its embedded, batch-oriented model — there’s no server process to
patch, monitor, or cluster. pgvector is close behind if you already run Postgres, since you’re adding
an index type rather than a new system. Qdrant has the highest floor: even a single-node deployment is
a service with its own upgrade cadence, backup story, and monitoring surface, though it pays that cost
back in filtering performance and horizontal scale once you cross into tens of millions of vectors
with heavy filtering. For a two- or three-person platform team already stretched across the rest of a
Kubernetes stack, that operational floor is not abstract — it’s the difference between “one more
extension to a database you already patch” and “one more StatefulSet with its own on-call runbook,”
and it’s worth weighing as heavily as the raw performance numbers in any bake-off.

Can I mix systems — pgvector for one workload, Qdrant or LanceDB for another?

Yes, and many production RAG stacks do exactly this: pgvector for a smaller, tightly-filtered
tenant-scoped corpus that lives naturally beside existing relational data, Qdrant for a
high-throughput shared corpus with complex ACL filtering, LanceDB for a large archival or batch-search
corpus. The cost is operational — each additional system is another thing to monitor, back up, and
upgrade — so only split workloads across systems when the access-pattern mismatch is real, not as a
default architecture.

How does quantization affect the pgvector vs Qdrant vs LanceDB comparison?

All three support some form of vector compression, and it changes the comparison meaningfully. pgvector’s
halfvec type roughly halves storage with a small recall cost; Qdrant supports scalar and binary
quantization with an optional rescoring pass against full-precision vectors to recover accuracy; LanceDB’s
default IVF-PQ is itself a quantization scheme, not an optional add-on. If storage cost is your binding
constraint rather than raw latency, re-run this comparison with quantization enabled on all three rather
than comparing full-precision configurations — the ranking can shift once compression is in the mix.

Further Reading

• GraphRAG hybrid retrieval and knowledge graph patterns (2026)
• Matryoshka embeddings and adaptive retrieval architecture (2026)
• Hybrid search architecture: dense/sparse fusion with RRF (2026)
• pgvector 0.8.2 release notes — PostgreSQL.org
• Qdrant: Combining Vector Search and Filtering

By Riju — about