Storage configurations

Use Cluster → Storage to review or change the storage type and capacity per node of a dedicated database.

Availability by plan

Storage settings affect both the provider shape and the effective monthly profile price.

Before you begin

You need:

• an organization owner or administrator role to queue a change
• a Dedicated or Production database with an active profile
• no other workflow holding the profile in Provisioning
• enough time for a fresh backup, replacement provisioning, restore, and controlled cutover when the page offers a GCP migration
• an application maintenance plan for the cutover window

Read Cluster configurations first if you also need to change node count or compute size. Queue one coherent change and wait for it to complete before starting another.

Open Storage configuration

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

The current provider, region, cluster size, and node count determine which storage options appear. The live create catalog is authoritative.

Understand the controls

1. Type

Each storage-type tile shows:

• the customer-facing provider storage label
• a short description when the catalog supplies one
• the base monthly amount used in the profile estimate
• any provider- or topology-specific warning

Only types compatible with the existing provider, region, node count, and cluster size are listed. If the page reports that no storage types are available, do not submit a guessed storage identifier.

2. Size

Capacity is measured in gigabytes per node.

• Storage backends with fixed capacities show selectable size tiles. Select one of the values displayed.
• Flexible durable storage shows a slider and numeric Size field from 10 GB through 4096 GB, in 1 GB increments.
• The comparison panel shows Current disk size, New disk size, Current storage add-on, and New storage add-on.

Some types have additional rules:

• Local NVMe uses provider-defined fixed capacities and cannot be resized after creation in the current product version.
• GCP Hyperdisk Premium uses fixed capacity and included performance profiles; IOPS and throughput are not separately configurable in this form.

The hidden catalog identifiers are submitted with your visible selection. Customer procedures should use the labels and sizes shown in the dashboard, not internal IDs copied from another environment.

Queue a supported storage change

1. In Type, select a compatible storage backend.
2. In Size, choose a displayed fixed capacity or enter a flexible capacity.
3. Compare the current and new disk size.
4. Review the storage add-on price change.
5. Confirm that the provider warning permits the requested mutation.
6. For a supported GCP durable-storage increase, select Queue backup-driven migration.
7. Open Changes and wait for the row to reach Completed.

If type and effective capacity match the active profile, Parix reports No storage changes to queue and does not create a workflow.

Workflow and status behavior

A supported GCP storage change is not an in-place disk edit. Parix:

1. validates the catalog selection and confirms that capacity does not shrink
2. records a durable storage-change context
3. queues a backup-driven migration
4. creates a fresh backup
5. provisions the target shape with the requested storage
6. restores the migration backup
7. cuts over during controlled downtime
8. persists the converged profile and allocation history

The Changes tab reports Pending, In progress, Completed, or Failed with actor and timestamps. The active allocation history remains the source of truth for effective storage used by billing.

Expected result

The page first reports Backup-driven migration queued (type · capacity). Completion is not confirmed until Changes reaches Completed, the database returns to Ready, and the dashboard shows the new storage capacity and price.

Provider and plan limitations

• GCP durable storage can grow but cannot shrink. Provision a new target database when you need a smaller disk.
• Every currently supported GCP storage mutation uses backup-driven migration and downtime.
• A backend migration to or from Local NVMe or GCP Hyperdisk is blocked in the current product version. Provision a new target database instead.
• Post-create storage changes are blocked for both GCP and AWS Local NVMe deployments.
• AWS storage changes are currently blocked until the AWS backup-driven migration path is available. This includes AWS EBS capacity changes from this tab.
• AWS provider support may be absent from the live production create catalog even though implemented paths support existing or non-production AWS-backed deployments.
• Shared Developer databases have no per-project storage control.

Downtime, cost, and data-safety warnings

A queued GCP storage migration makes the database unavailable during cutover. Stop or buffer writes according to your maintenance plan. Do not rely on an application retry loop alone to define a safe write boundary.

The migration creates a fresh backup for the move, but you should still verify that your normal backup and recovery policy is healthy before the change. Do not delete the database or modify cluster topology, parameters, CDC, or TigerBeetle version while the migration is active.

The displayed monthly price is the effective profile estimate for the selection. Treat it as a material billing change and obtain approval before queueing.

Troubleshooting

Storage is missing from navigation

The database is on a Developer/shared plan. Storage is managed at the shared-cell level and is not available as a tenant control.

The queue button is disabled

Check whether:

• the selection differs from the current type or capacity
• the profile is already Provisioning
• the new capacity is below the current GCP capacity
• the database uses AWS
• the database uses Local NVMe
• the selection crosses into or out of Local NVMe or GCP Hyperdisk
• your organization role is owner or administrator

The size field moves back to another value

The route normalizes flexible sizes to 10–4096 GB. Fixed-capacity backends accept only the size tiles supplied by the catalog.

No storage types are available

The live catalog has no type compatible with the current provider, region, topology, and cluster size. Preserve the current profile and contact support rather than trying an identifier from another database.

The change failed after queueing

1. Open Changes and capture the failed row.
2. Check Logs around its start and end times.
3. Verify the database status and whether the migration backup completed.
4. Do not queue another migration until the profile leaves Provisioning or Error and the failed workflow is understood.

See Provisioning and configuration for the combined checklist.

Next steps

• Return to Cluster configurations for topology or compute sizing.
• Review Backup and restore before the maintenance window.
• Use Metrics after completion to verify disk utilization and replica state.