Solutions · Vector search & RAG

Vector search on the database you already trust.

pgvector turns Postgres into a perfectly good vector store for RAG, semantic search, and recommendations. Index with IVFFlat for speed or HNSW for recall — both shipped enabled.

Start free

Why Postgres for vectors

A vector store does not need to be a separate product. pgvector adds a `vector` column type and ANN indexes to Postgres so you can run similarity searches in the same database that holds the rest of your application state — filter by tenant, join with metadata, paginate with cursors, all in one query. For most RAG workloads up to tens of millions of vectors, this is simpler, cheaper, and easier to operate than a dedicated vector database.

IVFFlat for low-latency ANN

Inverted-file index with flat lists. Fast queries, configurable `lists` and `probes` to trade recall against latency.

HNSW for high recall

Hierarchical Navigable Small World graph. Slower to build but much better recall at the same latency budget for high-dimensional embeddings.

Hybrid queries

Combine vector similarity with WHERE clauses on other columns. No second store to keep in sync.

Multiple distance metrics

L2 (`<->`), inner product (`<#>`), and cosine (`<=>`). Pick the right one for your embedding model.

Code sample

sql

Enable pgvector and index a 1536-dim embedding table

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (
  id           BIGSERIAL PRIMARY KEY,
  doc_id       BIGINT NOT NULL,
  body         TEXT NOT NULL,
  embedding    vector(1536) NOT NULL
);

-- IVFFlat index: 100 lists is a good starting point for ~1M rows.
CREATE INDEX chunks_embedding_ivfflat
  ON chunks USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

-- At query time, set the number of lists to probe.
SET ivfflat.probes = 10;

-- Find the 5 nearest chunks within a specific document.
SELECT id, body
FROM chunks
WHERE doc_id = 42
ORDER BY embedding <=> $1::vector
LIMIT 5;

Indexing strategy

Start with IVFFlat at `lists = sqrt(rows)` and `probes = lists/10`. Measure recall on a held-out set. If recall is too low for your use case, raise `probes` (slower queries, higher recall) or switch to HNSW. HNSW indexes are slower to build but give you better recall at the same latency on 1k+ dim embeddings.

Examples

RAG chatbots — index your knowledge base, retrieve top-K chunks per query
Semantic product search — embed product titles + descriptions, search by intent
Document deduplication — find near-duplicates above a similarity threshold
Recommendation systems — user-embedding × item-embedding nearest neighbors

Frequently asked questions

How many vectors before I need a dedicated vector DB?

Most workloads under ~10M vectors at 1536 dimensions run comfortably on a single Postgres cluster. Above that, consider sharding by tenant or moving the embedding column to a dedicated cluster.

Do I need to rebuild the index when I insert new rows?

No — pgvector indexes support incremental inserts. Rebuild only when you change the `lists` parameter or move from IVFFlat to HNSW.

Can I store metadata alongside the vector?

Yes — that is the whole point of pgvector over a dedicated store. Add columns, foreign keys, partitions; filter, join, paginate as usual.

Ship vector search on the database you know.

pgvector is enabled by default on every Luceris Postgres cluster, including the Free tier.

Start free Talk to us