Vector DB (pgvector)

The pgvector database stores the embeddings used by the RAG API. Its VECTORDB_* image keys and the shared DB_*/POSTGRES_* keys in config/.env, storage, backup basics, and links to the official pgvector/Postgres docs.

The Vector DB is a PostgreSQL database with the pgvector extension. It stores the document embeddings produced by the RAG API and serves nearest-neighbour similarity searches for file chat.

Overview


Compose file	`config/rag.compose.yml` (bundled with the RAG API)
Service name	`vectordb`
Module	`vectordb` (optional — `intelliask module disable vectordb`)
Image variable	`VECTORDB_IMAGE` (e.g. `pgvector:0.8.0-pg16`)
Exposed	internal only
Data	bind-mounted at `${STORAGE_ROOT}/postgres-vector` → `/var/lib/postgresql/data`
Consumed by	the RAG API

Environment variables

The Vector DB has its own image/resource keys and shares the database credentials with the RAG API:

`config/.env` key	Default	What it does
`VECTORDB_IMAGE`	`pgvector:0.8.0-pg16`	Image + tag to run.
`VECTORDB_CPUS`	`0.5`	CPU ceiling.
`VECTORDB_MEMORY`	`256m`	Memory ceiling.
`POSTGRES_DB`	`IntelliAsk`	Database name (shared with the RAG API).
`POSTGRES_USER`	`intelliask`	Database user (shared with the RAG API).
`POSTGRES_PASSWORD`	(auto-provisioned)	Database password (shared with the RAG API).

Credentials are bootstrapped once

POSTGRES_* are applied only on the first start with an empty data volume. Changing POSTGRES_PASSWORD later does not re-create the role — rotate it inside Postgres or wipe the volume. Because these keys are shared with the RAG API, always keep both services in sync.

After editing any value, apply with:

intelliask up vectordb

Storage & backup

Data is bind-mounted at ${STORAGE_ROOT}/postgres-vector, so embeddings survive container recreation. The stack-wide intelliask backup dumps this database (and MongoDB) plus the config in one step:

intelliask backup                 # DBs + config -> <storage>/backups/<timestamp>/

See Backup & restore for rotation and scheduling. To dump the vector DB on its own, use pg_dump against the container:

docker compose exec vectordb \
  pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc -f /var/lib/postgresql/data/vectordb.dump

Restore with the matching pg_restore. Re-embedding from source files is also an option since the RAG API can re-ingest uploads.

Using an external vector DB instead

The bundled pgvector database is an optional module. To point the RAG API at an external Postgres/pgvector instance instead:

Disable the bundled one: intelliask module disable vectordb.
Point DB_HOST / DB_PORT at the external database and set POSTGRES_DB / POSTGRES_USER / POSTGRES_PASSWORD to match it (the database must have the pgvector extension available).
intelliask up.

Resource limits

The defaults (VECTORDB_CPUS=0.5, VECTORDB_MEMORY=256m) suit a modest vector store. Raise VECTORDB_MEMORY for large corpora — Postgres benefits from more cache for index scans.

Updating the Vector DB

# 1. Bump the tag in config/.env, e.g. VECTORDB_IMAGE=pgvector:0.8.0-pg17
# 2. Pull + recreate only the Vector DB
intelliask update vectordb

Postgres major upgrades need care

A PostgreSQL major version bump (e.g. pg16 → pg17) changes the on-disk format and needs a dump/restore migration — you can't just swap the tag. Back up first and follow the upstream upgrade guide. Minor/extension bumps (e.g. pgvector 0.8.0 → 0.8.x on the same pg16) are safe in place.