pgvector extension is required; if it cannot be created, the extension-creation error is caught and logged, but knowledge ingestion and retrieval will fail at runtime.
Image and port
What IMP does on first connection
The backend auto-creates the target database if it does not exist, then enables thevector extension and sets a per-connection HNSW search parameter on every new connection.
Auto-create database. On startup the backend connects to the system postgres database with the configured credentials and runs CREATE DATABASE <name> if the target does not already exist. If the user lacks the CREATEDB privilege the step fails with a warning logged to stdout and IMP continues, assuming the database already exists.
Enable pgvector. After connecting to the application database, IMP runs:
hnsw.ef_search = 20 is the recall/speed trade-off for approximate nearest-neighbour queries. Increase it if knowledge retrieval misses relevant chunks; decrease it if ANN queries are too slow.
Connection pool
The application-level pool (Knex +node-postgres) is configured with:
A 300-connection ceiling means Postgres’s
max_connections must be at least 300 (plus a margin for the frontend’s own pool and the LiteLLM database). The default max_connections = 100 in vanilla Postgres is not enough for production IMP deployments.
Vector tables
IMP creates per-context item and chunk tables that include avector(N) column, where N comes from the dimensionality field in the LiteLLM model registry entry for the configured embedding model. Changing the embedding model after initial setup requires migrating or recreating these tables, because pgvector column dimensionality is fixed at creation time.
Configuration reference
Compose excerpt
Operational notes
Separate LiteLLM database. The LiteLLM proxy requires its own dedicated Postgres database (set viaLITELLM_DATABASE_URL). It must not share the same database as IMP. Pointing both at the same database causes the LiteLLM schema sync to drop IMP tables. See LiteLLM service for details.
initdb runs on every boot. The database initialisation routine (initdb) runs on every backend startup and is fully idempotent — existing tables are not touched. New columns are added with ALTER TABLE … ADD COLUMN IF NOT EXISTS.
Backup before schema changes. IMP does not run destructive migrations. However, adding a new embedding model with a different dimensionality and re-indexing knowledge will write new data into the database. Back up before changing the embedding model in production.