意識到this discussion有一個額外的旋轉。將couchdb連接到生產服務器與使用中間關係db
當前正在組織中的工程師之間爭論題目問題。
一方面，我們認爲將非關係數據庫（即CouchDB）掛接到生產服務器永遠不是一個好主意。他的架構建議是引入一箇中間關係數據庫作爲兩者之間的緩衝層（他特別推薦SQLAlchemy作爲Postgres-> Flask/Django之類的ORM）
另一方面，另一位工程師認爲，鑑於我們（相對較低）的綜合瀏覽量，我們可以在CouchDB中直接進行生產。
我很想知道更多關於nonrelational -> relational -> web page模式的優缺點，而不僅僅是nonrelational -> web page。
這是從來沒有掛鉤一個非關係型數據庫（即CouchDB的）到生產服務器
這聽起來很危險的教條給我一個好主意。
我不知道在CouchDB和webservice之間使用關係數據庫的任何好理由。什麼是「緩衝」數據庫？什麼讓你的CouchDB不是？或者爲什麼要使用CouchDB，如果您只能使用關係數據庫？
我能想到的唯一半合法參數是你需要它，因爲你有一些你需要的數據的關係建模，並且你必須轉換到關係數據庫來正確地做到這一點，並提供一個理智的接口到您的web服務。但是，在這種情況下，您應該只使用關係數據庫獨立（或圖形數據庫，或其他，但不是文檔存儲）。
另一方面，有很多反對意見，包括：涉及的數據重複，必須以某種方式發現和修復數據衝突的可能性，構建和維護額外系統以監控兩個數據庫並保持同步，在他們對數據建模的兩種方式之間進行轉換時遇到的挑戰，以及CouchDB的許多優點（靈活模式，數據複製不會導致單點故障，任意結構化數據，簡單縮放，方便的HTTP接口等）
我目前正在從事一項業務，該業務剛剛完成，成功部署了大約20個CouchDB，分佈在多個數據中心內，連續使用數千個服務器，每天爲數百萬用戶服務。這絕對是生產準備就緒，我不知道有任何實質性的性能或可靠性問題（只要您知道您在基礎架構設置方面正在做什麼）。
如果您的公司和開發人員不準備支持生產中的任何特定數據庫，那麼您可能不應該使用它。如果您是內部人員，並且在您的時間和技能不能滿足需求時使用外部支持選項，那麼如果技術支持您的需求，則可以做好準備。如果您準備好了，CouchDb已準備好生產。 – WiredPrairie