Released: 12 Oct 2026
This release introduces named model credentials. Any member of aidb_users can now create models that use an API key, without a superuser. See Model credentials.
Upgrading from 7.7.0 keeps existing models working, but changes how their secrets are stored and who can use them. Review Upgrading from 7.7.0 before you upgrade.
AIDB 7.8.0 includes the following enhancements, changes, and bug fixes:
| Type | Description |
|---|---|
| Enhancement | Named model credentials: Store a model's API key in a named credential that you can share with other roles and limit to specific hosts. See Model credentials. |
| Enhancement | aidb_admins role: A new role for managing secrets read from environment variables and Kubernetes Secrets. See Managing credential access with the aidb_admins role. |
| Change | Models use credentials: aidb.create_model() takes a new credential argument, and aidb.delete_model() no longer deletes the model's secret. See aidb.create_model. |
| Change | aidb.model_providers columns changed: The server_name, server_description, and server_options columns are replaced. Update queries that read them. See aidb.model_providers. |
| Change | Model name resolution: A bare model name that matches models in more than one schema now raises an error. See Model names. |
| Change | TLS verification for models with secrets: A model whose credential holds a secret can't skip TLS certificate verification. See TLS configuration. |
| Change | Redirect handling: Requests to model providers, MCP servers, and the OpenTelemetry exporter follow a redirect only to the same origin. See Configuring AIDB. |
| Change | run_sql_query native tool: The tool refuses queries that read user mappings. See Native tools. |
| Bug fix | Models with secrets for non-superusers: Members of aidb_users can now create, use, and delete models that use an API key. |
Upgrading from 7.7.0
In 7.7.0, each model provider was a Postgres foreign server, called a provider server here, and held its secrets as user mappings. In 7.8.0, credentials replace these foreign servers.
Run ALTER EXTENSION aidb UPDATE to perform the update (from any previous version of AIDB). The update will perform the following changes to pre-existing configuration:
- Provider servers with a secret become shared credentials named after the provider, for example
openai_completions. They're owned by the superuser that installed AIDB and are pinned to the provider's default host plus the hosts their models call. The upgrade warns for each credential that allows hosts beyond the provider default. Review them inaidb.credentialsand narrow them withaidb.update_credential(). A credential whose models call no network host gets the endpoint*and is made private. - Members' models now authenticate. In 7.7.0, models that non-superusers used on a provider with a secret sent requests without the key. After the upgrade, those requests include the shared credential's key.
- Per-role secrets stay in the catalog but are no longer used. The upgrade warns for each credential that has them. Drop them with
DROP USER MAPPING FOR <role> SERVER <credential>;. A provider server that had only per-role secrets becomes a credential without a secret. Its models fail until the owner sets one withaidb.update_credential(). - Provider servers without a secret are removed. Their models move to the
nonecredential and keep their name, schema, and owner. They get a new object identifier and lose comments and grants on the model table. This includes the default local models. - Scripts that relied on a shared provider secret must pass
credential => '<name>'toaidb.create_model(). A later model on the same provider no longer uses a secret set by an earlieraidb.create_model()call. - Secrets from environment variables or Kubernetes Secret files keep working. Their credentials are owned by the superuser that installed AIDB.
- MCP servers registered before the upgrade are owned by
aidb_users, so every member can still refresh and delete them. Servers that useheaders_envorheaders_k8s_secretare owned by the role that installed AIDB, and only that role can refresh or delete them. The upgrade warns with their names. Review their URLs. - An existing
aidb_adminsrole is used as is, and its members become admins. The upgrade warns with their names.