MongoDB 用 SSPL 鎖住 Atlas、Cosmos DB 又是封閉黑盒：FerretDB 2.0 把 wire protocol 接在 Postgres 上

文件型資料庫這幾年在自架這條路上越來越尷尬。MongoDB 自從 2018 年換成 SSPL 之後，雲端服務商不能再包成 SaaS 對外賣，連帶讓社群版的演進跟 Atlas 之間的功能差距越拉越大。微軟在 2025 年初把 Azure Cosmos DB for MongoDB 背後的引擎用 MIT 授權開源，這個叫做 DocumentDB 的 PostgreSQL extension 讓「在 Postgres 上跑 MongoDB 協定」變得務實。FerretDB 在 2026 年 3 月發布 2.0 GA，把這個 extension 整合進來，等於把整套自架 MongoDB 的路重新接通。

SSPL 把 MongoDB 的商業地位收緊，自架路線跟著繃緊

MongoDB Inc. 在 2018 年 10 月把伺服器端授權從 AGPL 換成 Server Side Public License，最核心的條款是：把 MongoDB 當作服務對外提供，就要把整個服務堆疊（含管理介面、自動化工具、監控腳本）的原始碼釋出。對絕大多數使用者來說這沒影響，但對雲端供應商而言這條規定等於關門。AWS、GCP、Azure 在那之後都從自家的 MongoDB-as-a-Service 撤退或改用替代實作，Amazon DocumentDB 跟 Azure Cosmos DB for MongoDB 就是在這個背景下出現的。

對自架的中小團隊而言，SSPL 本身不違法、不會被告，但週邊生態的變化是真實的：合規工具廠商不太敢碰、CNCF 不收、Linux 發行版的官方套件庫也陸續移除 MongoDB。Debian 12 之後就不再內建，Ubuntu 也只剩 22.04 之前能 apt install。要在新的 VPS 上裝 MongoDB，得到官方 repo 簽 GPG key、加 source list，這個流程跟 Postgres 一行 apt install 的體驗差太遠了。

加上 MongoDB Atlas 的訂價是按計算與儲存量計費，量大起來不便宜。對只是要存 JSON 文件、跑幾個 CRUD 的應用，每月幾百美元的雲端帳單很難對老闆解釋。

DocumentDB extension：微軟把 Cosmos DB 的核心搬到 Postgres 上

故事真正的轉折點是 2025 年 1 月，微軟把 Azure Cosmos DB for MongoDB（vCore 版本）背後的 PostgreSQL extension 用 MIT 授權公開。這個 extension 由兩部分組成：pg_documentdb_core 負責 BSON 資料型別、向量索引、地理空間查詢這些底層原語；pg_documentdb_api 在上面實作 CRUD、aggregation pipeline 跟 index management 的 SQL 函式。

把這兩個 extension 灌進 Postgres 之後，一張表可以同時接收 SQL 跟 BSON 查詢，BSON 用 binary 儲存、不會被反覆 serialize/deserialize。對團隊來說，這代表手上的 Postgres 維運工具（pgBackRest 備份、pg_stat_statements 分析、邏輯複製、CDC）都可以直接套用在文件資料上，不必另外養一套 MongoDB 的 ops 流程。

微軟的動機其實不難猜：把 DocumentDB 推成事實標準，Azure 上的 Cosmos DB 才有更多人願意進場。對社群來說，動機跟結果一致——extension 是 MIT，誰都可以拿去做產品。

FerretDB 2.0 把 wire protocol 翻譯這層收乾淨

FerretDB 從 1.x 開始就是一個 MongoDB wire protocol 的代理，把 MongoDB driver 送進來的 BSON 命令翻成 SQL 丟給 Postgres。1.x 時代的瓶頸很明顯：所有 BSON 都要序列化成 JSONB 存進 Postgres，aggregation pipeline 的複雜操作要在 FerretDB 內部模擬，常見的 array index、partial index 跑起來很慢。

2.0 把後端整個換成 DocumentDB extension。BSON 直接存原生格式，pipeline 操作下推到 extension 裡執行，FerretDB 自己只負責協定解析與翻譯。官方公布的數字是 1.x 到 2.0 的常見工作負載快了 20 倍以上，這個倍數聽起來誇張，但對照 1.x 時代用 JSONB 模擬 BSON 的效能反差，數字並不離譜。

實際部署起來，2.0 的 docker-compose 大概長這樣：一個 FerretDB 容器對外接 27017 port，後端連到一個帶 DocumentDB extension 的 Postgres。官方有預先打包好的 ghcr.io/ferretdb/postgres-documentdb image，省去自己編譯 extension 的步驟。連進去之後，MongoDB Compass、mongosh、Node.js 的 mongodb 套件可以原樣使用，連線字串只要把 host 換成 FerretDB 的位置。

services:
  postgres:
    image: ghcr.io/ferretdb/postgres-documentdb:17
    environment:
      POSTGRES_USER: ferret
      POSTGRES_PASSWORD: 改成真正的密碼
      POSTGRES_DB: postgres
    volumes:
      - pgdata:/var/lib/postgresql/data

  ferretdb:
    image: ghcr.io/ferretdb/ferretdb:2
    ports:
      - 27017:27017
    environment:
      FERRETDB_POSTGRESQL_URL: postgres://ferret:改成真正的密碼@postgres:5432/postgres

volumes:
  pgdata:

這套堆疊的記憶體用量比原生 MongoDB 少不少，FerretDB 本身大概 50MB 上下，剩下都是 Postgres 自己的 work_mem 跟 shared_buffers。對只跑幾個應用的 VPS 來說，這個資源佔比相對舒服。

哪些場景能直接搬，哪些別硬塞

2.0 對 CRUD、filter、簡單 aggregation 的相容性已經到能直接接手既有 MongoDB 應用的程度。Mongoose、Prisma 的 MongoDB connector、Spring Data MongoDB 寫出來的查詢多半不用改。文字搜尋（$text）的支援補上了，向量搜尋（$vectorSearch）也接到 Postgres 的 pgvector 上，整合 RAG 場景比 1.x 順手很多。

但有些東西還是有距離。$lookup 跟 $facet 這兩個 aggregation stage 在 2.0 的支援還不完整，複雜 join 跟多重 facet 的查詢有機率跑不過。Change Streams 只支援單一 collection 層級，要做 cluster 範圍的訂閱還沒辦法。Transactions 的隔離級別跟 MongoDB 4.0+ 的行為不完全一致，跨 collection 的多步驟事務在邊角案例會出現差異。

GridFS、Atlas Search、Atlas Vector Search、$graphLookup 這些算進階或專有功能也沒有支援。如果手上的應用重度依賴 Atlas 的全文搜尋或 BI Connector，遷移過去會比想像中辛苦。

效能上的取捨也要面對。FerretDB 經過 wire protocol 翻譯這層，單次查詢會比原生 MongoDB 多個幾毫秒的延遲。對讀多寫少、需要強一致性的工作負載這個差距不痛；對每秒上萬筆寫入的高吞吐場景，Postgres 的單機 write throughput 會先撞上瓶頸。建議把 FerretDB 定位在中小規模的應用後端，超出這個範圍就該認真評估 sharding 或回頭考慮原生 MongoDB。

跟 Amazon DocumentDB、Cosmos DB 對照怎麼選

MongoDB 的雲端替代品有三條主要路線，相容性各自卡在不同的時期。Amazon DocumentDB 走的是反向工程 MongoDB 3.6 API 的舊路線，相容性停在那個版本沒有再追，現代 driver 的新指令多半跑不過。Azure Cosmos DB for MongoDB 有兩種型態：RU（請求單位）計費的舊版相容性更老，vCore 版本就是基於 DocumentDB extension、相容性最接近現代 MongoDB。

FerretDB 2.0 在相容性這條軸上是跟 Cosmos DB vCore 同源，但部署在自家機房可控、授權是 Apache 2.0 完全開源、底層就是普通 Postgres——這是只用 Cosmos DB 拿不到的條件。對需要把資料留在臺灣機房、或合規要求資料不可出境的應用，FerretDB 是目前少數能同時滿足 MongoDB 協定相容跟資料主權的選項。

接到自家 VPS 上的部署考量

把 FerretDB 拉進生產環境的拓撲，跟既有的 Postgres 運維模式可以共用大半。同一臺 Postgres 上技術上可以跑業務的 SQL 表跟 FerretDB 的文件 collection，但比較推薦的做法還是分開兩個 Postgres database，備份策略、版本升級、Vacuum 排程各自獨立比較不會互相影響。

備份直接用 pgBackRest 或 Barman 對 Postgres 做 base backup 加 WAL streaming，比 mongodump 快很多，restore 時也是熟悉的流程。監控部分，Postgres 既有的 exporter 都能用，FerretDB 本身會 expose Prometheus metrics，要做查詢延遲、wire protocol 錯誤率的圖表也不困難。

副本架構走 Postgres 的 streaming replication 就行，搭配 Patroni 或 repmgr 做 failover。FerretDB 是無狀態的協定代理，前面掛幾個都可以，做 HA 不會比一般 Postgres 應用更麻煩。

把 MongoDB 這條路重新放回開源軌道

DocumentDB extension 加上 FerretDB 2.0 這組合，本質上是把過去七年因為 SSPL 而被切斷的「自架 MongoDB」這條路接回來。不是用換掉協定、要求應用改寫的方式，而是直接讓 Postgres 講 MongoDB 的話。對手上有既有 MongoDB 應用想搬回自家機房、或想避開 Atlas 訂閱費的團隊，2.0 已經是值得開始試的版本。

NCSE Network 在臺灣是方電訊機房提供 Intel Gold CPU 加 NVMe SSD 的 VPS 主機，跑 FerretDB 加 Postgres 這類需要本地高 IOPS 的資料庫工作負載條件穩定，把整套自架文件資料庫搬回臺灣機房，延遲跟頻寬也都不會是瓶頸。