Vector databases: store meaning with identity and permissions

Store more than the vector

A useful record includes a chunk ID, parent document ID, text or a reliable text reference, source location, document version, embedding version, and access scope. You also need a deletion/update process. If the text changes while the vector remains old, the record has become internally inconsistent.

Permissions come from the authenticated application context. Do not let a model invent a tenant ID and treat it as authority. Restrict the candidate set to permitted records, and verify retrieved records again before they enter the prompt. Sending private text to the model and filtering the final answer afterward is too late.

Understand exact and approximate search

Exact search compares against the full eligible set. It is a useful baseline and may be sufficient for a small corpus. Approximate nearest-neighbor indexes trade some recall for speed or resource efficiency. HNSW uses a graph structure; IVF organizes candidates into partitions; product quantization compresses representations. Those methods have different operational tradeoffs.

An index does not automatically make search better. Measure the overlap with an exact baseline, query time, memory, ingestion cost, and performance after filters. A selective filter can interact with approximate search so fewer candidates survive than expected. Check the database's documented behavior instead of assuming top-k always returns k useful permitted records.

Inspect a small SQL example

The following SQL is a local demonstration for PostgreSQL with pgvector installed. The three-dimensional values are invented so you can see ordering. They are not real embeddings. Production dimensions must match the chosen model, and application inputs must use parameterized queries.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE tutorial_chunks (
  id text PRIMARY KEY,
  tenant_id text NOT NULL,
  body text NOT NULL,
  embedding vector(3)
);
INSERT INTO tutorial_chunks VALUES
 ('returns', 'northstar', 'Return policy', '[1,0,0]'),
 ('delivery', 'northstar', 'Delivery policy', '[0,1,0]');
SELECT id, body, embedding <=> '[0.9,0.1,0]' AS distance
FROM tutorial_chunks
WHERE tenant_id = 'northstar'
ORDER BY embedding <=> '[0.9,0.1,0]'
LIMIT 2;

Here <=> is cosine distance, so lower values rank first. This plain query illustrates exact search; adding an approximate index is a separate decision. The literal tenant filter shows the concept, but a real application must derive that scope from verified identity and enforce database access policy.

Choose around the surrounding system

An existing PostgreSQL application may benefit from keeping vectors near relational metadata. A dedicated service may suit a different scale or operations model. Compare backup and recovery, filtering, deployment, data residency needs, monitoring, supported indexes, and the team's ability to maintain the system.

Run a small workload with representative filters before committing. Include updates and deletions in the experiment, not only inserts and searches. A system that returns yesterday's excluded document quickly is not working correctly, regardless of its benchmark latency.

References and further reading

Use these primary references for deeper study and current API details. Examples in this lesson use fictional Northstar data.

• pgvector documentation — pgvector