Hi Temporal Support,
New to temporal, I’m running a dev self-hosted Temporal cluster and need clarification on the correct upgrade procedure for our setup. Here are our specifics:
Environment:
- Helm chart: temporalio/temporal 0.73.2 (from ArtifactHub)
- Database: AWS RDS PostgreSQL (external — not a bundled sub-chart)
- Current values.yaml has: schema.setup.enabled: true and schema.update.enabled: true
What we understand so far:
- The Helm chart’s schema.update job runs as a pre-upgrade Helm hook
- Temporal requires sequential minor version upgrades — skipping versions is not supported
- The DB schema must be migrated BEFORE the new server version is deployed
Our questions:
-
For our setup, is it safe to rely on schema.update: true in values.yaml to run migrations automatically on each sync? Or is this known to be unreliable?
-
If we should run migrations manually, the approach we are planning is:
a. Before syncing, run a one-off job using the new version’s admin-tools image
b. Let the Job run temporal-sql-tool update-schema against our RDS for both the default and visibility stores
c. Once the Job completes successfully, deploy the new server version
Is this the correct and recommended approach? -
If we are multiple minor versions behind (e.g. currently on 1.29.1 and targeting 1.30.0), do we need to run the migration Job and sync separately for each intermediate minor version? Or can we run all schema migrations first and then deploy the final target version in one sync?
-
Should we set schema.update: false in values.yaml if we are managing migrations manually, to prevent the chart from attempting to run its own migration job on sync? Is this recommended setup for production using helm chart?
Thank you for your help, we want to make sure we have the right process before deploying to staging environment