「無伺服器（Serverless）」這個詞已經陸續被套用在函式、API，而現在輪到了資料庫。就如同它的前輩們一樣，這並不代表背後真的沒有伺服器，而是意味著你再也不用去操心伺服器的存在。這是因為無伺服器資料庫會自動處理配置、擴展與容量規劃，讓開發團隊能將精力百分之百專注在建構應用程式，而不是天天當維護基礎設施的保姆。對於那些習慣了計算 RDS 執行個體大小、手動調整唯讀複本的團隊來說，這種思維轉變是非同小可的。本文將剖析無伺服器資料庫的運作原理、盤點目前的各大主流產品，並探討 Navicat 如何在這個新時代中完美融入。
究竟什麼才算「無伺服器」資料庫？
無伺服器資料庫最核心的決定性特徵在於「儲存與運算徹底分離」。在傳統的資料庫部署中，這兩者是緊密綁定的：你的執行個體擁有固定的 CPU、記憶體和硬碟空間，想要擴展效能就只能將整個執行個體升級。然而在無伺服器架構中，儲存層與運算層各自獨立，這代表它們可以各自進行彈性擴展。當流量突發峰值時，運算層可以瞬間拉高資源來應付，並在閒置時自動調降（甚至在沒有流量時降至零）；與此同時，你的資料依然完好無損地保留在儲存層，隨時待命。
這種模式為開發者帶來了兩個非常實用的實務變革。首先，你只需為實際使用的部分付費，而非為了應付尖峰而提前預留一堆閒置的容量。其次，你不再需要糾結執行個體大小是否調整得當，因為資料庫會根據工作負載自行調整。
Amazon Aurora Serverless
Aurora Serverless v2 是亞馬遜為 Aurora 打造的按需自動擴展配置，同時支援相容 MySQL 與 PostgreSQL 的版本。它能進行極為精細的資源微調——最小單位可達 0.5 個 Aurora 容量單位（ACU）——並且能在極寬廣的範圍內流暢擴展，完全不會中斷活動中的連線或交易。相較於初代 v1 最讓人詬病的冷啟動延遲問題，v2 在彈性擴展上變得無比流暢，且完美支援了 Aurora 的全套高階功能，包括多 Multi-AZ 部署、全域資料庫以及唯讀複本。
對於開發測試環境、事件驅動架構，或是流量波動極大且難以預測的系統而言，Aurora Serverless v2 是極佳的首選；加上它與 AWS 生態系的深度整合，非常適合原本基礎設施就託管在 AWS 上的團隊。
Neon
Neon 是一款開源的無伺服器 PostgreSQL 平台，其核心圍繞著所謂的湖倉資料庫架構建置：儲存與運算完全分離，資料持久化儲存於雲端物件儲存中，而運算節點在閒置時可降至零。當新的查詢抵達時，運算節點能在數秒內啟動並直接掛載既有的歷史資料，中間完全不涉及任何資料搬移。
對開發者最友善的功能莫過於資料庫分支。就像 Git 的分支功能一樣，Neon 利用寫入時複製技術，讓你能在幾秒內建立一個特定時間點的獨立資料庫副本。由於這個過程不會複製任何實際資料，因此建立分支既快又便宜。這使得建立功能分支、運行遷移並在完成後將其刪除變得非常簡單，而無需觸及生產環境。對於在 PostgreSQL 上建構系統、且希望在不離開 PostgreSQL 生態系的情況下獲得雲端原生敏捷性的團隊而言，Neon 已成為熱門選擇。
PlanetScale
PlanetScale 最初憑藉將 MySQL 帶入無伺服器時代而聲名大噪，其底層是由 Vitess 驅動——這正是支撐 YouTube 龐大流量的分散式資料庫叢集技術。它對開發者工作流的傑出貢獻，就是具備非阻塞結構描述變更的資料庫分支：你不再需要一邊執行 ALTER TABLE 一邊緊張得不敢呼吸，而是可以先建一個分支、修改結構描述、發起部署請求，確認沒問題後再無縫合併。
這幾年該平台發生了顯著的轉變。PlanetScale 在 2024 年終止了免費的 Hobby 方案，正式將重心全面轉向企業級客戶，付費方案改由每月 39 美元起跳。此外，他們也打破了原先僅限 MySQL 的限制，推出了建構在本地 NVMe 儲存之上的託管式分片 PostgreSQL 服務。如今，PlanetScale 的定位已堅定地走向高效能、大規模的平台，全面對接對吞吐量有嚴苛要求的團隊，而非業餘使用者。
其他值得注意的產品
除了上述三大巨頭，無伺服器資料庫的版圖依然在不斷擴張：
- Supabase: 在 PostgreSQL 之上疊加了完整的後端平台，除了無伺服器資料庫託管外，還增加了身分驗證、儲存與即時訂閱功能。
- CockroachDB Serverless: 主打分散式 SQL，能實現跨區域的自動分片與強一致性。
- Turso: 基於 libSQL（SQLite 的衍生版）建置，主打邊緣運算，能以極低的延遲提供每資料庫單一租戶的架構。
每種產品都代表了在簡單性與強大功能光譜之間的不同定位。
使用 Navicat 連線至無伺服器資料庫
引入無伺服器資料庫時，開發者最關心的實務問題之一就是：「我手邊現有的工具還能繼續用嗎？」幸運的是，絕大多數的無伺服器資料庫都刻意保持了與底層引擎完全一致的有線協定。這意味著，只要能連線到 MySQL 或 PostgreSQL 的用戶端，就能毫無障礙地連上它們——這當然包括 Navicat。
Navicat Premium 內建了專屬的 Amazon AWS 連線類型，直接支援與 Amazon Aurora 的連線。你可以在介面中配置 Aurora 連線，並完美享有與傳統 MySQL 或 PostgreSQL 執行個體一模一樣的全套旗艦級環境，包括查詢編輯器、資料檢視器、結構描述管理與資料傳輸。對於 Neon 和 PlanetScale，只需使用 Navicat 標準的 PostgreSQL 和 MySQL 連線類型即可。這兩家平台都會在後台控制面板提供標準的連線字串；你只需將主機、通訊埠、資料庫名稱與憑證輸入到 Navicat 的連線對話方塊中，並根據要求勾選啟用 SSL，便能一秒連通。
這意味著，無伺服器資料庫所帶來的創新工作流（如快速迭代、分支、安全的結構描述變更），能與 Navicat 強大的查詢分析、視覺化執行計劃、資料同步以及結構描述比對等專業功能完美聯手。你既能享受無伺服器基礎設施帶來的維運便利，又不必犧牲專業資料庫管理環境的深度與掌握感。
需要注意的一些隱憂
儘管無伺服器資料庫非常強大，但它並非在所有場景下都優於傳統的配置型資料庫。對於對延遲極度敏感的應用程式來說，即使新一代平台已經大幅改善，冷啟動依然是必須納入評估的現實因素。再者，由於運算節點會隨著流量縮減到零或重新啟動，連線池的管理變得前所未有地重要。雖然多數平台都內建了這個機制，但在正式上線前，務必先摸透所選平台的連線管理邏輯。最後，相較於傳統每個月固定的實例開銷，基於使用量的計費模式會比較難以精準預估。特別是對於那些擁有持續性、高吞吐量工作負載的系統，傳統的配置型資料庫有時候反而更具成本效益。
總結
無伺服器資料庫如今已經高度成熟，不再局限於開發測試環境，而是能穩健扛起各種生產環境工作負載的可靠選擇。不論是 Aurora Serverless v2、Neon 還是 PlanetScale，都對這個新世代架構給出了各自獨特的精采詮釋。你可以根據自身對資料庫引擎的偏好、規模需求以及團隊的工作流來做選擇。不論你最後選了哪一家，它們都能為團隊大幅解放維運的泥淖。更棒的是，因為它們完全相容標準的 MySQL 與 PostgreSQL，透過 Navicat 進行管理與調校不需要任何特殊設定，功能更不會打折。
