Skip to content

Commit 01fa86a

Browse files
thild42thild42
committed
Update plan reference in postgresql_09
1 parent f5f9df7 commit 01fa86a

File tree

15 files changed

+135
-135
lines changed

15 files changed

+135
-135
lines changed

‎pages/public_cloud/public_cloud_databases/postgresql_09_concept_high_availability/guide.de-de.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: PostgreSQL - Concepts - High availability and failure scenarios
33
excerpt: Learn the concepts of high-availability for PostgreSQL offers
4-
updated: 2023-03-21
4+
updated: 2025-07-31
55
---
66

77
## Objective
@@ -13,11 +13,11 @@ We then describe multiple failure scenarios and consequences.
1313

1414
Public Cloud Databases for PostgreSQL are available on three service plans, offering different levels of high availability. The selected plan defines the features available. A summary is provided in the table below:
1515

16-
| Service plan | Cluster topology | High Availability Features | Backup retention |
17-
|--------------|------------------------------------------|----------------------------------------|------------------|
18-
| Essential | Single-node | No high availability | 2 days |
19-
| Business | Two nodes: Primary + replica | Higher availability | 14 days |
20-
| Enterprise | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
16+
| Service plan | Cluster topology | High Availability Features | Backup retention |
17+
|---------------------|------------------------------------------|----------------------------------------|------------------|
18+
| Essential | Single-node | No high availability | 2 days |
19+
| Business/Production | Two nodes: Primary + replica | Higher availability | 14 days |
20+
| Enterprise/Advanced | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
2121

2222
## About primary and replica nodes
2323

@@ -65,7 +65,7 @@ The table below summarizes the scenarios detailed in the following paragraphs.
6565
**RPO** is the **Recovery Point Objective**, meaning how far back before the incident you can recover the data.
6666
**RTO** is the **Recovery Time Objective**, meaning how long it takes to go back to a normal situation.
6767

68-
| Scenario | Essential (1 node) | Business (2 nodes) or Enterprise (3 nodes) |
68+
| Scenario | Essential (1 node) | Business/Production (2 nodes) or Enterprise/Advanced (3 nodes) |
6969
|--------------------------------------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
7070
| Primary node failure | **RPO**: approx. 5 minutes or 1 WAL file. **RTO**: multiple hours (time to restore your backup) | **RPO**: Near zero. **RTO**: Approx. 60 seconds then auto failover |
7171
| Replica node failure | N/A | **RP0**: zero, no data loss. **RTO**: zero, no downtime |
@@ -105,9 +105,9 @@ You will then need to configure the newly created service (e.g. adding users, IP
105105

106106
In both cases the Recovery Time Objective will vary, depending on multiple parameters such as the amount of data to restore, network congestion and latency or node performances. It can take from a few hours up to a few days.
107107

108-
### Scenarios for Highly available Business and Enterprise service plans
108+
### Scenarios for Highly available Business/Production and Enterprise/Advanced service plans
109109

110-
The Business plan provides a primary and a replica node, the Enterprise plan starts with a primary and two replica nodes.
110+
The Business/Production plan provides a primary and a replica node, the Enterprise/Advanced plan starts with a primary and two replica nodes.
111111

112112
#### Replica node failure
113113

‎pages/public_cloud/public_cloud_databases/postgresql_09_concept_high_availability/guide.en-asia.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: PostgreSQL - Concepts - High availability and failure scenarios
33
excerpt: Learn the concepts of high-availability for PostgreSQL offers
4-
updated: 2023-03-21
4+
updated: 2025-07-31
55
---
66

77
## Objective
@@ -13,11 +13,11 @@ We then describe multiple failure scenarios and consequences.
1313

1414
Public Cloud Databases for PostgreSQL are available on three service plans, offering different levels of high availability. The selected plan defines the features available. A summary is provided in the table below:
1515

16-
| Service plan | Cluster topology | High Availability Features | Backup retention |
17-
|--------------|------------------------------------------|----------------------------------------|------------------|
18-
| Essential | Single-node | No high availability | 2 days |
19-
| Business | Two nodes: Primary + replica | Higher availability | 14 days |
20-
| Enterprise | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
16+
| Service plan | Cluster topology | High Availability Features | Backup retention |
17+
|---------------------|------------------------------------------|----------------------------------------|------------------|
18+
| Essential | Single-node | No high availability | 2 days |
19+
| Business/Production | Two nodes: Primary + replica | Higher availability | 14 days |
20+
| Enterprise/Advanced | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
2121

2222
## About primary and replica nodes
2323

@@ -65,7 +65,7 @@ The table below summarizes the scenarios detailed in the following paragraphs.
6565
**RPO** is the **Recovery Point Objective**, meaning how far back before the incident you can recover the data.
6666
**RTO** is the **Recovery Time Objective**, meaning how long it takes to go back to a normal situation.
6767

68-
| Scenario | Essential (1 node) | Business (2 nodes) or Enterprise (3 nodes) |
68+
| Scenario | Essential (1 node) | Business/Production (2 nodes) or Enterprise/Advanced (3 nodes) |
6969
|--------------------------------------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
7070
| Primary node failure | **RPO**: approx. 5 minutes or 1 WAL file. **RTO**: multiple hours (time to restore your backup) | **RPO**: Near zero. **RTO**: Approx. 60 seconds then auto failover |
7171
| Replica node failure | N/A | **RP0**: zero, no data loss. **RTO**: zero, no downtime |
@@ -103,9 +103,9 @@ In case of datacenter failure, the recovery strategy involves creating a new ser
103103
You will then need to configure the newly created service (e.g. adding users, IP restrictions, etc.) and reconfigure applications consuming the database service to use new services URIs and credentials.
104104
In both cases the Recovery Time Objective will vary, depending on multiple parameters such as the amount of data to restore, network congestion and latency or node performances. It can take from a few hours up to a few days.
105105

106-
### Scenarios for Highly available Business and Enterprise service plans
106+
### Scenarios for Highly available Business/Production and Enterprise/Advanced service plans
107107

108-
The Business plan provides a primary and a replica node, the Enterprise plan starts with a primary and two replica nodes.
108+
The Business/Production plan provides a primary and a replica node, the Enterprise/Advanced plan starts with a primary and two replica nodes.
109109

110110
#### Replica node failure
111111

‎pages/public_cloud/public_cloud_databases/postgresql_09_concept_high_availability/guide.en-au.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: PostgreSQL - Concepts - High availability and failure scenarios
33
excerpt: Learn the concepts of high-availability for PostgreSQL offers
4-
updated: 2023-03-21
4+
updated: 2025-07-31
55
---
66

77
## Objective
@@ -13,11 +13,11 @@ We then describe multiple failure scenarios and consequences.
1313

1414
Public Cloud Databases for PostgreSQL are available on three service plans, offering different levels of high availability. The selected plan defines the features available. A summary is provided in the table below:
1515

16-
| Service plan | Cluster topology | High Availability Features | Backup retention |
17-
|--------------|------------------------------------------|----------------------------------------|------------------|
18-
| Essential | Single-node | No high availability | 2 days |
19-
| Business | Two nodes: Primary + replica | Higher availability | 14 days |
20-
| Enterprise | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
16+
| Service plan | Cluster topology | High Availability Features | Backup retention |
17+
|---------------------|------------------------------------------|----------------------------------------|------------------|
18+
| Essential | Single-node | No high availability | 2 days |
19+
| Business/Production | Two nodes: Primary + replica | Higher availability | 14 days |
20+
| Enterprise/Advanced | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
2121

2222
## About primary and replica nodes
2323

@@ -65,7 +65,7 @@ The table below summarizes the scenarios detailed in the following paragraphs.
6565
**RPO** is the **Recovery Point Objective**, meaning how far back before the incident you can recover the data.
6666
**RTO** is the **Recovery Time Objective**, meaning how long it takes to go back to a normal situation.
6767

68-
| Scenario | Essential (1 node) | Business (2 nodes) or Enterprise (3 nodes) |
68+
| Scenario | Essential (1 node) | Business/Production (2 nodes) or Enterprise/Advanced (3 nodes) |
6969
|--------------------------------------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
7070
| Primary node failure | **RPO**: approx. 5 minutes or 1 WAL file. **RTO**: multiple hours (time to restore your backup) | **RPO**: Near zero. **RTO**: Approx. 60 seconds then auto failover |
7171
| Replica node failure | N/A | **RP0**: zero, no data loss. **RTO**: zero, no downtime |
@@ -103,9 +103,9 @@ In case of datacenter failure, the recovery strategy involves creating a new ser
103103
You will then need to configure the newly created service (e.g. adding users, IP restrictions, etc.) and reconfigure applications consuming the database service to use new services URIs and credentials.
104104
In both cases the Recovery Time Objective will vary, depending on multiple parameters such as the amount of data to restore, network congestion and latency or node performances. It can take from a few hours up to a few days.
105105

106-
### Scenarios for Highly available Business and Enterprise service plans
106+
### Scenarios for Highly available Business/Production and Enterprise/Advanced service plans
107107

108-
The Business plan provides a primary and a replica node, the Enterprise plan starts with a primary and two replica nodes.
108+
The Business/Production plan provides a primary and a replica node, the Enterprise/Advanced plan starts with a primary and two replica nodes.
109109

110110
#### Replica node failure
111111

‎pages/public_cloud/public_cloud_databases/postgresql_09_concept_high_availability/guide.en-ca.md

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
title: PostgreSQL - Concepts - High availability and failure scenarios
33
excerpt: Learn the concepts of high-availability for PostgreSQL offers
4-
updated: 2023-03-21
4+
updated: 2025-07-31
55
---
66

77
## Objective
@@ -13,11 +13,11 @@ We then describe multiple failure scenarios and consequences.
1313

1414
Public Cloud Databases for PostgreSQL are available on three service plans, offering different levels of high availability. The selected plan defines the features available. A summary is provided in the table below:
1515

16-
| Service plan | Cluster topology | High Availability Features | Backup retention |
17-
|--------------|------------------------------------------|----------------------------------------|------------------|
18-
| Essential | Single-node | No high availability | 2 days |
19-
| Business | Two nodes: Primary + replica | Higher availability | 14 days |
20-
| Enterprise | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
16+
| Service plan | Cluster topology | High Availability Features | Backup retention |
17+
|---------------------|------------------------------------------|----------------------------------------|------------------|
18+
| Essential | Single-node | No high availability | 2 days |
19+
| Business/Production | Two nodes: Primary + replica | Higher availability | 14 days |
20+
| Enterprise/Advanced | Three nodes: One primary + two replicas | Best high availability characteristics | 30 days |
2121

2222
## About primary and replica nodes
2323

@@ -65,7 +65,7 @@ The table below summarizes the scenarios detailed in the following paragraphs.
6565
**RPO** is the **Recovery Point Objective**, meaning how far back before the incident you can recover the data.
6666
**RTO** is the **Recovery Time Objective**, meaning how long it takes to go back to a normal situation.
6767

68-
| Scenario | Essential (1 node) | Business (2 nodes) or Enterprise (3 nodes) |
68+
| Scenario | Essential (1 node) | Business/Production (2 nodes) or Enterprise/Advanced (3 nodes) |
6969
|--------------------------------------------|----------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
7070
| Primary node failure | **RPO**: approx. 5 minutes or 1 WAL file. **RTO**: multiple hours (time to restore your backup) | **RPO**: Near zero. **RTO**: Approx. 60 seconds then auto failover |
7171
| Replica node failure | N/A | **RP0**: zero, no data loss. **RTO**: zero, no downtime |
@@ -103,9 +103,9 @@ In case of datacenter failure, the recovery strategy involves creating a new ser
103103
You will then need to configure the newly created service (e.g. adding users, IP restrictions, etc.) and reconfigure applications consuming the database service to use new services URIs and credentials.
104104
In both cases the Recovery Time Objective will vary, depending on multiple parameters such as the amount of data to restore, network congestion and latency or node performances. It can take from a few hours up to a few days.
105105

106-
### Scenarios for Highly available Business and Enterprise service plans
106+
### Scenarios for Highly available Business/Production and Enterprise/Advanced service plans
107107

108-
The Business plan provides a primary and a replica node, the Enterprise plan starts with a primary and two replica nodes.
108+
The Business/Production plan provides a primary and a replica node, the Enterprise/Advanced plan starts with a primary and two replica nodes.
109109

110110
#### Replica node failure
111111

0 commit comments

Comments
 (0)