What is a NoSQL Database?

A NoSQL database is a data management system that uses flexible data models to efficiently handle large volumes of unstructured and semi-structured data.

Unlike traditional relational databases, which impose rigid data structures, NoSQL databases allow storing more arbitrary collections of data. This makes NoSQL databases a good option for modern applications and development workflows that require a more flexible data model and scalability.

However, this flexibility often comes at the cost of consistency and transactional guarantees.

In this article, we’ll explain more about the NoSQL database model, its benefits and describe some more popular systems available today that can handle NoSQL and relational database use cases.

The relational database has been around since the 1970s, and while an excellent system to store data, it is weak when it comes to scaling horizontally and managing the diverse, unstructured, and semi-structured data types that are prevalent in today's big data and real-time web applications.

The tech giants of the last few decades (Microsoft, Facebook, Amazon, Google, etc.) drove the need for NoSQL database technology as they contended with unprecedented amounts of data generation and scale necessary to meet customer demands on their applications.

Early NoSQL databases (NoSQL stands for "Not Only SQL") 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 unstructured 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 non-relational databases, along with the coveted relational and graph database functionality of relational database management systems.

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 maintain the relational capabilities of traditional SQL databases and the strongest level of data consistency.

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 automatic distribution, an API delivery model, and a modern document-relational data model.

Fauna is the first document-relational database, offering the benefits of document/NoSQL and relational databases in a package that is attractive to developers. Like other document databases, data in Fauna is stored in JSON documents that are initially schemaless, providing flexibility in early application development as schema evolves. Later in application development, optional schema support (a feature that is currently in early alpha) allows developers to incrementally start enforcing the shape of data across groups of document collections.

Unlike other document databases, documents stored in Fauna can reference each other based on attributes, allowing developers to use arbitrarily complex joins in the database layer and eliminating the need for multiple round trips and custom join logic in application code. All requests execute in the context of a transaction, which means that the result is guaranteed to be consistent and up to date at the snapshot time of the request. Fauna’s novel architecture allows the database to be scalable and correct, offering strict serializability — the highest level of consistency guarantee — without compromising on performance.

All of this functionality is delivered via an API, which removes the burden of operating, upgrading, and scaling a database from developers. The API supports queries that are implemented in the Fauna Query Language (FQL), which is Turing Complete, so transactions can include effectively arbitrarily complex logic. To learn more about the design of Fauna’s Query Language, visit our blog.

Get started with Fauna by signing up for a free account and try it yourself.