skip to Main Content

NoSQL Databases

Last Updated:
Analyst Coverage:

Originally a NoSQL database was conceived to be a database that was not relational and did not support SQL. Practice has determined that people want SQL, so the “No” in NoSQL now stands for “not only”. Thus, a NoSQL database is one that does not store data in relational tables (either row-based or columnar). Unfortunately, this definition is not especially useful: it means that databases such as Adabas or IMS, not to mention object oriented and XML databases (just to give another couple of examples) are, technically, NoSQL databases.

Leaving aside this question it is perhaps better to define what NoSQL databases are, rather than what they are not. The database architectures that are commonly thought of as falling under the NoSQL banner are key-value stores, document stores and column stores (not be confused with column-based relational databases). In addition, Graph and RDF databases may be considered to be NoSQL databases but they have some very distinct characteristics that differentiate them from other NoSQL products and they are treated as a separate subject in their own right by Bloor Research. There are also hybrid databases that share features of different NoSQL models such as Document-Graph stores.

There are NoSQL databases targeted at batch-based analytics, real-time analytics and transaction processing so it is not possible to generalise about relevant use cases except to say that products aimed at transaction processing will be ACID compliant and the others won’t be. Also in this context many NoSQL databases are “eventually consistent”: this is not good enough for true OLTP environments.

One feature that characterises what most people think of as NoSQL databases (but excluding a number of graph database products) is that they are designed to scale out rather than up. That is, they run across distributed, usually low cost, clustered environments. If you want more capacity you add new nodes rather than expanding a particular server. Commonly this process involves sharding, which is the way that you distribute data across the nodes in the cluster in order to optimise performance. However, unless additional measures are provided, sharding is only useful if you know in advance how you are going to access the data. Note that some (column-based) relational databases also use sharding: these should not be confused with NoSQL databases.

Depending on the type of NoSQL database there are several potential benefits that can be derived from using them. The first is that they run on low cost hardware. However, the expertise and management costs of administering and programming a NoSQL deployment may exceed that of a conventional environment to the extent that any savings are more than swallowed up.

Secondly, NoSQL databases are better suited to storing a variety of structured and unstructured data types, that traditional relational environments have not supported in the past. However, the major relational vendors are adding things such as support for JSON documents so this advantage is shrinking and may eventually disappear.

Thirdly, many (not all) NoSQL databases are schema-free. This makes them significantly more flexible when it comes to adding new types of information: you don’t have to change the schema definition.

Finally, there are specific advantages related to NoSQL databases that address the transaction processing and real-time analytics markets. In the case of the former these are akin to NewSQL databases: true distributed capability, much smaller footprint, easier management and so on. With respect to real-time analytics, NoSQL databases simply do something that you can’t do with a conventional database. In practice, these sort of solutions can be thought of as low-end streaming analytics platforms. They won’t cope with the sort of volumes (millions of events per second) that true event streaming products but will do very nicely thank you, for tens of thousands of events per second, which is more than you could expect a comparably priced relational product to achieve.

Perhaps the biggest trend in the NoSQL space is towards Apache Spark and away from Hadoop and MapReduce (though Spark will run with the Hadoop distributed file system, among others). Spark provides significantly better performance (orders of magnitude) for some applications as well as supporting SQL, graph analytics and streaming analytics.

It has been suggested elsewhere that the term “NoSQL” will no longer be a differentiating factor by 2017, as the major database players add more capabilities to their own database products. While the NoSQL tag will no doubt remain, we agree with this view.

More generally we have now got to the stage where vendors are starting to disappear – either going out of business altogether, being acquired by larger companies either to leverage the technology internally or for incorporation into their own product stack.

Everybody and his uncle is playing in the NoSQL space in one way or another but we are already starting to see consolidation. For example, Apple acquired Acunu (Cassandra based) and Experian acquired 4Store (a graph database). In both cases these were for internal use only so these are just two examples of products that have now disappeared. We expect many more to follow.


  • Actian logo
  • AEROSPIKE logo
  • AWS logo
  • Cambridge Semantics (logo)
  • COUCHBASE logo
  • DataStax (logo)
  • ESGYN DB logo
  • Franz Inc (logo)
  • Grakn logo
  • MARK LOGIC logo
  • Memgraph (logo)
  • MONGO DB logo
  • N5 logo
  • Neo4j (logo)
  • Objectivity (logo)
  • Ontotext (logo)
  • Redis Labs (logo)
  • SCYLLA logo
  • SPARSITY logo
  • Stardog (logo)
  • TigerGraph (logo)

These organisations are also known to offer solutions:

  • Accumulo
  • Berkeley DB
  • Cloudata
  • Cloudera
  • CouchDB
  • Datameer
  • Dynomite
  • GenieDB
  • GlobalsDB
  • Hadapt
  • Hadoop
  • HamsterDB
  • Hbase
  • HortonWorks
  • Hypertable
  • IBM
  • Lexis Nexis
  • MapR
  • MonetDB
  • Oracle
  • Pivotal
  • RaptorDB
  • RIAK
  • Scalien
  • Splice Machine
  • Teradata
  • Tokyo Cabinet
  • Voldemort
  • Zettaset
AEROSPIKE InBrief cover thumbnail


Aerospike is a distributed, massively parallel, NoSQL database with a three-tier architecture
REDIS InBrief cover thumbnail

Redis Enterprise (February 2020)

Redis Enterprise is an in-memory, distributed (automated partitioning), NoSQL database with a key-value store as its underpinning.
The cover of SQL Engines on Hadoop

SQL Engines on Hadoop

There are many SQL on Hadoop engines, but they are suited to different use cases: this report considers which engines are best for which sets of requirements.
InBrief SCYLLA DB cover thumbnail


ScyllaDB is a Cassandra compatible database developed using C++ rather than Java. As a result in has a smaller footprint and better performance that Cassandra.
Cover for All about graphs: a primer

All about graphs: a primer

Over the last few years graph databases have been the fastest growing sector within the database market ...
SPARSITY InBrief cover thumbnail

Sparsity Technologies Sparksee

Sparsity Technologies Sparksee is a property graph database that focuses on high performance deployment at scale and on embedded systems.
Cover for EsgynDB and HTAP

EsgynDB and HTAP

This paper discusses the sorts of features needed to support HTAP processing and then considers the capabilities of EsgynDB within this context.
Cover for the Cambridge Semantics AnzoGraph InBrief

Cambridge Semantics AnzoGraph (2019)

AnzoGraph is a massively parallel RDF database targeted primarily at large scale analytic environments
Back To Top