Types of NoSQL Databases

Compare how much the database can see in each panel. A key-value store sees one key and one value, while a graph database sees each person and each connection separately. The more the database can see, the more kinds of questions it can answer without help from your application.

Key-Value Stores

A key-value store works like a dictionary: you give it a unique key, and it returns the value stored under that key. John's whole record might be stored as the value of the key user:1. This is the simplest data model of the four, and a value can be anything from a short string to a large block of data.

Because every request names one key, the store can find the data quickly and can divide keys across many servers easily. The cost appears when you ask a different question. To find the user whose email is john.doe@example.com, a pure key-value store has no way to search inside its values, so your application must keep a second key for that lookup or read everything.

Key-value stores suit any data that you always fetch by a known key. Two common cases are session data, which records who is logged in, and caches, which keep temporary copies of data for fast reads. Some products add more to this model, and Redis, for example, offers typed values such as lists and sets.

Document Stores

A document store also saves one record under one key, but the database understands the record's contents. The record is a document, a structure of named fields that can contain nested values and lists, usually written as JSON and often stored in a binary form such as BSON. John's two orders can be stored inside his document as a list.

Since the database can read the fields, it can search on them and build indexes on them, which are lookup structures that speed up a search. You can therefore find John by email without reading every record. Documents in the same group can also have different fields, so a change in your data does not always require a change to the database.

The cost is that the structure of your documents decides which requests are easy. If John's orders are nested inside his document, reading John with his orders is simple, but a report across all orders needs more work. Document stores suit data that varies in shape and is usually read as a unit, such as product catalogs, user profiles, and content.

Column-Family Stores

A column-family store, also called a wide-column store, keeps data in rows that are found by a row key. Each row can have a large number of columns, and different rows can have different columns. Related columns are grouped into families that are stored together. For John, the row might look like this:

Here profile and orders are the two column families. Ana's row could have only the profile columns, and the empty orders columns would use no space. This layout works well for very high write volumes and for reads of a known row or a range of rows. It is therefore common for event data and for time-series data, meaning readings recorded over time, provided that you design the rows around the queries you will run.

Do not confuse this type with a columnar database. A columnar database stores all the values of one column together, which makes analytical work such as adding up one column across millions of rows fast. A column-family store is still organized by row, and such a calculation can be slow in it. Products also differ on flexibility: HBase lets you add new columns freely within a family, while Cassandra declares columns in a table definition and adds new ones with a schema change.

Graph Databases

A graph database stores things as nodes and the relationships between them as edges, and both can carry properties. John and Ana are two nodes, with a FRIEND_OF edge between them. Each relationship is stored as data in its own right, so the database can follow it directly.

This makes questions about connections fast. For example, "find the friends of John's friends who bought the same product" follows edges from node to node. A relational database would answer it with a series of joins, which are operations that combine rows from two tables, and the work grows quickly as the path becomes longer. Social networks, recommendation systems, and fraud detection all ask this kind of question.

This model has the opposite weakness. Graphs are harder to divide across servers than the other three models, because a single query that follows edges between machines needs network calls at each step. A graph database is also a poor fit when your application mainly reads and writes independent records.

Comparing the Four Types