6. Design Rationale
6. Design Rationale
← 5. Upgrade Mechanics | Index | Next: 7. Evolution →
6.1 Why This Section Exists
This section documents alternatives considered during the design of the PostgreSQL 18 baseline upgrade and explains why each was rejected. Each alternative is evaluated against the invariants defined in Section 2.3.
6.2 Rejected Alternatives
6.2.1 Remain on PostgreSQL 16
Description: Keep all containerized databases on PostgreSQL 16 and defer the major upgrade.
Why It Was Attractive:
- Avoids immediate operational change and retraining.
- Preserves current extension binaries and configuration without rebuilds.
Why It Was Rejected:
- Fails to establish a forward-looking baseline and prolongs compatibility drift.
- Prevents alignment with PostgreSQL 18 features and support lifecycle.
- Violates Invariant 1 — Baseline Version.
Conclusion: Deferring the upgrade conflicts with the baseline standardization decision and is not acceptable.
6.2.2 Mixed Baseline: PostgreSQL 18 for Metadata, PostgreSQL 16 for Tenant
Description: Upgrade only the metadata database to PostgreSQL 18 while keeping the tenant database on PostgreSQL 16.
Why It Was Attractive:
- Reduces immediate CDC risk by keeping logical decoding on the existing tenant baseline.
- Allows incremental adoption and smaller initial blast radius.
Why It Was Rejected:
- Introduces long-lived baseline drift between metadata and tenant databases.
- Complicates extension parity and pooler validation across heterogeneous versions.
- Violates Invariant 1 — Baseline Version.
- Violates Invariant 6 — Pooler Compatibility.
Conclusion: Mixed baselines violate the architectural requirement for a unified PostgreSQL version and are rejected.
Document Navigation
| Previous | Index | Next |
|---|---|---|
| ← 5. Upgrade Mechanics | Table of Contents | 7. Evolution → |
End of Section 6