Expanded NoSQL Use Cases Deserve a Second Look

I recently examined how evolving functionality had fueled the adoption of NoSQL databases, recommending that organizations evaluate NoSQL databases when assessing options for data transformation and modernization efforts. This recommendation was based on the breadth and depth of functionality offered by NoSQL database providers today, which has expanded the range of use cases for which NoSQL databases are potentially viable. There remain a significant number of organizations that have not explored NoSQL databases as well as several workloads for which it is assumed NoSQL databases are inherently unsuitable. Given the advances in functionality, organizations would be well-advised to maintain up-to-date knowledge of available products and services and an understanding of the range of use cases for which NoSQL databases are a valid option.

Almost one-quarter (22%) of respondents to Ventana Research’s Analytics and Data Benchmark Research are using NoSQL databases in production today. Our Benchmark Research also shows that more than one-third (34%) of organizations still have no plans to use NoSQL databases. Based on the expanded functionality now available, I believe that could be a mistake. If you have not investigated the use of NoSQL databases or have not evaluated the available products and services for some time, it’s time to reconsider the options. Evaluating potential use cases for NoSQL databases typically begins with the four primary categories I discussed previously: key-value stores, wide-column stores, document-oriented databases and graph databases. A good use case for a key-value store is an application that requires low-latency processing of a high volume of simple read/write operations. Examples include maintaining session state for web applications and gaming environments, application data caching, serving user profiles and preferences, providing leaderboards, supporting shopping carts and serving advertisements. Wide-column stores (also known as column family databases) are also well-suited to applications that require low-latency processing of simple read/write operations, with the additional need to store and process multiple attributes. These databases are well-suited to any of the use cases cited for key-value stores as well as storing and processing log data, time series data, IoT sensor data and advanced personalization and recommendations. For more complex use cases such as delivering recommendations, real-time inventory and fraud detection, key-value stores and wide-column stores may serve a limited aspect of the overall functionality. They can be deployed alongside other components for stream processing, machine learning model inferencing and graph processing (either from a single vendor or multiple providers) as part of a deliberate strategy of using multiple, dedicated data stores (sometimes referred to as polyglot persistence).

The innate flexibility of document databases’ ability to store data without fixed schema makes them suitable for use cases that require storage and processing of data sets with diverse attributes and values. Classic use cases include user profiles, product catalogs and content management. However, the inherent flexibility of the document model means that document databases can be considered general purpose databases to be used across a variety of industries and use cases, including customer experience, payment processing, IoT and time series, and operational analytics. The fact that the schema is both intuitive and can evolve also makes document databases suitable for rapid and agile development projects, making them attractive to application developers. Identifying relationships between entities is an important consideration in many applications, achieved by join operations between tables in a relational database or documents in a document database. Graph databases are inherently more suitable for use cases that rely on relationships, given that the data model represents the entities and values as well as the relationships between them. Classic use cases that take advantage of the graph model include social media, fraud detection and navigation systems as well as content and knowledge management. Other potential applications include network management, asset management, customer experience management, recommendation engines, security and threat detection, master data management and supply chain management. The native representation of relationships can also be significant in surfacing “features” for use in machine learning modeling.

Although these are the four primary categories of NoSQL databases, many products are now able to support a combination of key-value, wide column, document and graph capabilities, blurring the lines between the appropriate use cases. Additionally, as we described, NoSQL vendors have added capabilities and features that have previously been the preserve of the incumbent relational vendors, including relational database concepts, structured query language and transactional consistency. This has confounded common assumptions about consistency as it relates to NoSQL databases. Traditional relational databases have been designed to favor strong consistency based on the principle of atomic, consistent, isolated and durable (ACID) transactions. They are designed to deliver an error if the system cannot guarantee that the data being read is the last updated write. In comparison many — although not all — NoSQL databases were designed to favor availability via an approach known as BASE — basic availability, soft-state eventual consistency — that ensures that a read request receives a response even if it cannot be guaranteed that the most recent update has been written to every node in the distributed system. However, it is a misconception that all NoSQL databases are eventually consistent. Most graph databases are designed to provide guaranteed consistency, while many of the most prominent document database products (including MongoDB and Couchbase) have added support for distributed multi-document ACID transactions. As such, NoSQL databases are increasingly suitable for use as direct replacements for applications that depend on relational databases, although they are more likely to be used to support new or rewritten applications designed to exploit their native functionality. I assert that through 2026, incumbent relational database vendors will continue to be deployed for the majority of existing operational workloads, with emerging relational and non-relational database providers primarily adopted for new applications.

While the requirements that drove the emergence of NoSQL were particular to web giants and emerging application startups, organizations in other industries — including retail, marketing, gaming and gambling, travel and tourism, financial services, healthcare and government — have recognized the potential advantages of NoSQL databases. Given the functional evolution of the NoSQL database sector, I recommend that organizations in all industries reconsider current assumptions about NoSQL databases and evaluate the latest offerings to ensure a comprehensive understanding of the available products and services and their suitability for supporting a growing range of use cases.

Regards,

Matt Aslett