Scalingo for PostgreSQL® is available across several service classes. Each service class corresponds to a defined availability level and a specific set of features.

High Availability Setups

High availability, clustering, and SLAs are defined by the service class and do not depend on the architecture model.

The architecture model mainly affects how node–gateway pairs are placed. With Dedicated Resources, they are spread across up to three availability zones (AZs).

Single-node plans

Starter plans are running on a single node, without any redundancy or high availability mechanism. Consequently, we don’t consider them to be highly available. This translates into a lower Service Level Agreement.

Highly Available plans

Business and Enterprise plans are designed for higher service continuity, including during maintenance and platform incidents.

The following schema describes the cluster we setup and maintain for each Business plan with two gateways and two database nodes:

Business Plans

Business plans include a fully-managed cluster made of:

• Two (2) PostgreSQL® instances: one primary and one replica, ensuring near real-time replication between the two.
• Two (2) HAProxy® (one active and one standby) as entrypoint to your cluster.

Enterprise Plans

They include a fully-managed cluster made of:

• Three (3) PostgreSQL® instances: one primary and two replicas, ensuring near real-time replication between the three.
• Three (3) HAProxy® (one active and two standby) as entrypoint to the cluster.

Primary and standby nodes

Business and Enterprise plans include one primary node and one or more standby nodes. Standby nodes improve service continuity by:

• Maintaining an up-to-date secondary copy of the data.
• Reducing the potential data loss window in disaster scenarios.
• Enabling faster recovery through controlled failover, since standby nodes are already running and synchronised.
• Offloading backups, when supported, to reduce load on the primary node.¹