NoSQL database types
Though non-relational databases have existed in computing since the 1960s, and in informal use for most of human history (think about a dictionary — it's just a paper version of a key-value store), NoSQL as a concrete concept took off in the late 2000s in response to cheaper storage, and a growing need for flexibility and scale in Web 2.0 applications.
Since then, NoSQL has divided into four main accepted categories and myriad sub-categories:
Document databases
Document databases, document stores, or document-oriented databases store data in the form of documents. These documents are often semi-structured and use standard encoding or formats like JSON, BSON, YAML, or YML.
Documents are referenced by an ID, name, or other key and can contain complex nested structures. This makes them incredibly useful for storing complex, hierarchical, and related but different data.
An example is a blog, which may have separate documents for individual posts, users, and comments, each with its own sub-items like author, email address, or likes. The stored documents often mirror structures like objects used in development, making them easy to plug into a data-driven application framework.
In an abstract sense, the most well-known document database is the World Wide Web, which uses URLs or IP addresses as a key to reference documents composed in HTML.
Learn more about document databases.
Key-value databases
Key-value databases, or key-value stores, are the simplest form of NoSQL database. A key-value store holds a list of unique keys and their corresponding values.
Since these values can be complex and hierarchical or nested, key-value stores seem similar to document databases, and they are. The biggest difference is that document databases store values transparently, and key-value databases do so opaquely — a document store knows what the contents of every document are. In contrast, a key-value store only knows the key and which value to return.
Because of their simple design, key-value stores are usually the fastest type of NoSQL database and don't require a query language to implement.
Wide-column databases
Also known as column-oriented databases, column-family stores, and wide-column stores, these structures superficially resemble traditional relational databases in that they store data in tables, rows, and columns.
They differ because the NoSQL implementation allows individual rows to have different columns with different data types. This semi-structured approach makes wide-column databases very effective at operations that require frequent row and column-based aggregation and querying. This is especially useful for big-data analytics like fraud detection, where the validity of an action can be quickly compared to an individual's typical behavior and the typical behavior of every individual at a specific point. The wide-column structure also lends itself well to time-based analysis.
Due to their similarity to relational databases, many wide-column databases support SQL or SQL-like querying languages, making the transition from relational to non-relational easy.
Graph databases
Graph databases store data in a mathematical graph structure, where individual data points are called "nodes" and are connected to each other by relationships called "edges." Each node can have one or more properties, like a user ID or email, while each edge can have a type and a direction, like "knows" or "likes." A key feature of graph databases is "index-free adjacency," where every node contains pointers to every connected or adjacent node, allowing access to related items without needing to do an index lookup.
A similar and often interchangeable concept is a triplestore or resource description framework (RDF) store, which stores subject-predicate-object data types like "NoSQL is non-relational" or "Aerospike offers graph databases."
Because graph databases focus on the relationships between nodes as much as they do on the nodes themselves, these kinds of NoSQL databases are highly adopted among social networks, where the relationships between people, places, posts, and subjects are critically important. However, with the growth of generative AI and the focus on machine learning and large language models, graph databases are finding new life mapping the relationships between tokens, words, concepts, and intent.
Other types of NoSQL databases
Multi-model databases
Some NoSQL databases limit any given database to a specific type or model, while others, called multi-model databases, support multiple types within the same database. This makes them even more flexible and allows for a dynamic development flow where data structures can be added to the database as needed.
In-memory databases
Rather than storing data on long-term hardware like solid-state drives (SSDs) or hard disk drives (HDDs), in-memory databases store the data in volatile memory, making them incredibly fast. However, the cost of this speed is high: volatile memory is much more expensive than non-volatile memory. This limits their use to functions like caching or messaging, where low latency is critical.
Hybrid-memory databases
Some databases, like Aerospike, split the difference between traditional and in-memory storage by storing part of the data in volatile memory and part in long-term storage. Often, keys or indices are stored in volatile for ultra-fast lookup, while the values are stored on a disk for more cost efficiency.
NoSQL database type overview
Lookup index | Data stored | Pros | Cons | Good for | |
|---|---|---|---|---|---|
Document | Document ID or field | Document containing complex, queryable data | Very flexible, can store any kind of data within individual documents, data in documents is directly accessible | Can require more storage space, slower lookups, and can be difficult to maintain | Blogs, news sites, e-commerce, and other catalogs, multi-modal data storage like music playlists |
Key-value | Key | Value-containing non-queryable data | Very fast and simple, doesn't require dedicated query language or syntax | No visibility into values prior to retrieval, no ability to interact with just part of a value independently of the whole | Caching, session data, and simplifying more complex databases for faster access |
Column-oriented | Row, column, or both | Aggregated row or column value, or individual cell value | Flexible and pseudo-relational, efficient aggregation and comparisons, high compressibility | Less efficient for online transactional processing that requires many small reads and writes | Big data analysis, time-series, logging and analytics |
Graph | Token lookup index, or relationship to accessed node | Node object with unique properties and its edges | Ideal for relationships, easy to traverse and navigate relationships, enables complex emergent behavior for AI | Difficult to understand/learn, not optimized for analysis across the entire dataset, can be difficult to scale | Relationship data, social networks, generative AI |
Features, advantages, and weaknesses of NoSQL
Forrester Research called NoSQL databases “critical for all businesses to support modern business applications.” It noted that half of global data and analytics technology decision-makers have implemented or are implementing NoSQL platforms. That's for good reason, as NoSQL databases have specific benefits for modern applications.
Horizontal scalability
Whereas traditional relational databases scale vertically (also referred to as “scaling up”), NoSQL databases are horizontally scalable (“scaling out”) through sharding: breaking up the data into partitions, and being able to add or remove an arbitrary number of nodes and clusters for these partitions at any time. Adding nodes and clusters on demand scales faster and more efficiently than adding resources to a specific node.
This makes NoSQL databases much more efficient at handling large quantities of data, but at the tradeoff of being much more difficult to achieve ACID compliance.
High availability
Because of how NoSQL databases scale, they're built to synergize with distributed computing and cloud architectures. This makes them incredibly resilient and highly available — if a node goes down or can't be reached, other nodes can provide the missing data. NoSQL systems, because of their distributed nature, are almost by definition, built for high availability. Some even offer five-nines availability.
As a byproduct of the high availability and built-in replication, NoSQL databases tend to default to offering eventual or tunable consistency," rather than offering immediate or strong consistency, and thus tend to have difficulty with transactional operations without significant application workarounds.
Low latency/fast queries
NoSQL databases are typically built to optimize query and data retrieval speed, making them ideal when time is of the essence. This comes down partially to the underlying architecture design, partly to how data and indices are handled, and partly because querying is built to avoid overly complex processes like multiple complex joins.
While looking up and performing analysis on NoSQL databases is very fast, transactional procedures are often slower and more cumbersome than with traditional databases.
Flexibility and dynamic schemas
NoSQL databases can hold any kind of data, with or without defined schemas, structured or unstructured, and often with multiple structures within the same database. This makes them easy to build quickly within and allows for substantial changes without the need for heavy migrations or complex data transformations.
However, the lack of hard typing or schemas can introduce more opportunities for errors and decrease security. It can also make selecting the correct database type for a given application more difficult. Unless you're working with a multi-model database, it can require changing your database well into a project.
Conceptual simplicity
NoSQL databases typically store data in the format it's used in, or at least one that's similar. Unlike traditional SQL databases, NoSQL can store objects, JSON documents, images, sound files, and relationship data in a legible and ready-to-use state. In many cases, all the data necessary for a session can be retrieved with a single query using a single key. This makes NoSQL databases easy to integrate directly and simplifies database design.
It can also complicate database design when optimizing for speed or size. Because the data can be stored how it's used, it's tempting to take shortcuts and build overly complex data structures that grow cumbersome at scale and make access difficult and confusing. It can also lead to quickly ballooning database sizes for certain data types, especially with document databases.
'New' technology
SQL has been in use and has become increasingly common over the last two decades, but it's still a relatively young and immature technology. Not only does this add excitement to the field, but there's still significant growth and expansion happening in features, concepts, and underlying technologies. NoSQL databases are almost exclusively open source, with large contributor communities and new flavors and use cases being developed constantly.
This also means there are few standards, many proprietary query languages, fragmented improvements, fewer tools than for SQL, and a dizzying and confusing number of choices.
NoSQL databases vs. SQL databases
NoSQL | SQL | |
|---|---|---|
Flexibility | Structured, semi-structured, or unstructured data in various formats and types, sometimes within the same database. No need to define schema up front | Structured tables oriented around rows and columns with predefined schemas |
Scalability | Built for horizontal scalability, supports vertical scalability natively | Built for vertical scalability, can be made horizontally scalable through add-ons |
Availability | Designed to be distributed, fault-tolerant, and with high replication | Can be made distributed, fault-tolerant, and replicable through add-ons |
Speed | Fast queries, especially if database type matches need. Fast analysis and real-time processing (OLAP) workflows. Slower transaction (OLTP) workflows | Fast transaction workloads, slower queries, much slower real-time processing |
Data integrity | BASE (basic availability, soft state, eventual consistency) compliance, some database management systems offer ACID compliance | ACID-compliant |
Query language | It depends on the specific database, ranging from simple CRUD for key-value stores to proprietary languages for some specific implementations | Structured query language (SQL) |
Best for | Large datasets, high availability, analysis, and processing-heavy workloads, mixed data type or structures/structure level, Agile development, and whenever query speed is a core requirement | Highly structured data that requires significant security, compliance, and integrity. Data that requires a lot of complex joins. Heavy transaction workloads |
Are NoSQL databases better than SQL databases?
Different doesn't mean better, and NoSQL is just that: different from SQL. For some applications and environments, a traditional SQL relational database will be the best option. For others, NoSQL will have obvious advantages. Just like deciding between a hammer and a screwdriver, the right tool will depend entirely on what you want to do with it.
Ready to dive deeper into the world of NoSQL databases? Explore our comprehensive guide to NoSQL types, features, and best use cases.