Changes and upgrades
Review dedicated cluster history and queue supported TigerBeetle upgrades.
Dedicated databases provide an operational change history under Cluster > Changes. Developer shared infrastructure and TigerBeetle versions are managed by Parix, so the Cluster surface and self-service version upgrade are not available for shared databases.
Read the Changes tab
The page shows up to 100 recent database cluster changes. Each row contains:
- a human-readable change description
- status
- actor
- start time
- end time, when the change reached a terminal state
Change status moves through Pending, In progress, and then Completed or Failed.
The Changes tab is an operational history, not a complete workflow trace or organization audit log. It currently covers initial cluster creation and supported cluster, storage, parameter, CDC, and TigerBeetle version changes. Use the organization Audit Log when you need administrative-event history.
Upgrade the TigerBeetle version
Only organization owners and admins can queue an upgrade.
- Open the dedicated database.
- Select Settings.
- In TigerBeetle version, compare Current with Configured target.
- Select an available target version.
- Select Upgrade database.
Parix validates the requested transition before queueing work. An upgrade is rejected or skipped when:
- the target is not enabled for this database
- the current version is already the target
- provisioning or deletion is active
- organization billing is not ready
- required provider metadata is unavailable
- the requested in-place configuration change is unsafe for the current storage or provider shape
Some supported version transitions run through intermediate versions. Parix plans those hops; select only the final available target shown in the dashboard.
During and after an upgrade
Once accepted, the database profile returns to provisioning while the durable workflow applies the change. The Changes tab starts at Pending; the corresponding organization notification starts at Queued. Both later move through In progress to Completed or Failed.
On success, the current TigerBeetle version and profile return to active. On failure, the profile becomes error and the Changes row records Failed. The Changes table does not display the stored workflow error. Record the failed row and its timestamps, check the linked notification and available logs, and include those details when contacting support before queueing more work.
Cluster size, topology, storage, and parameter controls use the same asynchronous model. The dashboard may require a backup-driven migration or instruct you to create a new database when an in-place change is unsupported. Storage changes never allow reducing the current disk size.