Supported versions
Connection settings
Decision Control reads the standard Spring datasource environment variables (Spring relaxed binding maps them tospring.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 byHIBERNATE_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: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=updatefor the first rollout that introduces a schema change, then return tovalidate. - 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:sslrootcert. Use verify-full in production so the driver validates the server hostname against the certificate.
Verifying
After deploying, confirm the application reaches theStarted 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:
-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
--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 runningpg_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.).