pgvector

pgvector adds a vector column type and similarity search to PostgreSQL. AddisDB gives it a dedicated engine entry because embeddings deserve their own view: any result holding a vector column gets a Vectors tab that projects your embeddings into two dimensions so you can see how they cluster.

Who it is for

pgvector is the pragmatic answer to "we need semantic search." Your embeddings live next to the rows they describe, so a similarity search can be filtered by tenant, date or status in the same query — no second datastore to keep in sync, no consistency gap between the vector index and the source of truth.

The filtering point is the real argument. In a standalone vector database, a metadata filter is applied around an approximate search, so a narrow filter can leave you with far fewer results than you asked for. In Postgres, the planner treats the vector index as one more access path and can combine it with an ordinary B-tree predicate.

Use it for retrieval-augmented generation, semantic search over your own content, recommendations, and deduplication — especially when you are already running Postgres and the vector count is in the millions rather than the billions.

Set up the extension

1. Most managed Postgres now ships pgvector — Neon, Supabase, RDS and Cloud SQL all support enabling it.
2. Run CREATE EXTENSION vector; in the database that needs it.
3. Add a vector column with the dimension your embedding model produces — 1536 for OpenAI text-embedding-3-small, 1024 for many open models.
4. Create an index once you have data: HNSW for the best recall/speed balance, IVFFlat when build time matters more.
5. Self-hosted: install the extension package, or use the pgvector/pgvector Docker image.

CREATE EXTENSION IF NOT EXISTS vector;

ALTER TABLE documents ADD COLUMN embedding vector(1536);

CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops);

The dimension is fixed at column creation and has to match your model exactly. Changing embedding models later means a new column and a re-embedding pass, so it is worth deciding deliberately rather than by default.

Connect from AddisDB

1. New Connection → pgvector under Vector / AI. Port prefills to 5432 — it is a normal Postgres server.
2. Fill host, port, database, username and password, or paste a connection URL and click Fill fields.
3. Set SSL mode to require for a managed database.
4. Test, then Save.

Seeing your embeddings

Select a vector column and a Vectors tab appears next to Table, Text, Chart and JSON. It projects the embeddings down to two dimensions and plots them, which makes clustering — and the outliers that are quietly wrecking your retrieval quality — visible at a glance.

-- Nearest neighbours by cosine distance
SELECT id, title, embedding <=> '[0.01, -0.2, …]'::vector AS distance
FROM documents
ORDER BY distance
LIMIT 10;

A projection is a lossy summary, not a map of the true space — but it answers the questions that matter in practice: is everything collapsing into one blob, are there documents sitting nowhere near their neighbours, did a batch of embeddings get written with the wrong model.

Getting search quality right

• Match the operator to the index. <-> is L2, <=> is cosine, <#> is inner product, and an index built for one is not used by another — the query still returns rows, just slowly and by scanning.
• Order by the distance expression itself. Wrapping it in a function or aliasing it away can stop the planner from using the index.
• HNSW recall is tunable at query time with hnsw.ef_search: raise it for better results, lower it for speed.
• Normalize vectors when your model expects it, or cosine and inner product will disagree with each other.
• Check that the index is actually being used with EXPLAIN — an index scan says so; a sequential scan on a large table is the whole problem.

Everything Postgres gives you, too

• The full schema diagram, in-grid editing and ⌘K search.
• Live Monitor with active queries, blocking and locks — vector index builds are exactly the kind of long operation worth watching.
• Test clones for trying an index change against a disposable copy of the database.
• Mock data, migrations and diff, and AI querying grounded in your real schema.