最近在看 PostgreSQL 17 的一些東西，嗯... 感覺這次改版蠻多細節的。不是那種大張旗鼓的新架構，反而比較像把很多原本有點卡的地方，默默地修順了。🧐
以前大家總覺得資料庫要快，安全性就得稍微妥協一點；要安全，效能可能就得犧牲。PG17 好像試圖在說，這兩件事不一定那麼衝突。當然，是不是真的完全沒衝突... 這點可以聊聊。
TL;DR
一句話講完：PG17 在你每天都會用到的地方，像是刪資料後的空間回收 (Vacuum)、大量寫入 (WAL) 這些，變得比以前快非常多，而且記憶體吃得更少。同時，它還給了一些更龜毛... 啊不是，更細緻的安全設定，讓 DBA 睡得比較安穩一點。我覺得這次升級蠻有感的。
直接看證據：跟 PG16 差在哪？
講再多都沒用，直接看數字最快。我自己是覺得，如果只是聽別人說「變快了」，實在很難想像。所以這邊整理一下，把幾個重點功能的數據擺在一起看，體感會比較強烈。
下面這個表，不是那種很嚴謹的 benchmark，比較像是我消化完各方資料後，覺得「最有感」的幾個點。大概是這種感覺... 👇
| 功能 | 以前 (大概是 PG16 的狀況) | 現在 (PG17 的新表現) | 我的碎碎念 🤔 |
|---|---|---|---|
| 空間回收 (Vacuum) | 很吃記憶體，跑起來心驚膽顫。特別是交易量大的時候，根本是惡夢。 | 聽說記憶體用量少了 20 倍... 沒錯，20 倍。跑起來也快了 3 倍左右。 | 這點超實用。等於是半夜被叫起來救資料庫的機率降低了。DBA 的福音。 |
| 大量寫入 (High Concurrency Writes) | 人一多、寫入一多，WAL 就容易塞車，吞吐量上不去。 | 吞吐量直接翻倍。官方數據說從 12,500 拉到快 25,000 inserts/sec。 | 做電商搶購、IoT 收數據的應該會超愛。以前要用很貴的硬體去扛，現在軟體層就優化了。 |
| 安全性檢查 (RLS) | 很好用，但開下去查詢效能會掉個 15-20%。有時候為了安全，只能忍。 | 效能損耗降低到 8-12%。等於是 RLS 的「稅」變便宜了。 | 這讓 RLS 從「非不得已才開」變成「可以考慮預設開啟」的選項，對資安架構影響蠻大的。 |
| 處理 JSONB 裡的特殊字元 | 普通。沒特別感覺，反正就是能用。 | 快了 4 倍... 這個數字有點誇張。需要 CPU 支援 AVX-512。 | 如果你的服務存很多使用者輸入的文本，那這個加速會很有感。不過前提是你的 CPU 要夠新。 |
所以... 它是怎麼做到的？
數字很漂亮，但背後的原理更有趣。我自己是覺得，了解「為什麼」會變快，比單純知道「變多快」還重要。這樣你才知道自己的應用程式到底吃不吃得到這些紅利。
先說最重要的：Vacuum 終於不卡了
這個應該是 PG 老玩家最有感的。以前 PostgreSQL 的 `VACUUM` 程序，簡單講就是來收垃圾的，把標記為「已刪除」但空間還沒釋放的資料清掉。問題是，這個清潔工超級耗資源，特別是記憶體。
PG17 改了一個叫做 TID store 的內部機制，收垃圾的方式變聰明了。以前是地毯式搜索，現在比較像是有個清單，直接去指定地點收。結果就是... 記憶體用量少了超級多，速度也快了。
這不只是省資源而已，它會帶來連鎖反應。Vacuum 跑得快，代表 autovacuum (自動清潔) 可以設定得更頻繁、更沒壓力。資料庫的健康狀況會維持在一個比較好的水平。
再來是寫入效能：WAL 處理的優化
WAL (Write-Ahead Log) 是 PostgreSQL 保證資料不遺失的核心機制。所有寫入都要先記一筆帳 (log)，才能真的寫進資料檔。在高併發寫入的場景，例如秒殺活動，大家都在寫這本帳，就很容易變成效能瓶頸。
PG17 優化了 WAL 的處理流程，特別是在 WAL 記錄被壓縮（例如用 zstd）的時候。簡單說，就是記帳的流程變得更順、更平行化，減少了大家排隊等著寫帳的時間。結果就是，整體的寫入吞吐量可以拉高很多。
如果你在 `postgresql.conf` 裡面有做些調整，例如打開 WAL 壓縮，那升級到 PG17 應該會看到明顯的改善。
-- 類似這樣的設定，在 PG17 上效果會更顯著
ALTER SYSTEM SET wal_compression = 'zstd';
ALTER SYSTEM SET max_wal_size = '4GB';
ALTER SYSTEM SET checkpoint_completion_target = 0.9;
-- 改完記得要 reload
SELECT pg_reload_conf();還有一些... 硬核玩家會愛的加速
有個東西叫 AVX-512，是一種 CPU 指令集，可以讓 CPU 一次處理更多資料。如果你的伺服器 CPU 夠新（像是 Intel Skylake-X 或 AMD Zen 4 之後的），那 PG17 就會自動用上它來加速某些運算。
哪裡用得到？
- `bit_count()` 函式：算一個數字裡面有多少個位元是 1。聽起來很宅，但在做一些特徵比對、狀態標記的時候蠻好用的。這東西快了將近 50%。
- JSON 處理：當你的 JSON 裡面有一大堆需要跳脫的特殊字元（像是雙引號、反斜線），PG17 在處理這些字串時，速度可以快到 4 倍。這就超實用了，因為現在很多應用都直接把 log 或半結構化資料塞進 JSONB。
安全設定也變龜毛了... 我是說，更細緻了
效能很棒，但這次 PG17 在安全性上的更新也值得一提。我覺得它體現了一個趨勢：把安全設定的「預設值」拉高，並且提供更多「關後門」的選項。
例如，連線時的 TLS 加密交握，現在多了一個 `sslnegotiation=direct` 參數。這可以避免一些中間人攻擊的手法，強迫連線一開始就必須走加密通道。在台灣，很多金融或政府專案，都有類似的資安要求，這點就跟金管會或是一些國際標準如 NIST 的建議比較貼近。以前可能要自己想辦法繞過去，現在官方直接內建了。
還有 `pg_hba.conf` 的設定，現在可以更明確地強制所有遠端連線都必須使用 `scram-sha-256` 這種比較安全的密碼驗證方式，甚至可以直接拒絕掉舊的 `password` 驗證。對於有合規要求的公司來說，這省了很多事。
情境應用：誰最該升級？
說了這麼多，那到底誰最需要這次升級？
我覺得有幾種場景：
- 高交易量、高寫入的服務：像是電商平台、遊戲後台、IoT 數據收集。光是 WAL 和 Vacuum 的優化，就可能讓你省下不少硬體成本，或是撐過下一次的促銷活動。
- 對資安合規有嚴格要求的產業：金融、醫療、政府。PG17 提供的各種細緻安全設定，能讓你的稽核報告更好寫。特別是 RLS 效能提升，讓你在導入列級安全性時，不用再那麼擔心拖慢系統。
- 大量使用 JSONB 的現代應用：如果你是一個 Heavily API-driven 的服務，後端存了一堆 JSONB，那 AVX-512 帶來的加速（如果你的硬體支援的話）會非常可觀。
不過呢，反過來說，如果你的系統是一個內部用的小工具，每天交易量不大，資料也不太變動... 那升級的急迫性可能就沒那麼高。當然，從長期維護來看，跟上版本還是比較好的。
常見錯誤與修正 (升級前先看看)
每次大版本升級，最怕的不是新功能不會用，而是舊的東西莫名其妙壞掉。這裏提幾個我認為大家在規劃升級 PG17 時，要特別注意的「坑」。
- CPU 不支援 AVX-512：看到 JSON 加速 4 倍很興奮？先確認一下你的伺服器 CPU。如果是在雲端，例如 AWS 或 GCP，也要看一下你選的 VM instance type。如果 CPU 不支援，那這項紅利你就吃不到。不是 bug，但期望落差會很大。
- 查詢計畫改變 (Query Plan Regression)：這是 PostgreSQL 升級永遠的痛。因為查詢優化器變聰明了，它對 SQL 的「解讀」可能會跟舊版不一樣，導致某些原本跑得好好的 query 突然變超慢。解法？沒有萬靈丹。只能在測試環境充分跑過你的核心查詢，用 `EXPLAIN ANALYZE` 抓出效能退步的語句，然後手動調整或改寫。
- Extension (擴充套件) 相容性：如果你用了大量的 extension，像是 PostGIS、TimescaleDB 或其他第三方工具，千萬、千萬要先去官網確認它們是否支援 PG17。常常發生的悲劇就是，資料庫升上去了，結果最重要的 extension 裝不起來，整個系統直接停擺。
- 備份與還原腳本：檢查一下你的備份還原腳本。雖然核心工具 `pg_dump` 和 `pg_restore` 都會向下相容，但如果你在腳本裡寫了一些特定版本的系統 view 或函式，可能會在新版找不到。升級前，務必在測試機上完整跑一次「備份->還原」的演練。
嗯... 大致上是這樣吧。總的來說，PG17 這次的更新，我覺得是蠻務實的。沒有畫什麼遙不可及的大餅，而是專注在解決大家每天都會遇到的痛點。速度變快、資源用更少、安全性更高。對於還在用 PG14 或更舊版本的人來說，這次升級的誘因真的很大。就算是從 PG16 升，光是 Vacuum 的改善，就值得考慮了。 👍
你呢？看完這些新功能，你最期待或最擔心的是哪個部分？留言分享一下你的看法吧！
