RocksDB 這個 embedded LSM 引擎從 2012 年由 LevelDB fork 出來以後，撐起了 Kafka Streams、CockroachDB、TiKV、Ceph、MyRocks 這一整代分散式系統的儲存層。它的架構前提從第一天起就是一顆掛在本機的 SSD——write ahead log 直接落盤、SST 檔案排在同一個 filesystem 上、compaction 靠隨機讀寫本機磁碟撐吞吐。想在雲上跑 RocksDB 就得配一顆 EBS 或本地 NVMe，還得自己做跨 AZ 複製才拿得到 S3 那個等級的持久性。SlateDB 是 2024 年開始出現的另一條路線，2026 年 7 月推進到 0.14.1——它把 LSM tree 的所有資料，包括 WAL 跟 SST，全部直接寫到 S3 相容物件儲存，本機磁碟只做快取，不再是持久層。
這個轉向表面上很激進，但它接住的是一個實際問題：現在有多少 stateful 服務其實根本不需要單機微秒級寫入延遲，只是被 RocksDB 這條技術路徑逼著配磁碟、配副本、配自動故障轉移——結果一堆 serverless、durable execution engine、串流處理系統為了維護幾 MB 到幾 GB 的內部狀態，得養一整套完整的 stateful 基礎設施。SlateDB 押的是這條需求線的另一端。
Object storage 直接當持久層是不是自欺欺人
先講最容易被質疑的點：S3 的寫入延遲一次 PUT 動輒 20 到 80 毫秒，這種數字放進 OLTP 寫入路徑聽起來像自殺。SlateDB 的答案是不打算裝作沒這回事——它明確定位為「lowish latency, high throughput」，跟 RocksDB 在同一等級的延遲比賽從一開始就放棄。
作為交換，SlateDB 拿到三件本地磁碟做不到的事：S3 的 11 個 9 持久性不用自己補副本、儲存容量沒有上限、跨 AZ 複製免費內建。EBS 的持久性只在單一 AZ 有效，要達到 S3 同等級需要跨三個 AZ 複製，加上 EBS 每 GB 費用是 S3 Standard 的四倍以上——實務上想拿到同樣的持久性保證，EBS 方案的成本會比印象中高很多。
儲存成本的差距在小型 stateful 工作負載上最明顯。DynamoDB 每 GB 每月 $0.1、S3 Standard $0.023，同樣資料量塞進 SlateDB 每月儲存成本大約是 DynamoDB 的四分之一。API 費用要看寫入模式——S3 每 1000 次 PUT $0.005、每 1000 次 GET $0.0004，如果每筆 put() 都直接觸發 PUT 會被 API 費用打爆，這就是為什麼 SlateDB 整套設計都圍繞在寫入批次化上。
寫入路徑分成兩段，WAL 跟 SST 各自寫進 S3
寫入骨架維持 LSM 的標準結構：新資料先寫 WAL 拿到持久性、同時進記憶體裡的 MemTable、MemTable 滿了以後 flush 成 L0 SST、compaction 把 L0 合成有序分層。差別在每個階段的儲存介面。
WAL 在 SlateDB 是一份直接寫進 S3 的 append-only 檔案。每個寫入請求進來以後，客戶端可以選要不要等 S3 回 200 才回應——選等的話拿到 durable write 保證但延遲貼近 S3 的 round trip time、選不等的話延遲降到毫秒級但 crash 時可能掉幾毫秒的資料。這個 tradeoff 每筆寫入自己決定，不是全域設定。
Group commit 是控制 API 成本的關鍵。SlateDB 會把一段時間窗口內的所有寫入合併成一次 S3 PUT，時間窗預設可調——設短一點延遲小但 PUT 次數多、設長一點反過來。實務上跑幾十筆 write per second 的服務把窗口設在 50 到 100 毫秒，API 成本會壓到跟 EBS 相近的水位，但拿到 S3 的持久性跟彈性。
MemTable 用雙緩衝設計避免 flush 阻塞新寫入。當 mutable MemTable 達到閾值，會被凍結成 immutable、丟給背景執行緒 flush 成 L0 SST、同時開一份新的 mutable MemTable 接手。這套雙緩衝在 RocksDB 裡也有，SlateDB 的差別在 flush 目的地是 S3 而非本地 filesystem。
L0 SST 的排列跟傳統 LSM 一樣是無序的——每個 flush 出來一份新檔案、彼此 key range 可能重疊、讀取時得掃過所有 L0。Compaction 把它們合併成有序的 Sorted Runs，range 查詢只要 binary search 找到覆蓋 key 的那份 SST 就好。
Manifest 是 SlateDB 的一致性支點
SlateDB 對物件儲存的一個關鍵利用是「S3 現在對單一 object 的 PUT 是強一致」這件事。這在 2020 年之前的 S3 不成立，各種基於 S3 的資料系統早期都得繞開這個限制。AWS 宣布 read-after-write consistency 之後，這條路才第一次變成可行。
Manifest 檔案就是這個一致性保證的直接應用。它是 S3 上一份小的 metadata，記錄當前所有 SST 的位置、WAL 的 checkpoint、compaction 狀態。任何 writer 想推進資料庫狀態都得 PUT 一份新 manifest；同一時間只有一份是有效的。fencing 機制透過 conditional PUT（If-Match ETag）確保只有持有正確 generation 的 writer 才能成功——第二個 writer 想搶會直接 fail，實現 single-writer 的邏輯保證，不需要外部協調服務。
這個做法有一個明顯的美感：整個資料庫的「權威狀態」就是 S3 上那一份 manifest 檔案，沒有其他任何東西。備份就是複製 bucket、restore 就是換 endpoint、跨區複製就是 S3 replication。運維面的複雜度大幅降下來。
讀取路徑靠三層快取撐住，不然會被 S3 延遲吃死
寫入還可以靠 batch 攤銷 API 費用，讀取的 latency 就沒那麼容易繞。SlateDB 用三層快取結構撐住讀取效能：熱資料放在 in-memory block cache、warm 資料放在本地 disk cache、cold 資料才回 S3 拉。
Block cache 是常見的 LSM 優化，把 SST 的 data block 依 LRU 保留在記憶體裡。Disk cache 是 SlateDB 額外加的一層，把最近讀過的整份 SST 檔案落地到本機磁碟——這個磁碟不參與持久性保證，只當快取，掛了直接重建。本機 SSD 從「持久層」降級為「快取層」以後，容量小、便宜的磁碟就撐得住。
點查詢還會加上 bloom filter 降低不必要的 SST 讀取。壓縮設定跟 RocksDB 類似，可以在 LZ4、Snappy、Zstd 之間選——壓縮率高的 zstd 省 API 傳輸費、CPU 開銷大；壓縮率低的 LZ4 反過來。
冷讀取的延遲仍然貼近 S3 的 GET 延遲（幾十毫秒），這個沒辦法優化掉。SlateDB 適合的工作負載必然是「熱資料集小、cold 讀取容忍高延遲」這一類——AI agent 的長期記憶、durable execution 的中間狀態、串流處理的窗口 state，這些場景的 working set 通常都能塞進幾百 MB 的記憶體快取裡。
該用 SlateDB 還是繼續用 RocksDB
放下技術新鮮感的選擇判斷其實直接。
繼續用 RocksDB 或 RocksDB-cloud 的情境：延遲敏感的 OLTP 主資料庫、單機吞吐量壓到極限的高頻寫入、已經有一套跨區複製方案、對 stateful 運維習慣了。這些場景 SlateDB 的架構優勢換不回它多出來的 tail latency。
換 SlateDB 的情境：需要每個租戶一份獨立資料庫的多租戶架構（S3 的 flat namespace 天生支援上億個 key）、durable execution engine（Temporal、Restate 這類）的狀態儲存、無伺服器函數的持久狀態、想省掉 EBS 快照跟跨 AZ 複製的運維、需要幾秒內把一份資料庫複製到別的 region。這些場景 SlateDB 換來的彈性遠大於它輸掉的延遲。
有一個場景值得單獨提：把 SlateDB 當 Redis 的持久化替代品。Redis 的 AOF/RDB 在生產環境的痛點是「持久化跟複寫都得自己做」，用 SlateDB 頂替能拿到 S3 的持久性同時保留類似的 KV API pattern。但 SlateDB 目前不是 Redis 相容協議，應用程式端需要重寫。
Beta 階段的實務注意事項
SlateDB 現在還在 0.14.x，官方明確說明「no API compatibility guarantees」，跨 minor version 的儲存格式相容只保證相鄰版本之間可讀。生產部署要把版本升級當成一次正式運維動作處理，不能像 RocksDB 那樣升級透明無感。
功能上還在補的部分包括：merge operator、範圍刪除、change data capture、資料庫的 split / merge。這些大多已經有 RFC 但尚未 GA。想在生產跑 SlateDB 的工程團隊應該先確認自己的用例不踩這些洞。
觀察 SlateDB 的另一個角度是它加入了 Commonhaus Foundation。這個治理方式跟 Apache Software Foundation、CNCF 類似，把專案跟任何單一商業實體切開——比起 HashiCorp、Redis、Elastic 這幾年連環改授權的教訓，這對長期採用的公司是關鍵的保護。Dropbox、Goldsky、Tensorlake、Gadget 這幾家已經在生產跑 SlateDB，但要拿它取代 RocksDB 在 CockroachDB 或 TiKV 這種等級的系統，時機還沒到。
儲存引擎的下一輪分化
RocksDB 依舊會在延遲敏感的高吞吐場景守住地位，這在可見的未來不會變。SlateDB 這條路線押的是另一個生態變化——雲原生工作負載的 stateful 部分越來越多，但這些狀態其實不是傳統資料庫的形態，而是「一大堆小型獨立資料集」、「durable state 但不需要毫秒級延遲」、「彈性擴縮又要低成本」。這種需求過去只能用 DynamoDB、Cassandra 這類系統勉強撐住，SlateDB 提供的是「一個 embedded library 加上一個 S3 bucket」的替代方案。
在 VPS 上跑 durable execution engine、AI agent 平台、多租戶 SaaS 後端的場景，SlateDB 的架構優勢很直接：本機不需要大容量磁碟、備份策略退化成 S3 lifecycle 規則、跨區複製直接靠 S3 replication，運維面比自己維護 RocksDB 加快照方案簡單一整個數量級。
NCSE Network 在臺灣是方電訊機房提供 Intel Xeon Gold CPU 加 NVMe SSD 的 VPS 主機，搭配自架或第三方 S3 相容儲存跑 SlateDB 這類架構——本機 NVMe 集中處理快取與運算、持久層交給物件儲存，硬體資源用在 CPU 與記憶體上更有效率。前往 ncse.tw 了解 VPS 方案與規格細節。
