前言
橫向對比
關系型資料庫
關系型這是最常見的經典的資料庫模式。關系資料庫管理系統（RDBMS），是基于集合理論的系統，實作方式是具有行和列的二維表。
關系資料庫嚴格強制使用類型，一般分為數值、字元串、日期和未解釋的二進制大對象，但我們看到PostgreSQL提供了一些擴充，如數組和cube。
适合
因為關系資料庫的結構性質，如果提前知道資料的布局，但是可能不清楚随後你打算如何使用這些資料，那麼關系型資料庫是合适的。或者，換句話說，你提前為組織的複雜性付出代價，以實作随後的查詢靈活性。許多業務問題正好是以這種方式模組化的，從接單到出貨以及庫存到購物車。你可能事先不知道以後将如何查詢資料，但資料在本質上是相當規範的，是以強制這種規範性是很有幫助的。
不适合
如果你的資料是高度可變的或者多層次的，那麼關系資料庫不是最合适。因為你必須提前指定模式，是以，處理記錄與記錄之間有很大變化的資料問題将遇到麻煩。假設考慮開發一個資料庫來描述所有自然界中的生物。建立你需要考慮到的所有特征的完整清單（hasHair、numLegs、laysEggs等）會很棘手。在這種情況下，你選擇的資料庫最好對可能的輸入有較少的預先限制。
鍵值型資料庫
KV将簡單的鍵映射到（可能）更複雜的值，就像一個巨大的哈希表。由于它們相對簡單，是以這種類型的資料庫實作起來最靈活。哈希查找速度快，在Redis的例子中就是這樣，速度是其主要的關注。哈希查找也容易分布化，是以Riak利用這一事實，側重于簡單管理的叢集。當然，它的簡單性可能對有複雜的模組化需求的資料是個缺點。
适合
由于很少或不需要維護索引，鍵-值存儲庫往往具有橫向的可擴充性，速度極快，或兩者兼而有之。它們特别适合于資料相關性不高的問題。例如，在Web應用中，使用者的會話資料滿足這個标準，每個使用者的會話活動會有所不同，并且大部分是與其他使用者的活動無關的。
不适合
往往缺乏索引和掃描功能，如果你需要能夠執行資料查詢，除了基本的CRUD操作（建立、讀取、更新、删除）以外，KV存儲庫的幫助不大。
列型資料庫
與KV和RDBMS存儲有許多的相似之處。像鍵-值存儲庫一樣，值的查詢通過比對鍵完成。類似于關系資料庫，把它們的值分組為零或多列，但是每一行可以填充任意多的資料。不同于前兩個資料庫，列型資料庫按列存儲類似的資料，而不是按行存儲資料。列的添加很容易，版本控制是小菜一碟，并且對于空值沒有存儲成本。我們看到了HBase是對這一類型的經典實作。
适合
傳統上，橫向擴充作為列型資料庫開發的一個主要的設計目标。正因為如此，它們特别适合于在幾十、幾百或幾千個節點的叢集上的“大資料”問題。它們也往往内置支援如壓縮和版本控制的功能。一個良好的列型資料存儲問題的典型例子是索引網頁。網頁上有大量的文本（好處來自于壓縮），在某種程度上互相關聯，并随着時間變化（好處來自于版本控制）。
不适合
不同的列型資料庫有不同的特點，并由此帶來不同缺點。但有一件事它們是相同的，那就是，最好基于你打算如何查詢資料，設計你的資料庫模式。這意味着，你應該預先對如何使用資料而不僅僅是資料将如何組成有一些想法。是以，如果你不能提前定義資料的使用模式（例如，需要快速的自由定義的報表），那麼列型資料庫未必是最合适的。
文檔型資料庫
文檔型資料庫允許每個對象有任意數量的字段，甚至允許對象作為值以任意深度嵌套到其他字段中。這些對象通常用JavaScript對象符号（JSON）表示，MongoDB和CouchDB都是這樣，但這絕不是一個概念要求。
由于文檔型資料庫不像關系資料庫那樣彼此相關，它們比較容易在幾個伺服器上實作分片和複制，這使得分布式實作相當普遍。
适合
文檔資料庫适合于涉及高度可變領域的問題。當你事先不知道你的資料看起來究竟像什麼樣子，文檔型資料庫是一個不錯的選擇。此外，由于文檔型資料庫的性質，它們往往能很好地映射到面向對象程式設計模型。這意味着在資料庫模型和應用模型之間移動資料時，阻抗性不比對的情況較少。
不适合
如果你習慣于在高度規範化的關系資料庫模式中執行複雜的聯接查詢，你會發現文檔型資料庫的功能匮乏。文檔型資料庫一般應包含大部分或全部正常使用所需的有關資訊。是以，在一個關系資料庫中，你最好自然地規範化你的資料，以減少或消除可能不同步的副本，而使用文檔型資料庫，非規範化的資料是常态。
圖資料庫
圖資料庫是一個新興的資料庫類型，更側重于自由解釋資料之間的互相關系而不是實際的資料值。作為我們的開源示例，Neo4j在許多社交網絡應用中日益普及。不像其他資料庫類型将相似的對象劃為共同的組，圖資料庫在形式上更自由——查詢包含兩個節點共享的邊，即在節點之間移動。随着越來越多的項目使用它們，圖資料庫在簡單的社交例子上不斷發展，用于更多差異細微的使用場景，例如，推薦引擎、通路控制清單和地理資料。
适合
圖資料庫似乎是為網絡應用量身定做的。典型的例子是社交網絡，其中節點代表互相之間有各種關系的使用者。使用任何其他的類型對這種資料模組化，往往難以适應，但圖資料庫會欣然接受。它們還是面向對象系統的完美比對。如果可以在白闆上模組化資料，就可以在圖中模組化。
不适合
由于節點之間的高度互相關聯，是以圖資料庫一般不适合網絡分區。因為圖的快速爬取意味着你不能與其他資料庫節點的網絡聯接，是以圖資料庫不能很好地向外擴充。可能的情況是，如果你使用圖資料庫，它會是一個較大系統的一部分，大容量資料存儲在其他地方，而在圖中隻儲存關系。