2026-06-28 — MinIO 封存後的 S3 替代方案、pgEdge ColdFront 冷熱分層 beta 發布、WAL-RUS 以 Rust 重寫 WAL-G 降低 70% 記憶體

MinIO 停止維護後，Ceph 與 Garage 成為 S3 相容儲存的主要繼承者

LWN.net · 2026-06-25

背景

MinIO 社群版於 2025 年 12 月進入維護模式，GitHub 儲存庫隨後在 2026 年 2 月正式封存為唯讀狀態，不再接受 PR 或安全更新。授權從 Apache 2.0 改為 AGPL v3 是觸發這波遷移潮的長期根因，企業用戶和自架用戶都開始評估替代方案。LWN 的分析文章聚焦在兩個最受關注的選項：老牌分散式儲存 Ceph，以及輕量 Rust 實作的 Garage。

Ceph：企業級但重量級

Ceph 透過 RadosGateway（RGW） 提供 S3 相容介面，並統一支援物件、區塊與檔案儲存。最小部署至少需要 Monitor、Manager、OSD 與 Gateway 等多個元件，記憶體需求從 4 GB 起跳，實際環境往往更高。Ceph 的強項在於 S3 API 完整度高，支援 Lifecycle Policy 與 Kafka 通知等進階功能。適合已在使用 Ceph 作為統一儲存基礎設施的組織，作為 MinIO 的直接替換選項。

Garage：為邊緣與地理分散設計

Garage 由法國非營利組織 Deuxfleurs 以 Rust 開發，版本 v2.0 於 2025 年 6 月釋出。設計核心是跨越 200ms 以上延遲網路的地理分散複製，採用 CRDT（Conflict-Free Replicated Data Types）維持一致性，不需要中央協調器。單一無依賴執行檔可在 ARMv7/v8 或 x86_64 上執行，最低需求為 1 GB RAM 與 16 GB 磁碟，適合異質二手硬體。

Garage 在 S3 相容性方面支援 Nextcloud、Matrix、Mastodon 與 Rclone 等常見應用，但尚未實作 Lifecycle Policy 與 Kafka 整合。授權為 AGPL v3，與 MinIO 後期相同，需留意衍生軟體義務。社群規模約 79 位貢獻者，每年三次發布週期。

選型比較

影響範圍

對於已有 Ceph 叢集的組織，擴充 RGW 是阻力最小的路徑。邊緣部署或資源受限環境則以 Garage 為首選，其低資源需求與地理分散原生支援在這類場景具備明顯優勢。此外，RustFS（Apache 2.0）作為新興替代方案也引起關注，但目前仍處於 alpha 階段，尚不適合生產環境。

原始來源：LWN.net — A look at MinIO alternatives: Ceph and Garage

pgEdge ColdFront：讓 PostgreSQL 同時承載 OLTP、分析與 AI 工作負載的冷熱分層擴充

pgEdge / PostgreSQL.org · 2026-06-26

背景

pgEdge 於 2026 年 6 月 26 日宣布 ColdFront 進入 beta 階段，這是一套以 PostgreSQL 擴充形式實作的透明資料分層系統。它讓應用程式無需修改任何 SQL 或程式碼，即可將冷資料自動搬移至 Apache Iceberg 格式並存放於 S3 相容物件儲存。目標是在單一 PostgreSQL 端點下統一處理 OLTP、分析與 AI 工作負載。

核心改動

ColdFront 在 PostgreSQL 的 SQL 層攔截查詢，將 DML 路由至正確的儲存層。熱資料留在 PostgreSQL 原生分區，冷資料以 Parquet 格式寫入 Iceberg，由以 Go 撰寫的 archiver daemon 依設定的 watermark 定期搬移。讀取與寫入（包括 UPDATE、DELETE）均可穿透至冷層，應用程式僅看到一個統一的 table 名稱。

分析掃描透過 pg_duckdb 1.5.4（內嵌 DuckDB 向量化引擎）執行，據官方公告在 60M 行資料集、6 節點叢集下實測吞吐量達 4.4M rows/second。Iceberg REST catalog 使用 Lakekeeper，物件存放支援 AWS S3、SeaweedFS、Azure Blob Storage（ADLS Gen2）及 Google Cloud Storage。

規格細節

ColdFront 支援標準未修改的 PostgreSQL 16、17、18，授權採用 PostgreSQL License（開放原始碼）。有兩種主要操作模式：

• Tiered 模式：近期資料在 PostgreSQL 分區，舊資料自動搬移至 Iceberg；透過 hot_period 與 retention_period 參數控制生命週期。
• Decoupled 模式：整張 table 從一開始就存放於 Iceberg，PostgreSQL 成為無狀態計算前端，僅保有薄層 wrapper view 與 metadata。

ColdFront 可與 pgEdge Spock multi-master 叢集整合，實現跨節點分散式分層。

影響範圍

ColdFront 目前為 beta 預發行版本，官方文件明確指出介面、磁碟格式與行為可能變動，且存在資料遺失風險，不適合用於生產環境。pgEdge 計畫在 2026 年下半年將其整合至 pgEdge Enterprise Postgres 與 pgEdge Cloud。對於希望在不引入獨立資料湖基礎設施的前提下降低儲存成本的 PostgreSQL 用戶，此方案值得追蹤。

原始來源：GitHub — pgEdge/coldfront、PostgreSQL.org 公告

WAL-RUS：ClickHouse 以 Rust 重寫 WAL-G，解決 Go GC 造成的記憶體浪費問題

ClickHouse Blog · 2026-06-25

原本的問題

WAL-G 是廣泛使用的 PostgreSQL 備份與 WAL 封存工具，以 Go 撰寫。ClickHouse 的工程師觀察到，在資源受限環境（尤其是禁止 memory overcommit 的主機）下，Go 的垃圾回收機制會造成虛擬記憶體呈鋸齒狀波動，峰值約達 2.8 GB（以 4 個並行 worker 測量）。這使得資源規劃困難，也無法在記憶體嚴格限制的節點上穩定運行。

採用的方法

ClickHouse 以 Rust 從頭重寫，產出 WAL-RUS（開源於 ClickHouse/wal-rus），核心設計原則為串流 I/O、不對完整 WAL segment 進行緩衝。主要技術決策包括：

• 以 Rust 顯式記憶體模型取代 GC，確保配置量可預測
• 有界 worker pool 搭配謹慎的並行控制，避免任意擴張緩衝
• 持久化物件儲存連線供背景連續處理使用
• 最小化資料複製與中間緩衝，適合串流工作負載

WAL-RUS 完整沿用 WAL-G 的 WALG_* 與 PG* 環境變數，與 WAL-G 歸檔格式雙向相容，可無縫切換而無需重新備份。相容性細節記錄於倉庫內的 WALG_COMPAT.md。

實際效果

在 4 個並行 worker 的基準測試下，WAL-RUS 虛擬記憶體使用量低於 1 GB，對比 WAL-G 的約 2.8 GB，降幅超過 70%。WAL 封存吞吐量與 CPU 使用率在兩者間相當，未有顯著退步。目前支援的儲存後端為 file://、s3://、gs://，壓縮格式支援 zstd、brotli、lz4、lzma、gzip。指令集涵蓋 wal-push、wal-fetch、backup-push、backup-fetch、backup-list 及 daemon 模式等，API 設計與 WAL-G 對齊。

原始來源：ClickHouse Blog — WAL-RUS、GitHub — ClickHouse/wal-rus