Parameter configurations

Use Cluster → Parameters for the small set of TigerBeetle runtime controls that Parix currently exposes.

This is not a generic key-value parameter editor. The current product supports:

• changing Cache grid size on GCP deployments
• queuing Restart replicas to refresh the current bootstrap configuration on existing GCP replicas

Availability by plan and provider

Before you begin

You need:

• an organization owner or administrator role
• a Dedicated or Production GCP database with an active profile
• no workflow currently holding the profile in Provisioning
• a maintenance window if restarting the only replica would interrupt traffic
• a reason to override the size-derived default; a larger cache leaves less memory for other runtime and system needs

Use Metrics to record a baseline before changing cache behavior.

Open Parameter configuration

1. Select the organization.
2. Open the database from Dashboard.
3. Select Cluster.
4. Select Parameters.

The page shows Current cache grid and New cache grid before you submit anything.

Cache grid controls

Cache grid size is entered in MiB through a synchronized slider and numeric field.

• Minimum: 512 MiB
• Step: 128 MiB
• Maximum: derived from the database's memory per node while reserving TigerBeetle and system headroom

For a small cluster size whose derived maximum is 512 MiB, the page reports This cluster size uses the fixed minimum cache grid and disables the adjustment.

The submitted value is normalized to TigerBeetle notation, for example 512MiB. Comparison is case-insensitive after normalization, so spelling changes such as mib versus MiB do not create a workflow.

Change the cache grid

1. Compare Current cache grid with New cache grid.
2. Move the slider or enter a value in the numeric field.
3. Keep the value within the displayed minimum and maximum and on a 128 MiB step.
4. Select Queue parameter changes.
5. Open Changes and follow the parameter-change row.
6. After completion, return to Metrics and compare cache hit behavior and replica health with your baseline.

If the normalized value matches the active profile, the queue button remains disabled or Parix reports No parameter changes to queue.

Refresh bootstrap configuration

Use Refresh bootstrap on existing replicas only when a Parix startup-script or bootstrap change needs to be applied to an already provisioned GCP cluster.

1. Confirm that the active configuration should remain otherwise unchanged.
2. Schedule a restart window, especially for a single-node database.
3. Select Restart replicas.
4. Follow the new row in Changes until completion.

This action forces a rolling restart. It does not change the cluster size or cache-grid value.

Workflow and status behavior

Both actions queue the shared upgrade/restart workflow rather than changing the process immediately in the browser. Parix records the actor and change context, marks the profile Provisioning while required, and transitions the Changes row through:

• Pending
• In progress
• Completed
• Failed

The successful queue messages are:

• Parameter change queued (cache grid …)
• Replica restart queued to refresh bootstrap configuration

Expected result

After Completed, the database returns to an active/Ready state. A cache change becomes the active provider metadata and the Changes history records the applied override. A bootstrap refresh keeps the same shape and cache value but restarts the replicas with the current bootstrap configuration.

Downtime and operational warnings

Changing the cache grid or refreshing bootstrap requires replica rollout. Do not assume a queue acknowledgment means the new value is already live.

A rolling restart can preserve service only when healthy replicas remain available. A single-node Dedicated database has no alternate replica during its restart and can be temporarily unavailable. Pause or buffer critical writes for that window.

Do not queue a second parameter, topology, storage, CDC, restore, or upgrade action while the profile is Provisioning.

Troubleshooting

Parameter controls are disabled

Confirm that:

• the database is Dedicated or Production, not Developer/shared
• the provider is GCP
• the profile exists and is not Provisioning
• your organization role is owner or administrator
• the selected cluster size supports a cache value above the fixed 512 MiB minimum

The input is rejected

Use the dashboard numeric control. The underlying value must be a positive TigerBeetle cache-grid size such as 512MiB; the current UI constrains it to the displayed MiB range and 128 MiB increments.

The page says there are no changes to queue

The normalized target matches the current value. Case or suffix formatting alone is not a configuration change.

Restart replicas is disabled

The database is not a supported GCP deployment, the profile is missing, or another workflow is currently provisioning it.

The workflow failed

1. Open Changes and capture the failed row and time.
2. Check Logs for replica startup or health errors.
3. Check Metrics for replica state and memory behavior.
4. Do not retry with a larger cache until the profile is stable and the first failure is understood.

See Provisioning and configuration for the combined checklist.

Next steps

• Review Cluster configurations when memory pressure requires a different compute size rather than a cache override.
• Review Storage configurations for capacity changes.
• Use TigerBeetle compatibility before a version upgrade.