---
title: "pgvector vs Qdrant vs LanceDB"
description: "pgvector vs Qdrant vs LanceDB: a Postgres extension, a Rust vector engine, and a Lance multimodal lake. Last reviewed October 2026; vendor docs linked."
url: "https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb"
updated: "2026-10-28"
vertical: "Retrieval"
doc: "https://docs.pixeltable.com/datastore/embedding-index"
---

# pgvector vs Qdrant vs LanceDB

pgvector, Qdrant, and LanceDB are three ways to store vectors and search nearest neighbors. pgvector is a PostgreSQL extension. Qdrant is a dedicated vector search engine. LanceDB is a multimodal lake plus ANN on the Lance format. They differ on where the rest of the row lives, how you filter, and whether media bytes sit in the same table.

Updated: 2026-10-28
Part of [What is an embedding index?](https://www.pixeltable.com/learn/what-is-an-embedding-index).

## On this page

- [Three vector stores](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#what-it-is)
- [pgvector](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#pgvector)
- [Qdrant](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#qdrant)
- [LanceDB](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#lancedb)
- [How to choose](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#how-to-choose)
- [Last reviewed](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#review)
- [Comparison](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#comparison)
- [Where Pixeltable fits](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#where-pixeltable-fits)
- [Questions](https://www.pixeltable.com/learn/pgvector-vs-qdrant-vs-lancedb#questions)

## Three vector stores {#what-it-is}

All three answer nearest-neighbor queries. The split is the rest of the application: SQL joins, payload filters on a dedicated engine, or blobs in a Lance table.

## pgvector {#pgvector}

pgvector is open-source vector similarity search for Postgres: vector columns, exact search, and HNSW or IVFFlat indexes, with SQL joins and filters on the rest of the row. Any host that runs the extension (self-managed Postgres, Supabase, Neon, and others) can serve it. Media usually lives in object storage you add. Repo: https://github.com/pgvector/pgvector

## Qdrant {#qdrant}

Qdrant is an open-source vector search engine written in Rust. Collections hold points: vectors plus payload. Payload indexes extend the HNSW graph so filters apply during search. It supports dense and sparse vectors, BM25 on a text field, and deployments from OSS to Qdrant Cloud, Hybrid Cloud, and Private Cloud. Docs: https://qdrant.tech/documentation/overview/

## LanceDB {#lancedb}

LanceDB stores images, video, audio, text, embeddings, and features in one Lance table and serves vector search, full-text search, hybrid search, reranking, filtering, and SQL. OSS is an embedded library. Enterprise is a distributed lakehouse. Docs: https://docs.lancedb.com/

## How to choose {#how-to-choose}

Start from the system of record you already run.

- Pick pgvector when Postgres already holds the application row and SQL is how you join and filter.
- Pick Qdrant when a dedicated ANN service with rich payload filters is the serving contract.
- Pick LanceDB when multimodal blobs and vectors should share one Lance table, embedded or as a lakehouse.

## Last reviewed {#review}

Facts on this page were checked against vendor documentation on 2026-10-28. Product surfaces move; treat version names and APIs as directional and follow the official links in Related.

## pgvector vs Qdrant vs LanceDB (last reviewed: Oct 2026) {#comparison}

|  | pgvector | Qdrant | LanceDB |
| --- | --- | --- | --- |
| What it is | Postgres extension for vector columns | Dedicated vector search engine (Rust) | Multimodal lake plus ANN on Lance |
| Where the rest of the row lives | The same Postgres row | Payload on the point; files usually elsewhere | The same Lance table (blobs, features, vectors) |
| Filters | SQL WHERE | Payload indexes on HNSW; sparse and BM25 options | SQL-style filters, FTS, hybrid, rerank (vendor docs) |
| Ops | Whatever already runs Postgres | OSS server or Qdrant Cloud / Hybrid / Private | Embedded OSS process, or Enterprise |
| Best for | Teams already on Postgres | Filtered ANN as a separate service | Lake layout and embedded or lake-scale retrieval |
| Official docs | https://github.com/pgvector/pgvector | https://qdrant.tech/documentation/overview/ | https://docs.lancedb.com/ |

## Where Pixeltable fits {#where-pixeltable-fits}

Use Pixeltable when the index should be declared on the table that holds the passage or frame, so insert and delete keep it current, and typed media can sit on the same schema. Pixeltable is not a drop-in Qdrant cluster and not a Lance lakehouse. Keep pgvector when Postgres is already the system of record and you will embed in a worker you write. Keep Qdrant when that engine is the serving contract. Keep LanceDB when Lance layout is the product; export with pxt.io.export_lancedb when you want that engine.

```python
import pixeltable as pxt
from pixeltable.functions.huggingface import sentence_transformer

TableModel = pxt.model_base()
embed = sentence_transformer.using(
    model_id='sentence-transformers/all-MiniLM-L6-v2'
)

class Passages(TableModel, name='passages'):
    text: pxt.String
    source: pxt.String
    __indexes__ = [
        pxt.EmbeddingIndex(text, string_embed=embed),
    ]

@pxt.query
def search_passages(query: str, limit: int = 5):
    sim = Passages.text.similarity(string=query)
    return (
        Passages.order_by(sim, asc=False)
        .limit(limit)
        .select(Passages.text, Passages.source, sim)
    )
```

## Questions {#questions}

### Is pgvector enough instead of Qdrant? {#faq-1}

Often, if Postgres already holds the row and the vector count and QPS fit one Postgres instance. Qdrant is the better fit when filtered ANN, sharding, and a dedicated engine are the contract.

### Does LanceDB replace pgvector? {#faq-2}

Only if you move the serving index onto Lance tables. pgvector stays when SQL joins on Postgres rows are the product. LanceDB stays when blobs and vectors share a Lance table.

### Where do the video files live? {#faq-3}

With pgvector and Qdrant, usually in object storage, with a URL or id in payload or SQL. With LanceDB, as blob columns in the Lance table (or external URIs). With an application schema, as a typed Video column.

### Do I still need to embed myself? {#faq-4}

Yes for pgvector and typically for Qdrant and LanceDB unless you add their embedding functions or an integrated inference product. An EmbeddingIndex on a source table embeds on insert as part of the schema.

## Related

- [Best Pinecone alternatives](https://www.pixeltable.com/learn/best-pinecone-alternatives)
- [Best LanceDB alternatives](https://www.pixeltable.com/learn/best-lancedb-alternatives)
- [Best Weaviate alternatives](https://www.pixeltable.com/learn/best-weaviate-alternatives)
- [Do I need a vector database if I use Postgres?](https://www.pixeltable.com/learn/do-i-need-a-vector-database-if-i-use-postgres)
- [Pixeltable vs LanceDB](https://www.pixeltable.com/compare/pixeltable-vs-lancedb)
- [Pixeltable vs Weaviate](https://www.pixeltable.com/compare/pixeltable-vs-weaviate)
- [pgvector](https://github.com/pgvector/pgvector)
- [Qdrant overview](https://qdrant.tech/documentation/overview/)