距離 PostgreSQL 14 終止支援僅剩兩個月：比起升級，請先演練復原

有些團隊排定了升級資料庫版本的時程，卻不知道升級失敗時回滾需要多少時間。如果您正在維運 PostgreSQL 14，現在需要的產出並不是一個新版本名稱，而是一份可復原的移轉計畫。截至 2026 年 9 月 14 日，距離官方終止支援日期大約只剩兩個月。

已確認的事實：社群支援與代管合約並不相同

PostgreSQL 官方版本政策為主要版本提供 5 年支援，並公告 14 的最終發布日期為 2026 年 11 月 12 日。這是社群支援的時程。受管服務的升級維護時段、額外延伸支援與費用，必須另行查閱該服務商的文件與合約。

同時也必須區分同一個主要版本的小幅更新與主要版本升級。套用 14 的最新修正版本並不能取代升級至 15 或更高版本的工作。相反地，僅因為已有主要版本移轉計畫，就不斷推遲目前版本必要的修正套用，也是不恰當的作法。

從這裡開始是實務維運建議，而非官方支援政策本身。首先，請在一張表上列出各服務的 DB 版本、擴充模組及其版本、連線驅動程式、批次作業、備份保存位置以及複寫架構。選擇目標版本時，切勿僅因最新就貿然決定，務必同時確認實際代管環境與擴充模組的支援範圍。

僅憑資料庫規模小就假設升級速度會很快，這種想法是不夠周延的。如果用於登入後首次查詢、更新付款狀態等業務關鍵路徑的擴充功能或查詢語法產生變化，即使資料複製時間極短，移轉仍可能失敗。找出無人負責的相依性，正是這份清單的目的。

在隔離環境中還原近期的備份，並執行應用程式具代表性的讀取與寫入流程。在這項演練中，必須先確認連線目標，以避免將寫入操作傳送至正式環境 DB。包含實際資料的還原複本，應在原有的存取控制範圍內進行處理。

將備份開始時間、還原完成時間與驗證完成時間分開記錄，才不會混淆擷取檔案的時間與服務能夠重新進行寫入的時間。與其只用刻意縮小、速度較快的小樣本草草通過，不如使用接近正式環境大小的還原複本測量時間，並記錄成本與儲存空間的限制。

官方 pg_upgrade 文件說明可以使用 --check 在實際升級前執行相容性檢查。然而，外部模組的相容性必須另行檢視，且還需要適用於新伺服器的共用函式庫。切勿將檢查指令的成功單純解讀為應用程式的查詢與效能皆已通過驗證。

特別是 --link 模式具有一項限制：啟動新叢集後，舊叢集將無法直接沿用。如果只著眼於速度而選擇該方式，原先預期的回滾途徑可能會失效。務必以與實際切換相同的條件進行演練，並明確指出在何種時機點需要啟動基於還原的回滾機制。

請預先寫下成功標準，避免在切換當天臨時協商。例如，可以將核心 API 讀寫正常完成、批次作業在無重複處理的情況下重啟、主要資料表的業務統計數據一致、複寫狀態確認等指標落實到負責人。這並非強制所有服務套用同一套標準值的範例。

在新 DB 開始寫入後，若需回滾至先前的備份，這段期間產生的異動該如何保存也會成為問題。切勿將單純開啟舊伺服器的程序，與在無資料遺失情況下回滾的程序混為一談。可容許的資料遺失量與停機範圍，必須由服務負責人共同達成共識。

若難以一次遷移所有 DB，請先挑選相依性最少的一項服務，測量其還原、驗證及回滾時間，並將結果作為其他服務規劃的參考依據。將負責人、預定切換日期以及驗證失敗時的中止標準整合至同一份文件中，就能讓原本只有時程表的專案轉變為切實可行的任務。

對於「眼下產品開發更為急迫」的反對意見是可以理解的。然而，若直到最後期限前仍不清楚復原方法，可供選擇的檢查時間將會被壓縮。本文並非主張特定版本的效能提升，亦非代表整個社群的意見，而是將焦點放在因應移轉失敗的準備上，重視穩健度勝過導入新功能的速度的維運建議。