{Event}  Save 50% on registration to MongoDB.local NYC with code BANNER50! Learn more >

Understanding the Different Types of NoSQL Databases

NoSQL is an umbrella term to describe any alternative system to traditional SQL databases.

NoSQL databases are all quite different from SQL databases. They use a data model that has a different structure than the traditional row-and-column table model used with relational database management systems (RDBMS).

But NoSQL databases are all quite different from each other, as well.

This article will describe the four main types of NoSQL databases and their uses.

What NoSQL databases have in common

As explained in When to Use NoSQL Databases, NoSQL databases were developed during the internet era in response to the inability of SQL databases to address the needs of web-scale applications that handled huge amounts of data and traffic.

Companies are finding that they can apply NoSQL technology to a growing list of use cases while saving money in comparison to operating a relational database. NoSQL databases invariably incorporate a flexible schema model and are designed to scale horizontally across many servers, which makes them appealing for large data volumes or application loads that exceed the capacity of a single server.

The popularity of NoSQL has been driven by the following reasons:

  • The pace of development with NoSQL databases can be much faster than with a SQL database
  • The structure of many different forms of data is more easily handled and evolved with a NoSQL database
  • The amount of data in many applications cannot be served affordably by a SQL database
  • The scale of traffic and need for zero downtime cannot be handled by SQL
  • New application paradigms can be more easily supported

NoSQL databases deliver these benefits in different ways.

Understanding differences in the four types of NoSQL databases

Here are the four main types of NoSQL databases:

Document databases

A document database stores data in JSON, BSON, or XML documents (not Word documents or Google Docs, of course). In a document database, documents can be nested. Particular elements can be indexed for faster querying.

Documents can be stored and retrieved in a form that is much closer to the data objects used in applications, which means less translation is required to use the data in an application. SQL data must often be assembled and disassembled when moving back and forth between applications and storage.

Document databases are popular with developers because they have the flexibility to rework their document structures as needed to suit their application, shaping their data structures as their application requirements change over time. This flexibility speeds development because, in effect, data becomes like code and is under the control of developers. In SQL databases, intervention by database administrators may be required to change the structure of a database.

The most widely adopted document databases are usually implemented with a scale-out architecture, providing a clear path to scalability of both data volumes and traffic.

Use cases include ecommerce platforms, trading platforms, and mobile app development across industries.

Comparing MongoDB vs. PostgreSQL offers a detailed analysis of MongoDB, the leading NoSQL database, and PostgreSQL, one of the most popular SQL databases.

Key-value stores

The simplest type of NoSQL database is a key-value store. Every data element in the database is stored as a key value pair consisting of an attribute name (or "key") and a value. In a sense, a key-value store is like a relational database with only two columns: the key or attribute name (such as "state") and the value (such as "Alaska").

Use cases include shopping carts, user preferences, and user profiles.

Column-oriented databases

While a relational database stores data in rows and reads data row by row, a column store is organized as a set of columns. This means that when you want to run analytics on a small number of columns, you can read those columns directly without consuming memory with the unwanted data. Columns are often of the same type and benefit from more efficient compression, making reads even faster. Columnar databases can quickly aggregate the value of a given column (adding up the total sales for the year, for example). Use cases include analytics.

Unfortunately, there is no free lunch, which means that while columnar databases are great for analytics, the way in which they write data makes it very difficult for them to be strongly consistent as writes of all the columns require multiple write events on disk. Relational databases don't suffer from this problem as row data is written contiguously to disk.

Graph databases

A graph database focuses on the relationship between data elements. Each element is stored as a node (such as a person in a social media graph). The connections between elements are called links or relationships. In a graph database, connections are first-class elements of the database, stored directly. In relational databases, links are implied, using data to express the relationships.

A graph database is optimized to capture and search the connections between data elements, overcoming the overhead associated with JOINing multiple tables in SQL.

Very few real-world business systems can survive solely on graph queries. As a result graph databases are usually run alongside other more traditional databases.

Use cases include fraud detection, social networks, and knowledge graphs.

As you can see, despite a common umbrella, NoSQL databases are diverse in their data structures and their applications.

Related resources

Ready to get started?

Try MongoDB, the primer NoSQL database, in the cloud with MongoDB Atlas.