Skip to main content

Fully external database management

Use this approach when the DBA or customer tooling must control database provisioning, user authorization, and the timing of schema migrations. Configure component database patterns with Database Management set to disabled.

Prepare the database​

For each database, the DBA or customer provisioning service must:

  1. Create the database and schema.
  2. Create the schema-owner and application users.
  3. Apply all required grants and default privileges.
  4. Create required extensions, such as PostgreSQL citext.
  5. Run the component dbschema image as a migration job before the first component deployment.
  6. Repeat the migration job before each upgrade that changes the component schema.
  7. Store the application-user credentials as a nevisAdmin secret or Kubernetes Secret, and reference it from the pattern. If a vault integration is used, synchronize the credentials into a Kubernetes Secret consumed by the pattern.

The schema-owner credentials must be available to the migration job but must not be placed in the running component configuration.

Install nevisAdmin 4​

The nevisAdmin 4 Helm chart has its own dbschema job and credential configuration. Use the pre-provisioned database and users procedure for the nevisAdmin 4 database when the chart's database user must be restricted. In particular, pre-create the database and citext extension so that CREATEROLE is sufficient.

The disabled setting described on this page applies to component database patterns. Do not assume that setting a component pattern to disabled disables nevisAdmin 4 database initialization.

Configure the component pattern​

For each component database pattern:

  1. Configure the database connection.
  2. Set Database Management to disabled.
  3. Provide only the application-user credentials to the component pattern.
  4. Deploy the project after the external migration job has completed successfully.

nevisOperator does not create the database or users and does not run schema migrations for the component. It deploys the component pod with the pre-created application user.

Migration job and upgrades​

The migration job must use the component dbschema image that matches the component version. Run it as a one-off Kubernetes Job with the schema-owner credentials. Configure the job with NEVIS_DBSCHEMA_BOOTSTRAP=false so it skips role manipulation and runs the schema migration only.

Treat the migration job as part of the release process. Do not deploy a component upgrade until the external migration has completed successfully.

Trade-offs​

This approach gives the DBA complete control over database changes and requires no database management privileges in nevisOperator. It is the appropriate choice when migrations require explicit DBA approval or must run in a separately controlled release process. It also adds operational work: the external process must prepare every database, run migrations before upgrades, and keep the migration image and credentials in sync with the deployed component version.