GoatDB 作為一種新穎的資料庫解決方案出現，它透過將計算推向客戶端，顛覆了傳統的雲架構。這款為 Deno 和 React 應用程式設計的輕量級即時資料庫，因其非傳統的資料管理和同步方法在開發者社群引發了討論。
顛覆傳統資料庫架構
GoatDB 採用了與傳統資料庫系統根本不同的方法。它沒有遵循標準的雲優先模型（即擁有重後端、複雜資料庫和帶臨時資料快取的輕客戶端），而是使用類似 Git 的架構將大部分計算推送到客戶端。建立者解釋了這一設計理念：
「想象一下現代的雲優先架構，你有一個厚重的後端和複雜的資料庫，一個帶有臨時資料快取的輕量級客戶端，以及在它們之間傳輸資料的 API 層。這是一個將傳統設計顛倒過來的實驗，使用類似 Git 的架構將大部分計算推送到客戶端，但用於你的實際應用資料。」
這種顛覆帶來了有趣的副產品，包括即時協作能力、安全資料審計，以及在生產環境中同時維護不同分支上的多個應用版本的能力。
GoatDB的主要特點
- 無需專用基礎設施（在客戶端執行）
- 具有離線優先能力的彈性架構
- 邊緣原生架構（在客戶端進行處理）
- 內建同步功能的即時協作
- 具有類似Git提交圖的資料版本控制
- 透過加密驗證保障安全性
- 自動衝突解決
查詢效能和實現
GoatDB 透過純 TypeScript 函式處理排序和過濾查詢。與依賴伺服器端索引的傳統資料庫不同，GoatDB 在協程中執行線性掃描，以防止 UI 執行緒阻塞。該系統利用其版本控制基礎逐步更新查詢結果，使其適用於有大量資料需求的應用程式。
根據文件中分享的基準測試，GoatDB 可以處理數十萬個專案被多使用者即時編輯的情況。效能指標顯示，讀取操作每項花費不到 0.001 毫秒，而從 10 萬個專案集合中過濾約 3,000 個專案的查詢可在大約 100 毫秒內完成。
GoatDB 基準測試結果（在 2018 款 MacBook Pro 上）
- 寫入：每項約 0.25 毫秒
- 讀取：每項小於 0.001 毫秒
- 查詢：從 10 萬項中篩選約 3 千項需要約 100 毫秒
- 開啟倉庫：每 10 萬次提交小於 1.5 秒
執行時要求和相容性
目前，GoatDB 需要 Deno 作為其執行環境，儘管 React 整合是可選的。這一要求引發了關於其可訪問性的一些討論。雖然該專案目前僅限於 Deno，但開發者表示他們正在努力支援未來的其他框架和執行時。
GoatDB 具有對稱設計，可在客戶端和伺服器端同時執行。對於客戶端儲存，它提供了 OPFS（Origin Private File System）和 IndexedDB 兩種後端，為瀏覽器環境中的資料持久化提供了靈活性。
與現有解決方案的比較
該資料庫的方法引發了與已建立解決方案如 PouchDB 和 SQLite 的比較。當被問及相比與 CouchDB 同步的 PouchDB 的優勢時，GoatDB 的建立者強調可擴充套件性是關鍵區別。一些社群成員質疑，當現有技術如 SQLite（作為 WASM 模組）可能服務於類似目的時，效能優勢是否足以證明建立新資料庫解決方案的必要性。
一個顯著的區別是 GoatDB 的實現是作為類似 Git 的分散式複製提交圖，而不是傳統的包裝為資料庫的 B 樹結構。這種架構實現了其離線優先功能，客戶端可以在伺服器不可用時繼續工作，並在重新連線時恢復伺服器狀態。
記憶體考慮和限制
GoatDB 客戶端方法的一個實際限制是記憶體使用。由於資料主要在記憶體中處理，應用程式受到客戶端裝置可用記憶體的限制。然而，開發者指出，GoatDB 允許顯式地將部分資料解除安裝到磁碟，類似於桌面應用程式中關閉檔案，這可以幫助管理記憶體限制。
資料庫的小體積——僅 8.2KB 的包大小——使其對於已有 JavaScript 執行時的 Web 應用程式特別有吸引力，解決了對應用程式增加不必要重量的擔憂。
在以伺服器為中心的資料庫解決方案占主導地位的環境中，GoatDB 代表了重新思考現代 Web 應用程式資料架構的一個有趣實驗。雖然不適合每個用例，但其創新的客戶端資料管理方法為需要即時協作和離線功能的應用程式提供了令人信服的優勢。