Upgrade & Rollback plan: My customer requests rollback via old-version standby (13 ↔ 17) — need community advice

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’d
like to confirm if it’s technically feasible or advisable before
proceeding.

Scenario:
1. They have a **Primary–Standby 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 —
minimizing downtime.
3. They also asked whether it’s possible for **data generated on the
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’t 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) — even temporarily, for rollback
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!

--
Best Regards,

Miles Le | Vu (Mr.)