MIME-Version: 1.0
From: "Vu Le (JData - HN)" <dba4@jprotech.com.vn>
Date: Fri, 10 Oct 2025 15:26:28 +0700
Message-ID: <CACT9sogdbwVqsXQeT-V8GP+GhhQrQcwmCPOCTtaPL35jHg5UXQ@mail.gmail.com>
Subject: =?UTF-8?Q?Upgrade_=26_Rollback_plan=3A_My_customer_requests_rollba?=
	=?UTF-8?Q?ck_via_old=2Dversion_standby_=2813_=E2=86=94_17=29_=E2=80=94_need_community_ad?=
	=?UTF-8?Q?vice?=
To: pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CACT9sogdbwVqsXQeT-V8GP%2BGhhQrQcwmCPOCTtaPL35jHg5UXQ%40mail.gmail.com>
Precedence: bulk

Hi all,

I'm currently planning a major version upgrade from PostgreSQL 13.x to
17.x in a production environment.

My customer has requested the following rollback approach, and I=E2=80=99d
like to confirm if it=E2=80=99s technically feasible or advisable before
proceeding.

Scenario:
1. They have a **Primary=E2=80=93Standby setup** (streaming replication).
2. Their idea is to **upgrade only the Primary** (to v17) first, while
keeping the **Standby** on v13 (the old version).
   - The upgraded Primary will run read/write traffic for about a week
to validate stability.
   - If any serious issue occurs, the plan is to **switch over**
(promote the v13 Standby), adjust IPs, and resume operations there =E2=80=
=94
minimizing downtime.
3. They also asked whether it=E2=80=99s possible for **data generated on th=
e
v17 Primary** to still be **replicated back to the v13 Standby**, so
that rollback would be fast and without data loss.

Constraints:
- They **cannot use a Blue/Green or clone-based approach**, because of
**limited storage resources**.
- They also doesn=E2=80=99t want the old data directory to become outdated
(they expects it could stay in sync with the upgraded node).
- They only have **UAT and Production environments** (no dedicated Staging)=
.

Questions:
1. Is there **any supported or practical method** to replicate data
*backward* (from PostgreSQL 17 to 13) =E2=80=94 even temporarily, for rollb=
ack
purposes?
2. If not, what are the **recommended real-world rollback strategies**
for a low-downtime upgrade under these constraints?
3. Are there open-source tools or logical replication setups (e.g.,
pglogical, Bucardo, etc.) that could safely achieve something similar?

Any insight, best practice, or reference architecture from the
community would be very helpful.
Thank you for your time and guidance. Have a good day!

--=20
Best Regards,

Miles Le | Vu (Mr.)