最適合誰
需要跨多個 SQL/NoSQL 資料庫建立統一瀏覽介面的中小型團隊。特別適合資料散落在 MySQL、PostgreSQL、MongoDB 等多處、又不想花時間建 ETL 管線的場景。架構師研究資料聯邦設計模式時也值得一看。
我實際怎麼用
透過 Docker Compose 快速啟動三容器環境，連接現有 PostgreSQL 後自動產生 CRUD 介面。主要用於驗證「不搬移資料、查詢時聯結」的資料聯邦概念，作為多資料源統一查詢層的架構設計參考。
真正強的地方
- 以 JSON-LD 風格跨庫映射關聯（虛擬連結資料圖），瀏覽任何記錄即可追蹤至其他資料庫的相關記錄
- 不複製資料，查詢時動態聯結，省掉整條 ETL 同步管線的維護成本
- JSON Schema 驅動 UI：前端表單與版面配置由 Schema 定義，擴充性高
- REST / OpenAPI / OData / JSON:API 四種 API 標準都支援，第三方整合友善
- 有公開 Playground，零安裝即可試用核心功能
失敗模式與不該用的情境
- AGPL-3.0 授權傳染是最大法律風險：對外提供服務的商業系統必須公開原始碼
- 社群偏小（142 Stars / 15 Forks），遇到問題可能需要自己翻原始碼
- 聯邦查詢效能瓶頸：跨庫查詢效能取決於最慢的資料源，不適合即時分析場景
- 前端綁定 Angular，React/Vue 開發者無法直接利用前端元件
- 不適合需要高效能 OLAP 分析的場景
價格、上手門檻與風險
- 開源免費，但 AGPL-3.0 授權意味商業閉源使用需購買授權
- Docker Compose 一鍵啟動，中等難度。進階設定需理解 JSON Schema 與 Linked Data 概念
- 風險：社群規模小、單一團隊維護、AGPL 授權傳染
結論
Dashjoin 的「不搬移資料的資料聯邦」理念值得研究，作為架構設計參考很有價值。但社群規模過小加上 AGPL 授權限制，更適合當概念驗證工具，別指望拿來當生產環境的長期依賴。痛點是多庫整合但不想建 ETL 的話，花半天試玩 Playground 就能判斷這條路值不值得走。