當我們使用數據庫時webapp數據存儲到db，經常需要在數據庫和客戶端的應用之間寫類似轉換層的東西，將數據庫的查詢語句轉化成的HTTP調用。這些工作在編寫的每一個App中被一次次開發重復著。
將我們拯救了出來！通過我們的客戶端App，可以直接和數據庫通訊。它使用HTTP作為主要的通訊方式，沒有特殊的協議，沒有特殊的驅動：只有REST和HTTP。你可以通過你的瀏覽器，curl或像這樣的REST客戶端直接和連接。
換句話說，是真正“為Web而生的數據庫”。
Sync：的殺手級特性
另一個特性是，它從底向上都被設計成完全同步友好的數據庫。
舉個例子，如果你擔心客戶端應用的潛在危險，你可以直接在歐洲設一個，再在北美搞一個，亞洲搞一個。在這些數據庫之間開啟雙向復制之后，客戶端就可以使用其中任何一個。
使這一切都可以運行在你的瀏覽器里。
討論
：我已經使用作為React 應用的數據庫6個月了webapp數據存儲到db，用數據庫作為后端的存儲，這樣我們就可以使用設備更多的存儲空間，而不只是50M。它工作得非常好，在一個離線緩存中維護數據，然后再同步到 Ocean上的 2.0。 讓它在React 里工作非常有挑戰性。讓我們的系統跟上的更新也非常有挑戰性。實際上我們使用 5.4.5，因為6.x版本中有 ，我還沒有時間去搞明白哪里不兼容。社區（尤其是Nolan )非?；钴S，給出示例、聽取反饋回答問題等都非常積極。
：我們已經在產品環境中使用大約15個月了。當初選擇它是因為這是一個綠色軟件，它給了我們兩個優勢：簡單的離線支持、實時同步功能，配合后端的程序很方便。因為這個東西實際上就是一個帶有本地緩存的Web App，部署新版本非常簡單。
在架構方面，我們有大約有250個用戶，每個都有獨立的Couch數據庫。我們還沒有評估Couch 2.0，使用的還是Couch 1.6.
然而，我們在使用的過程中，還是遇到了一些問題：
載入時間問題。當你從0開始載入一個數據庫時，非常耗時。初始化一個20-30M的數據庫大約會花15-30分鐘的時間，我們必須周期性地存儲dump的文件，這樣節省了一些時間。不過我覺得.0的同步協議已經解決了這個問題；
瀏覽器限制。當我們超過了瀏覽器的容量顯示（通常是iOS的，50M），我們就不得不采取一些具有創造性的做法。現在我們的方案是，為每一個客戶運行兩個數據庫，一個是完整版本的數據庫，另一個只存在7-8天。Pouch向后者同步數據。我們在完整數據庫和臨時數據庫之間周期性地進行過濾復制。在客戶端，如果一個客戶需要7天之前的數據，就將Pouch切換到在線模式，作為一個庫從在線數據庫中取得數據；
處理沖突。因為/是分布式的，所以當用戶基于相同的數據版本做了更新時，得當心沖突；
自定義后端邏輯。因為Pouch直接與Couch連接，所以不能在需要時完自定義后端邏輯。我們必須引入一個REST后臺通道，以確保我們的后端在需要時運行額外的邏輯。