NoSQL Databases - Non-relational Databases Explained

A NoSQL database is a type of non-relational database, many of which store data in JSON documents, their main reasons for creation being performance and flexibility. Unlike relational databases, which impose rigid structure with, NoSQL databases allow storing more arbitrary collections of data but often sacrifice data consistency and transactional guarantees. As such, NoSQL databases tend to be a good option for modern applications and development workflows that require a more flexible data model, as well as scale. Modern NoSQL databases make this an even better development by offering capabilities for flexibility and scale without giving up on ACID guarantees.

The need for NoSQL technology was generated primarily by major commercial applications (Twitter, Facebook, Amazon, Google, Yahoo, etc.) to meet unprecedented customer demand. NoSQL databases addressed common scaling headaches with more traditional SQL databases, often by focusing exclusively on a single data model (e.g. key-value databases for fast reads/writes at the cost of complex data).

Early NoSQL databases were developed with specific business logic/fulfillment in mind (e.g. storing global e-commerce state) at greater scale than SQL alternatives could handle, abandoning various SQL features in favor of speed. Unsurprisingly, this led to changes in design and implementation to compensate, as the need to model relational data hasn’t gone away. While early NoSQL solutions sacrificed transactions and (immediate) consistency, they delivered better performance, achieving the required scale and reliability.

Fast forward to today, and just about any sizable business uses NoSQL for at least a portion (if not the majority) of storage needs. Widespread adoption has led to accelerated maturation of the underlying tech, including new NoSQL databases that tackle previously under-served data models (e.g. tabular data). A wealth of different tools, along with documentation, education, and an increase in availability of experienced developers, means that leveraging NoSQL databases is easier and more productive than ever before.

The NoSQL family is diverse in its variety of data models, from key-value pairs, to row/column stores, and JSON documents to meet virtually any need. In addition, the majority of NoSQL databases neither require nor enforce strict schemas, enabling quicker and easier deployment of schema changes to production. Some NoSQL databases even accommodate multiple different data models for maximal flexibility.

Plenty of NoSQL databases are capable of distributing their work load over multiple instances, servers, nodes, etc. The ability to scale both horizontally and vertically is always a first-class feature with NoSQL databases. They can also be incredibly robust, using built-in protocols to continue operating when connections or nodes fail.

Because NoSQL databases are focused on fewer features and simpler data models, they typically outperform SQL databases to a significant degree. This specialization comes at the cost of “trying to do it all” but is a good tradeoff, given that most applications don’t utilize every database feature anyway, NoSQL or otherwise. It also accelerates NoSQL evolution insofar as developers have a smaller list of features to maintain and improve.

The functionality found in most NoSQL databases tends to be easier to leverage and integrate into applications, given the flexibility of data models and focus of purpose. This is particularly true for more modern architectural choices such as microservices, fully JavaScript web development, etc. As such, NoSQL databases accelerate software development compared to older technologies.

The gap in functionality between NoSQL and SQL databases can be reduced essentially to a few core features. The most significant are arguably (A) how relational data can be accomodated, (B) support for ACID-compliant transactions, and (C) a widely adopted query interface for advanced data manipulation.

Modern NoSQL databases like Fauna, now tackle the lack of relational data modeling as well as the widespread desire for ACID-compliant transactions. However, the first generation NoSQL solutions like MongoDB, retain these caveats.

Below are two common NoSQL data models along with SQL’s tabular data model. While SQL databases require pre-defining tables, columns, primary keys, and more, many NoSQL databases default to enforcing few to no such requirements. For example, a document database (loosely illustrated above) can store any arbitrary data in the form of JSON. This benefits agile development, as applications can iterate on their usage of data without issues caused by schema changes.

One of the sacrifices made in early NoSQL databases was support for ACID-compliant transactions, largely due to its complexity among distributed databases. Such transactions allow reliable manipulation of data across multiple tables or databases, ACID being an acronym for Atomic, Consistent, Isolated, and Durable. For example, a transaction might involve an e-commerce purchase in which the database transaction must fail if the quantity to be purchased exceeds available inventory. ACID-compliance ensures the transaction is completed (committed) or cancelled (rolled back) in a reliable way. In case of failure, the customer is not charged, no receipts or confirmations are sent, the product is never pulled for shipment, etc. Without the atomic guarantee, it would be possible for part of the process to occur while other parts do not; e.g., charging the customer but never giving a receipt or the product.

Further explanation of ACID is out of this article’s scope, but the point is that ACID-compliance is easier to achieve with a single database server or geographically small deployment. When struggling SQL databases (which had ACID-compliant transactions in many instances) were replaced with distributions of early NoSQL databases, full ACID-compliance was abandoned in favor of “eventual consistency”. Fortunately, advancements have been made over time leading to partial ACID-compliance among many NoSQL databases, along with a few providing full ACID-compliance.

NoSQL may never have a single, ubiquitous interface like SQL (as a language), but there are already several NoSQL databases offering advanced data manipulation via common nascent interfaces. For example, GraphQL has gained popularity among NoSQL databases, though it isn’t intended for the same power of which SQL is capable.

The most common types of NoSQL databases are document, key-value, wide-column, and graph databases. The following sections will explain them briefly.

As the name implies, document databases store collections of ‘documents’, which typically refers to hierarchical collections of data properties/values in a JSON format. Given their flexible and forgiving nature, document databases are suitable for a variety of applications. They are particularly approachable for novice engineers and well-suited for applications that require simple CRUD (Create, Read, Update, and Delete) operations.

Key-value databases offer the fastest operation of all NoSQL types of databases. They are suitable only for the simplest applications in which data is only created, read, and deleted—no complex updates allowed. For suitable use cases, key-value databases should be strongly considered as their speed and optimization are hard to beat.

Wide-column databases are similar to SQL in that they’re often designed with tables, columns, and rows. They offer excellent speed and scale by leveraging clever storage partitioning but often require more planning than other approaches, due to their reliance on developers specifying the layout/grouping of said partitions. Wide-column databases are best suited for applications that have extreme storage requirements.

Finally, graph databases are often used to supplement another database and excel in modeling relational data. While most relational databases can model only simple relationships with references or primary/foreign keys, graph databases utilize networks of “nodes”, connected with the use of “edges” to store significantly more complex (e.g., hierarchical) relationships.

A node is an entity while an edge is a relationship, both of which can usually store additional properties and data; enabling applications to describe “how” one entity relates to another, “in what way” two entities are related, and more. They bring immense optimization potential and open new doors for functionality when integrated with an application that utilizes any sort of network (e.g. social networks).

NoSQL’s rapid growth over the years, in both maturation and adoption, has led to what some may describe as a NoSQL renaissance. Multi-model databases, Fauna in particular, offer the flexibility and scale of NoSQL, along with the coveted relational and graph database functionality of SQL and others.

AWS’s DynamoDB provides applications with quick CRUD operations and classic NoSQL scale if implemented correctly; though Fauna excels in both areas by providing one of the fastest global transaction protocols in the industry, along with true hands-free serverless scale.

MongoDB, a database especially popular among beginners, continues to provide an excellent NoSQL experience with an easy-to-use document data model. Even easier, however, are the serverless options like Fauna, which also provides a similar data model to MongoDB’s, but with relational, graph, and temporal modeling as well.

Early NoSQL databases provided much-needed scale for the major players of the early internet. Today, databases like Fauna have only amplified that original value, providing more scale, flexibility, and state-of-the-art functionality, such as strong consistency among global distributions. Get started with Fauna by signing up for a free account and try it yourself.