Skip to main content
Decision Control persists its state (models, decisions, published versions) in a relational database. PostgreSQL is the supported engine — every deployment described in this guide uses it.

Supported versions

Connection settings

Decision Control reads the standard Spring datasource environment variables (Spring relaxed binding maps them to spring.datasource.*): A production deployment must point these at a managed PostgreSQL instance reachable from the application. In Kubernetes, the URL typically uses the in-cluster service DNS (e.g. jdbc:postgresql://postgres.infra.svc.cluster.local:5432/dc).

Schema management

The schema is created and migrated automatically on startup, controlled by HIBERNATE_DDL_AUTO: For production, provision an empty database, run a first boot with update to create the schema (or apply the schema out-of-band), then switch to validate for subsequent deployments so an unexpected entity change can never silently alter the production schema.

Provisioning

Create a dedicated database and least-privilege application role:
The application role needs CONNECT, CREATE (for first-boot schema creation under update), and full DML on its own schema. Once the schema is created and you switch to validate, you may drop CREATE from the role.

Optional read-only role

For monitoring or BI access without write privileges:

Upgrade considerations

  • Schema changes ship with the application image. Deploy a new image with HIBERNATE_DDL_AUTO=update for the first rollout that introduces a schema change, then return to validate.
  • Take a database backup before any upgrade that changes the schema.
  • Schema changes are additive within a major line; a downgrade after a schema change is not supported without restoring from backup.

TLS to the database

Append SSL parameters to the JDBC URL when the database requires encrypted connections:
Mount the CA certificate into the container and reference it with sslrootcert. Use verify-full in production so the driver validates the server hostname against the certificate.

Verifying

After deploying, confirm the application reaches the Started AletyxDcApplication log line and that /actuator/health returns 200 OK before allowing traffic. A datasource problem surfaces as a Hibernate / HikariCP connection error in the logs and a DOWN health status.

Backup and recovery

Treat the Decision Control database the same as any other application Postgres: nightly logical backups plus point-in-time recovery for production. The application is stateless apart from this database — restoring it is the only step needed to recover the deployment state (models, decisions, versions, audit trail).

Scheduled pg_dump (Kubernetes example)

A simple CronJob running the postgres image is enough for the application database. The example below assumes the database hostname is <your-db-host>, the connection credentials live in a Secret named dc-db-secret, and the persistent backup volume is dc-backup-pvc:
The -F c (custom format) output is required by pg_restore. Keep at least 7 daily backups plus one weekly retained for 30 days; the volume sizing is dominated by version history rather than active model count.

Restore

Restoring into a database that already has data (an upgrade rehearsal, for example) is supported with the --clean flag shown above; the schema and rows are dropped before being recreated. Restoring into an empty database produces the same final state.

Managed PostgreSQL services

For Cloud SQL / RDS / Azure Database, prefer the platform’s own snapshot and point-in-time recovery rather than running pg_dump from inside the cluster. The result is faster and integrates with your platform’s RBAC and audit. Use logical dumps for cross-environment migrations only (dev → staging refresh, etc.).