Replicas

Parix models scale through cluster topology and provider replica metadata.

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