What is a NoSQL database?
NoSQL databases are a type of database system that replaces the rules, schema, and relational focus of traditional SQL databases with a more flexible, open-ended approach. They are sometimes referred to as "purpose-built databases" because each NoSQL database is uniquely designed to fit the needs of the application it supports. These qualities and other features like speed, scalability, and availability make NoSQL a favorite for modern agile development and complex applications like generative AI.
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.
The simple answer is that each one stores data differently. Specifically, SQL uses a “schema,” which is used to define how data that is composed will be put into the database. SQL schema is more rigid than the more flexible NoSQL schema.
With its more free-form style, any data can be stored in any record. This gives an organization faster access to data, an important consideration if you really need speed and simple accessibility over reliability or consistency. Another advantage: If you don’t want to be tied to a specific schema because you may want to make changes later, NoSQL allows you to do so, even with large amounts of data. NoSQL requires less management with automatic repair, easier data distribution and simpler data models.
Not every application will succeed under such flexibility. SQL provides more safeguards and greater consistency than NoSQL databases. At the same time, NoSQL is still the new kid on the block and there are potential problems that go along with being untested in many situations.
There are four basic types: key-value store, document-based store, column-based store and graph-based store (though you can build graph on top of key-value). Key-value is designed for storing, retrieving and managing associative arrays, a data structure known as a hash table. A good fit for key-value databases would be for storing session information, user profiles, preferences and shopping cart data. Document-based stores documents composed of tagged elements, and may be the most useful to content management systems, blogging platforms and web analytics. With a column store, data is stored in cells grouped in columns of data rather than as rows, and is also considered a good fit for content management, as well as expiring usage. Graph based has a flexible graph representation. It is often ideal for scalability concerns and where there are problem spaces such as connected data that is used in things like social networks.
The two most common consistency models are either ACID (atomic, consistent, isolated, durable) or BASE (basic availability, soft-state, eventually consistency). With ACID, once the data is written, you will be able to access the data and get a consistent view of it. With BASE, once data is written, it will eventually appear for reading, which is why it is seen as having looser consistency. The majority of NoSQL databases don’t provide ACID guarantees, which may not be a big deal when talking about having to wait a few moments to see a Facebook post. But if an organization is dealing with billion-dollar financial transactions, then that may be opening the door for fraud. (Note, there are just a couple NoSQL systems that have some form of strong consistency). Choosing the consistency needs to be decided on a case-by-case basis.
NoSQL databases use distributed clusters of hardware to scale up, and are considered to be cheaper and more scalable than SQL databases. The flexible, schema-less model can store, process and access various types of business data, while providing greater control over data storage and processing. Some enterprises are using relational databases along with NoSQL, while others are scrapping their relational databases in certain scenarios because they get better performance and scale at a lower cost with NoSQL.
The bottom line is that NoSQL databases are cheap and open source. NoSQL typically uses inexpensive servers to manage fast-growing amounts of data and transactions. This can be an important consideration if an organization can’t afford costly RDBMS databases that use big servers and storage systems. Since there are options in how NoSQL systems store data, they can use less or more servers, but typically at the detriment of some other performance characteristic.
There are a few, but the most common is in-memory (DRAM). In-memory has fast performance characteristics, but since DRAM is expensive, it can be costly to scale out. In addition, multiple copies of data need to be stored for redundancy as in-memory data isn’t persistent.
The complementary storage mechanism is on-disk, but performance degrades significantly with typical NoSQL systems. The benefit is fewer servers, however. Aerospike, however, combines the best of both worlds with their Hybrid Memory Architecture™, which only stores indexes on DRAM yet persists data on disk, with yet the same performance levels of in-memory. Aerospike also has All Flash, which preserves 95% of the performance but has all the data on disk, condensing server footprint. Lastly, Intel has their Optane DC Persistent Memory, which has the performance of DRAM with the persistence of disk, also for much higher data densities.
If your organization wants to provide a personalized experience, then it’s going to require a lot of data from demographics to behavioral – and the flexibility of NoSQL is just the ticket. Other top uses can be profile management, real-time big data, content management, catalogs, customer 360-degree view, mobile applications, the internet of things (IoT), digital communications and fraud detection (which is also dependent on behavioral analysis). Organizations that need low latency, high scalability and speed for large amounts of data find that NoSQL gives them the responsiveness they need.
There are a number of innovative features for NoSQL that are being developed, according to Forrester. Among them: greater automation that helps speed up NoSQL deployments and support more complex applications with little effort. In addition, open-source NoSQL solutions “are stable and ready for primetime,” Forrester reports.
What is a NoSQL database?
NoSQL databases are a type of database system that replaces the rules, schema, and relational focus of traditional SQL databases with a more flexible, open-ended approach. They are sometimes referred to as "purpose-built databases" because each NoSQL database is uniquely designed to fit the needs of the application it supports. These qualities and other features like speed, scalability, and availability make NoSQL a favorite for modern agile development and complex applications like generative AI.
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.
The simple answer is that each one stores data differently. Specifically, SQL uses a “schema,” which is used to define how data that is composed will be put into the database. SQL schema is more rigid than the more flexible NoSQL schema.
With its more free-form style, any data can be stored in any record. This gives an organization faster access to data, an important consideration if you really need speed and simple accessibility over reliability or consistency. Another advantage: If you don’t want to be tied to a specific schema because you may want to make changes later, NoSQL allows you to do so, even with large amounts of data. NoSQL requires less management with automatic repair, easier data distribution and simpler data models.
Not every application will succeed under such flexibility. SQL provides more safeguards and greater consistency than NoSQL databases. At the same time, NoSQL is still the new kid on the block and there are potential problems that go along with being untested in many situations.
There are four basic types: key-value store, document-based store, column-based store and graph-based store (though you can build graph on top of key-value). Key-value is designed for storing, retrieving and managing associative arrays, a data structure known as a hash table. A good fit for key-value databases would be for storing session information, user profiles, preferences and shopping cart data. Document-based stores documents composed of tagged elements, and may be the most useful to content management systems, blogging platforms and web analytics. With a column store, data is stored in cells grouped in columns of data rather than as rows, and is also considered a good fit for content management, as well as expiring usage. Graph based has a flexible graph representation. It is often ideal for scalability concerns and where there are problem spaces such as connected data that is used in things like social networks.
The two most common consistency models are either ACID (atomic, consistent, isolated, durable) or BASE (basic availability, soft-state, eventually consistency). With ACID, once the data is written, you will be able to access the data and get a consistent view of it. With BASE, once data is written, it will eventually appear for reading, which is why it is seen as having looser consistency. The majority of NoSQL databases don’t provide ACID guarantees, which may not be a big deal when talking about having to wait a few moments to see a Facebook post. But if an organization is dealing with billion-dollar financial transactions, then that may be opening the door for fraud. (Note, there are just a couple NoSQL systems that have some form of strong consistency). Choosing the consistency needs to be decided on a case-by-case basis.
NoSQL databases use distributed clusters of hardware to scale up, and are considered to be cheaper and more scalable than SQL databases. The flexible, schema-less model can store, process and access various types of business data, while providing greater control over data storage and processing. Some enterprises are using relational databases along with NoSQL, while others are scrapping their relational databases in certain scenarios because they get better performance and scale at a lower cost with NoSQL.
The bottom line is that NoSQL databases are cheap and open source. NoSQL typically uses inexpensive servers to manage fast-growing amounts of data and transactions. This can be an important consideration if an organization can’t afford costly RDBMS databases that use big servers and storage systems. Since there are options in how NoSQL systems store data, they can use less or more servers, but typically at the detriment of some other performance characteristic.
There are a few, but the most common is in-memory (DRAM). In-memory has fast performance characteristics, but since DRAM is expensive, it can be costly to scale out. In addition, multiple copies of data need to be stored for redundancy as in-memory data isn’t persistent.
The complementary storage mechanism is on-disk, but performance degrades significantly with typical NoSQL systems. The benefit is fewer servers, however. Aerospike, however, combines the best of both worlds with their Hybrid Memory Architecture™, which only stores indexes on DRAM yet persists data on disk, with yet the same performance levels of in-memory. Aerospike also has All Flash, which preserves 95% of the performance but has all the data on disk, condensing server footprint. Lastly, Intel has their Optane DC Persistent Memory, which has the performance of DRAM with the persistence of disk, also for much higher data densities.
If your organization wants to provide a personalized experience, then it’s going to require a lot of data from demographics to behavioral – and the flexibility of NoSQL is just the ticket. Other top uses can be profile management, real-time big data, content management, catalogs, customer 360-degree view, mobile applications, the internet of things (IoT), digital communications and fraud detection (which is also dependent on behavioral analysis). Organizations that need low latency, high scalability and speed for large amounts of data find that NoSQL gives them the responsiveness they need.
There are a number of innovative features for NoSQL that are being developed, according to Forrester. Among them: greater automation that helps speed up NoSQL deployments and support more complex applications with little effort. In addition, open-source NoSQL solutions “are stable and ready for primetime,” Forrester reports.