Enterprise database (pgvector)

greatmemory's Postgres backend stores embeddings in a vector column, so the database needs the pgvector extension. On a database where the application role has the right privileges, this is invisible: on first startup the engine runs CREATE EXTENSION IF NOT EXISTS vector automatically and gets on with it.

Enterprise and managed databases are usually not like that. The role your application connects with frequently cannot run CREATE EXTENSION — it is reserved for a DBA/superuser, and on several managed platforms the extension must be allow-listed at the server level before anyone can create it at all. This page covers how to run greatmemory against those databases.

The assume-pgvector flag

For databases where a privileged role pre-provisions pgvector and the application role has only ordinary DML/DDL rights, set:

GM_DB_ASSUME_PGVECTOR=1

or in greatmemory.toml:

db_assume_pgvector = true

With this flag greatmemory will not attempt CREATE EXTENSION. Instead it verifies that pgvector is already present and fails fast with a clear message if it is not — so a misconfigured database surfaces immediately at startup rather than at the first write.

The engine still manages its own schema (tables and indexes) using ordinary DDL inside the database. Only the extension itself is DBA-gated; everything else is handled by the normal migration path. See Upgrades & migrations.

Provisioning pgvector per platform

In every case a privileged role runs the same one line once, in the target database:

CREATE EXTENSION vector;

What differs is the privilege model and whether the platform requires allow-listing the extension first.

AWS RDS / Aurora PostgreSQL

pgvector is on the supported-extensions list for PostgreSQL 15 and later. A user holding the rds_superuser role runs:

CREATE EXTENSION vector;

No parameter-group change is needed for pgvector itself on modern versions.

Azure Database for PostgreSQL Flexible Server

pgvector must be allow-listed first — add VECTOR to the azure.extensions server parameter:

az postgres flexible-server parameter set \
  --resource-group <rg> --server-name <server> \
  --name azure.extensions --value VECTOR

(Or set it from the Portal under Server parameters.) Then a privileged role runs:

CREATE EXTENSION vector;

GCP Cloud SQL for PostgreSQL

Supported on PostgreSQL 15 and later. A privileged user runs:

CREATE EXTENSION vector;

No instance flag is required on current versions.

Self-managed / on-prem enterprise Postgres

Install the pgvector package on the database server first — your distribution's package (for example postgresql-15-pgvector) or a build from source — then a superuser or the database owner runs, in the target database:

CREATE EXTENSION vector;

Recommended enterprise flow

1. DBA provisions pgvector once. A privileged role runs CREATE EXTENSION vector; in the target database (and, on Azure, allow-lists VECTOR first).
2. Create the greatmemory database and role with only DML rights. The application role needs no CREATE EXTENSION privilege — it only reads and writes data and manages greatmemory's own tables.
3. Set GM_DB_ASSUME_PGVECTOR=1 (or db_assume_pgvector = true) so the engine verifies rather than creates the extension.
4. Deploy. On startup greatmemory confirms pgvector is present, applies any pending schema migrations within the database, and begins serving.

This keeps the privileged, DBA-gated step (the extension) separate from the day-to-day role, which is exactly the separation regulated environments expect.

Troubleshooting

If pgvector is missing when GM_DB_ASSUME_PGVECTOR is set, greatmemory refuses to start and prints:

error: pgvector extension not found in the configured database, but
GM_DB_ASSUME_PGVECTOR is set. Have a privileged role run
`CREATE EXTENSION vector;` in this database (on Azure, first add VECTOR to the
azure.extensions server parameter).

The fix is the DBA step above: a privileged role runs CREATE EXTENSION vector; in the database greatmemory connects to (and on Azure, allow-list VECTOR in azure.extensions first). Once the extension exists, restart greatmemory and startup verification passes.

If you see the same missing-extension condition without the flag set, the application role lacks permission to run CREATE EXTENSION — switch to the enterprise flow above (provision once as a DBA, then set GM_DB_ASSUME_PGVECTOR=1).

See also

• AWS — RDS / Aurora PostgreSQL with pgvector
• Azure — PostgreSQL Flexible Server and the azure.extensions allow-list
• Google Cloud — Cloud SQL for PostgreSQL with pgvector
• Upgrades & migrations — how the engine manages its own schema