docs: remove RDS Blue/Green approach from PG major-version upgrade guide

The Blue/Green approach could not deliver the zero-downtime property the
guide is named for. RDS refuses to create the deployment while a
Materialize source holds a slot on blue, so the only way to start one is
to drop the source -- which cascades the downstream dataflow -- and the
new source must re-snapshot against green regardless. The resulting
staleness window spans provisioning plus a full re-snapshot.

Replace it with a "Why managed Blue/Green deployments don't work"
section that keeps the reproduced constraint and its consequences, so
readers who reach for RDS Blue/Green learn where it blocks.

Also switch the cutover from hand-waved "repoint consumers" to an atomic
ALTER SCHEMA ... SWAP WITH, and carry over the dbt blue/green caveats
about sinks needing a dedicated schema and cluster and active SUBSCRIBEs
breaking at the swap.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: tylerhartwig

doc/user/content/ingest-data/postgres/major-version-upgrade.md

@@ -20,25 +20,26 @@ new instance running the new version, and the replication slot does **not**
 carry over automatically. How you handle the slot determines whether reads stay
 fresh through the upgrade.
 
-This guide covers two approaches:
-
-| Approach | Reads stay fresh? | Who moves the data? | Use when |
-|----------|-------------------|---------------------|----------|
-| [Parallel source (self-managed)](#approach-a-parallel-source-self-managed) | **Yes, continuously** | You (native logical replication) | Zero read downtime is a hard requirement. |
-| [Amazon RDS Blue/Green](#approach-b-amazon-rds-bluegreen-managed) | No — bounded freshness gap | AWS | A brief staleness window is acceptable and you want AWS to manage the cutover. |
+The approach in this guide keeps Materialize continuously fresh. You keep the
+existing source running against the old primary the entire time, build the
+new-version primary in parallel, and hydrate a second source against it before
+cutting consumers over.
 
 {{< note >}}
-Both approaches involve a brief **write** freeze on the application at the
-moment of cutover, which is inherent to any major-version upgrade. The
-difference is whether Materialize keeps serving fresh **reads** throughout.
+This procedure involves a brief **write** freeze on the application at the
+moment of cutover, which is inherent to any major-version upgrade. Materialize
+keeps serving fresh **reads** throughout.
 {{< /note >}}
 
-## Approach A: Parallel source (self-managed)
+{{< warning >}}
+Managed upgrade services that swap the primary out from under Materialize — such
+as [Amazon RDS Blue/Green
+deployments](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)
+— cannot be used while a Materialize source is attached. See [Why managed
+Blue/Green deployments don't work](#why-managed-bluegreen-deployments-dont-work).
+{{< /warning >}}
 
-This is the only approach that keeps Materialize continuously fresh. You keep
-the existing source running against the old primary the entire time, build the
-new-version primary in parallel, and hydrate a second source against it before
-cutting consumers over.
+## Upgrade with a parallel source
 
 ```text
 app writes ──▶ PG (old major) ──native logical replication──▶ PG (new major)
@@ -145,110 +146,86 @@ Once the new source has caught up, perform a coordinated cutover:
 1. **Drain both sources** in Materialize so they reflect the frozen state, then
    verify the fingerprint matches across the old primary, new primary, existing
    source, and new source.
-1. **Repoint consumers** from the existing source's objects to the `upgrade`
-   schema's objects.
-1. **Resume application writes**, now pointed at the new primary.
-
-Throughout the cutover, reads against Materialize stay live and fresh — the
-existing source serves until the flip, and the new source is already caught up
-at the flip.
+1. **Swap the schemas.** Rather than repointing each consumer, swap the
+   production schema with the `upgrade` schema. The swap is atomic, so
+   consumers keep referencing the same schema-qualified names and move together
+   at a single instant:
 
-### 5. Decommission
+    ```mzsql
+    ALTER SCHEMA public SWAP WITH upgrade;
+    ```
 
-Drop the subscription on the new primary, drop the old source in Materialize,
-and decommission the old primary.
+    To roll back, run the same statement again.
 
-## Approach B: Amazon RDS Blue/Green (managed)
+1. **Resume application writes**, now pointed at the new primary.
 
-[Amazon RDS Blue/Green deployments](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)
-let AWS build the upgraded "green" instance, keep it in sync, and swap
-endpoints at switchover. This is operationally simpler, but it **cannot keep
-Materialize continuously fresh** because of the constraint below.
+Throughout the cutover, reads against Materialize stay live and fresh — the
+existing source serves until the swap, and the new source is already caught up
+at the swap.
 
 {{< warning >}}
-**A Blue/Green deployment cannot be created while a Materialize source is
-attached to the blue instance.** Materialize's logical replication slot counts
-as *external replication*, and RDS refuses to create the deployment
-(`CREATING_READ_REPLICA_OF_SOURCE` fails with *"external replication on the blue
-primary instance"*). You must [drop the
-source](/sql/drop-source/) first, which starts an unavoidable **freshness
-gap**. No RDS flag bypasses this.
+If you have [sinks](/sql/create-sink/), create them in a **dedicated schema and
+cluster** that is excluded from the swap. Sinks must not be recreated as part of
+a blue/green cutover; instead, cut them over to the new definition of their
+upstream dependencies after the swap. This mirrors the guidance in [blue/green
+deployments with dbt](/manage/dbt/blue-green-deployments/).
 {{< /warning >}}
 
-### 1. Detach Materialize and create the deployment
-
-1. `DROP SOURCE` in Materialize to release the replication slot. Confirm
-   `pg_replication_slots` no longer lists Materialize's slot. **The freshness
-   gap starts here.**
-1. Create the Blue/Green deployment, targeting the new major version with a
-   parameter group that has `rds.logical_replication = 1`. Wait for the green
-   instance to become **Available** (a major-version upgrade can take tens of
-   minutes; it scales with database size).
-
-The publication and `REPLICA IDENTITY` settings are copied from blue into green.
-
-### 2. Attach Materialize to green
-
-The green instance is a logical replica that is itself a primary
-(`pg_is_in_recovery()` returns `false`), so it can host Materialize's slot.
-Create a source against **green's temporary endpoint** and let it snapshot and
-catch up:
-
-```mzsql
-CREATE SOURCE my_source
-    FROM POSTGRES CONNECTION pg_green (PUBLICATION 'mz_source')
-    FOR ALL TABLES;
-```
-
-**The freshness gap ends when this source has caught up.** As in Approach A,
-snapshot time scales with data volume.
-
-### 3. Switch over and repoint the source
-
-Trigger the Blue/Green switchover. AWS promotes green **in place** — it takes
-over the production endpoint, while the old blue is demoted and renamed. The
-switchover completes in tens of seconds, during which the application has a
-brief write pause.
-
-Because green is promoted in place (same instance, same LSN timeline), its
-replication slot is preserved. Repoint the source's connection at the
-production endpoint so Materialize resumes from the **same slot with no
-re-snapshot**:
-
-```mzsql
-ALTER CONNECTION pg_green SET (HOST = 'PRODUCTION_ENDPOINT') WITH (VALIDATE = true);
-```
-
-After the switchover, green's temporary endpoint is removed; a source restart
-would otherwise fail to resolve it, so run the `ALTER CONNECTION` promptly.
-
 {{< note >}}
-This seamless resume works **only** because a Blue/Green switchover promotes
-green in place, preserving the slot and LSN timeline. Repointing a source at an
-unrelated instance (one that doesn't carry the same slot) forces a fresh
-snapshot instead.
+Any active [`SUBSCRIBE`](/sql/subscribe/) commands attached to the swapped
+cluster(s) will break at the swap. On retry, the client automatically connects
+to the newly deployed cluster.
 {{< /note >}}
 
-### 4. Clean up
+### 5. Decommission
+
+Drop the subscription on the new primary, drop the old source in Materialize,
+and decommission the old primary.
 
-Delete the Blue/Green deployment and the demoted old instance.
+## Why managed Blue/Green deployments don't work
+
+[Amazon RDS Blue/Green deployments](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html)
+let AWS build the upgraded "green" instance, keep it in sync, and swap endpoints
+at switchover. This is an appealing shortcut, but it is **not compatible with an
+attached Materialize source**.
+
+Creating the deployment fails at `CREATING_READ_REPLICA_OF_SOURCE` with *"external
+replication on the blue primary instance"*. One of the documented prerequisites
+is that the DB instance is not the source or target of external replication, and
+Materialize's logical replication slot is external replication. No RDS setting
+bypasses this.
+
+Releasing the slot — by [dropping the source](/sql/drop-source/) — does let the
+deployment be created, but that is not a viable production step:
+
+- `DROP SOURCE` defaults to `RESTRICT` and fails when the source has dependents.
+  Forcing it with `CASCADE` drops the entire downstream dataflow — tables, views,
+  materialized views, indexes, and sinks — which means rebuilding and rehydrating
+  your environment, not a brief pause.
+- Even after the switchover, Materialize's original slot on blue is unusable, so
+  the new source must snapshot from scratch against green.
+
+The result is a staleness window that begins when you detach from blue and lasts
+through provisioning and a full re-snapshot. Use the [parallel
+source](#upgrade-with-a-parallel-source) procedure above instead: it keeps the
+existing source serving fresh for the entire upgrade, and the only coordinated
+pause is the write freeze at cutover.
 
 ## Considerations
 
-- **DDL is not replicated.** For Approach A, pre-create the target schema on the
-  new instance before subscribing.
+- **DDL is not replicated.** Pre-create the target schema on the new instance
+  before subscribing.
 - **Sequences are not advanced on the target** by native logical replication.
-  Synchronize them at cutover (Approach A) or RDS handles it at switchover
-  (Approach B).
+  Synchronize them at cutover.
 - **`REPLICA IDENTITY FULL`** must be set on replicated tables so Materialize
   captures all column values on updates and deletes.
-- **`ALTER CONNECTION ... SET (HOST = ...)`** resumes from the existing slot
-  only when the target instance preserves that slot (an in-place promotion).
-  Otherwise Materialize re-snapshots.
+- **A publication can feed multiple subscribers**, so Materialize's slot and the
+  upgrade subscription's slot coexist on the old primary without conflict.
 
 ## Related pages
 
 - [Ingest data from Amazon RDS](/ingest-data/postgres/amazon-rds/)
 - [Guide: Ingest from a dedicated PostgreSQL replica](/ingest-data/postgres/logical-replica/)
 - [Guide: Handle upstream schema changes with zero downtime](/ingest-data/postgres/source-versioning/)
-- [`ALTER CONNECTION`](/sql/alter-connection/)
+- [Blue/green deployments with dbt](/manage/dbt/blue-green-deployments/)
+- [`ALTER SCHEMA`](/sql/alter-schema/)