Here are some notes on the different flavors of NoSQL databases:

Key-Value Stores

  • Examples:  Amazon’s DynamoDB (and Dynomite, the open-source version), Microsoft’s Azure Table Storage
  • Consists of databases, tables, and rows.
  • The purpose is to have schema-free records.
  • Each row has a key, but there can be a different number and name of columns within each row.
  • E.g.
    • AddressID:  123, City: Austin, State: Texas
    • AddressID:  124, Village: Abberley, County: Worcestershire

Document Stores

  • Examples:  CouchDB, MongoDB
  • Document stores are actually specialized Key-Value Stores
  • Consists of tables and rows.
  • Rows are called “documents,” typically JSON objs, nested objs and arrays, or links to documents in another database.
  • Great for content management systems.
  • Old versions of documents are retained (also great for content management systems).
  • E.g.
    • Database: Customers
      • CustomerID: 123, FirstName: Robert, LastName: Corvus,
        • Address:  123 Fake Street, City: Austin, State: TX
        • Orders: OrderId: 123 –>
          • which points to OrderID: 123 in the Orders Database with TotalPrice: 100.00, Items:Item345, Item678 –>
            • each item points to Items database, etc.

Wide Column Stores

  • Examples:  Google’s Big Table, Hadoop / Hbase (the open source version of Big Table), Facebook’s Cassandra
  • Consists of tables, rows, column families (aka supercolumns), and columns
  • Column families and columns can vary from row to row
  • Very tree-like structure
  • Great for Big Data
  • E.g.
    • Table: Customers
      • CustomerId: 123
        • Supercolumn: Address
          • Column: Street: 123 Fake Street
          • Column: City:  Austin
          • Column: State: Texas
        • Supercolumn: Orders
          • Column: MostRecentOrder: 123
    • Table:  Orders
      • OrderId: 123
      • Total Price: 100.00

Graph Database

  • Examples:  Neo4j (open source), Microsoft’s Trinity, Twitter’s FlockDB, InfiniteGraph
  • Consists of nodes and edges
  • Nodes are like rows in a table and can have properties and values
  • Edges are like the join between rows and tables
  • Good for social networks and for any relationship-chain representation (friends, comments, group memberships, as well as the usual data like addresses, purchasing history, etc )
  • Avoids the self-joins and many-to-many table joins needed in relational (aka SQL ) databases
  • E.g. (from


« »