Replicas

Parix models scale through cluster topology and provider replica metadata.

Use this page as an explanation of replica behavior. To change topology from the dashboard, use Cluster configurations.

Replica model

Provider metadata tracks replica-specific details such as:

• replica index
• machine or instance identity
• runtime state
• volume or disk identity
• private or internal addresses

This is how the control plane reconstructs topology-aware views for metrics, logs, and cluster details.

How scale changes happen

Replica count is not edited independently from the rest of cluster shape. Instead, operators select a new cluster configuration in the Instances tab and the control plane resolves:

• target node count
• target size variant
• implied monthly profile cost

The upgrade workflow then chooses whether the rollout is:

• rolling in place
• backup-driven migration on GCP when topology changes require a new replica set
• blocked on AWS for topology changes until restore-backed migration exists

Operational consequences

• replica-aware views depend on durable provider metadata being current
• topology changes are visible only after workflow convergence into durable state
• GCP topology changes preserve data by restoring a fresh backup into the target shape, but the database is unavailable during cutover
• allocation history is still the billing-facing history of effective cluster shape

Current product limits

Scaling behavior should be understood within current product scope:

• no cross-region replication
• no multi-region HA
• no dedicated public replica-management API