判斷：適合已盤點擴充套件、確認目標環境有相容檔案與更新路徑，並完成隔離環境應用驗證的團隊安排升級；不適合只因截止日期將近，就把未演練的升級直接推上生產。 PostgreSQL 官方資料列明，PostgreSQL 14 預計於 2026 年 11 月 12 日停止支援；發布前仍應再次核對官方版本支援政策。
這篇文章寫給維護 PostgreSQL 14 自建執行個體、需要盤點擴充套件的 DBA。
如果你負責後端程式，重點是確認應用實際呼叫的擴充功能是否可用。
如果你是 SaaS 技術負責人，請用下列檢查結果判斷是否有足夠時間演練與安排切換。
最後更新於 2026 年 10 月 28 日；停止支援日期核實自 PostgreSQL 官方版本支援政策及PostgreSQL 14.24 發布公告。
PostgreSQL 14 擴充套件相容性檢查：先分清「已安裝」與「可用」
擴充套件盤點要從每個資料庫分別開始嗎？ 要。pg_extension 列出目前資料庫已安裝的擴充套件；pg_available_extensions 則呈現伺服器環境可用的擴充套件及版本資訊。兩者回答的是不同問題，官方分別說明了已安裝擴充套件的系統目錄與可用擴充套件檢視表。
連線至每個資料庫後，先執行：
SELECT e.extname, e.extversion, n.nspname AS schema_name
FROM pg_extension AS e
JOIN pg_namespace AS n ON n.oid = e.extnamespace
ORDER BY e.extname;
再查伺服器目前提供的擴充套件：
SELECT name, default_version, installed_version
FROM pg_available_extensions
ORDER BY name;
第一個查詢顯示該資料庫已安裝的名稱、版本與結構描述；第二個查詢提供目前環境可用的項目，以及已安裝版本（若有）。請將結果保存為遷移紀錄，不要把「目前可用」誤當成「目標環境也有」。
這兩份清單都不是完整的應用依賴清單。還要檢查部署與資料庫遷移程式、資料庫物件、應用程式碼及設定檔，找出擴充套件提供的函式、型別、索引或載入設定是否被引用。擴充套件機制與安裝方式可參考官方擴充套件文件。
目標環境缺檔案，與只差一次版本更新，不是同一種問題
PostgreSQL 擴充套件在新版本裡還能用嗎？ 不能只憑擴充套件名稱判斷。目標伺服器必須提供與目標 PostgreSQL 主版本相符的擴充套件檔案，而且擴充套件自身必須有可行的版本更新路徑。即使名稱相同，也不代表可以直接載入或升級。
請逐項確認：
- 目標環境是否安裝了該擴充套件，以及檔案是否與目標 PostgreSQL 版本相符。
- 目標環境提供的擴充套件版本，能否從目前已安裝版本更新；是否要求先經過中間版本。
- 相關函式、資料型別、運算子類別、索引或載入設定是否仍符合應用程式依賴。
- 擴充套件由何處安裝與管理；不要假設作業系統套件、原始碼建置或自訂檔案在不同環境中有相同版本與設定。
整理成一份逐項核對紀錄，至少包含目前名稱與版本、目標環境提供情況、預計更新路徑、依賴物件及測試結果。未能確認的項目標記為阻塞，不要用「應該相容」代替驗證。
依問題類型定位升級檢查的阻塞點
pg_upgrade 如何協助檢查擴充套件？ 它可在正式升級前執行檢查模式，並依官方文件要求確認新舊環境與擴充套件檔案等條件；但檢查通過不等於應用功能已驗證。pg_upgrade 官方文件亦說明，擴充套件的共用物件檔案必須在新環境中具備，相關更新步驟仍須依個別擴充套件處理。
可先在隔離環境以實際安裝路徑執行檢查，以下為參數形式示意：
pg_upgrade --check \
-b /path/to/old/bin -B /path/to/new/bin \
-d /path/to/old/data -D /path/to/new/data
請依你的安裝方式替換路徑，並保存完整輸出與資料庫日誌，再按問題分類處理：
- 缺少檔案或程式庫：核對目標伺服器是否安裝該擴充套件，以及套件來源和檔案路徑是否正確。
- 沒有更新路徑：查閱擴充套件本身的更新說明；確認是否須先更新到中間版本，或改用已驗證的替代方案。
- 物件或應用依賴：檢查擴充套件提供的型別、函式、索引及應用呼叫。移除或清理前先在測試環境確認影響，不能只為了讓檢查通過就刪除物件。
- 檢查工具通過但功能失敗：轉向應用程式、連線程式、ORM、遷移指令碼或備份還原工具的整合測試。
五步完成隔離驗證，再判斷是否能切換
升級 PostgreSQL 後，擴充套件要不要單獨更新？ 視擴充套件及目標版本而定。不要預設會自動更新；依目標環境提供的版本、擴充套件更新路徑與官方指示，逐項決定是否需要更新，並以測試結果確認。
- 複製檢查基線：記錄各資料庫的已安裝清單、版本、相關設定及應用依賴；把目標 PostgreSQL 版本和擴充套件來源一併記下。
- 準備隔離環境：使用與預定生產環境相符的 PostgreSQL 版本及擴充套件檔案，避免只在不同版本或不同安裝來源的測試機驗證。
- 執行預檢與更新演練：先跑
pg_upgrade --check，再按擴充套件文件執行必要更新；保留指令、輸出、錯誤訊息與修正方式。 - 測試應用實際使用的功能：覆蓋關鍵查詢、函式呼叫、索引行為及依賴物件，也要測連線程式、ORM、資料庫遷移與備份還原流程。只確認「能安裝」不足以證明業務功能正常。
- 演練復原與回退：在隔離環境確認備份可還原，寫清切換條件、失敗時的回復步驟及責任人；升級資料目錄後，不要假定可以把舊程式直接指回新資料目錄。
測試紀錄應寫明所用版本、操作步驟、預期與實際結果、失敗現象及回退方法。這篇文章不提供擴充套件的通用相容保證；若缺少實測，應寫成待驗證項目，而不是宣稱升級成功或效能提升。
以驗證結果決定是否進入生產
請用以下條件作為決策分支，而不是用日曆日期代替技術驗收：
- 若每個已安裝擴充套件都已在目標環境找到相符檔案、確認更新路徑，且應用測試與備份還原演練通過：安排切換，並保留檢查紀錄及回退方案。
- 若擴充套件檔案存在，但更新路徑或依賴行為仍不明：回到隔離環境重現；在結論完成前，不要切換生產。
- 若目標環境缺少擴充套件，或關鍵功能測試失敗：先解決安裝來源、更新路徑或替代方案，再重新驗證。
- 若停止支援前仍無法完成驗證：不要把未演練的升級推上生產；先制定風險控制與後續遷移計畫，並核對官方支援資訊。PostgreSQL 官方列出的停止支援安排可查閱版本支援政策。
備份與回復必須獨立規劃。PostgreSQL 官方提供多種備份與還原方法，你需要依實際使用的備份工具驗證還原結果，並把備份放在資料庫伺服器以外的位置。伺服器使用獨立硬碟或獨享硬體，並不等於資料自動具備冗餘；沒有硬體 RAID 時，應自行規劃軟體 RAID 或複製，且不能以 RAID 取代機外備份。
選定自建目標環境時，也要把記憶體、硬碟配置、作業系統與接入方式納入檢查，而非只看 CPU 型號。可先參考資料庫伺服器記憶體與硬碟規劃，並確認團隊熟悉所用的SSH 接入方式。這些資源核對無法取代擴充套件與應用測試，也不應被當成資料庫代維運或遷移服務的承諾。
若你目前使用共享 VPS 或雲端資料庫，請把共享運算資源、按規格計費的儲存 I/O，以及資料與日誌配置受限等因素，與自行維護擴充套件、備份和升級的工作量一起比較；這些差異會依方案和工作負載而變，並非每個託管方案都相同。若你需要可自行控制資料庫環境、並希望避免共享主機的資源競爭，OSFP Cloud 的 AMD 獨立伺服器可納入比較；但擴充套件安裝、升級驗證與機外備份仍需由你規劃。正式切換前，先完成擴充套件測試與還原演練，再依實際工作負載核對OSFP Cloud 伺服器方案。