Does NoSQL live up to the hype?

5 min readAug 13, 2018

Several years ago, non-relational, NoSQL databases began generating buzz as the tool that would allow web apps to scale while freeing web developers from some of the constraints posed by traditional relational databases. This post takes a look at the differences between relational databases and document databases, a popular variety of NoSQL database.

What‘s the difference between relational and document databases?

Oracle’s headquarters in Redwood Shores, California. Oracle is the top ranking database management system. Photo by Tim Dobbelaere | CC BY-SA 2.0

Relational Databases

Traditional relational databases are organized into tables with rows and columns and are queried with SQL. Relational databases emphasize the relationships between the tables. For example, a relational database for an e-commerce site might include a table of customers with columns for first name, last name and email address. Each rows pertains to just one customer. Purchases would be stored in a different table that has columns for the item, price and date purchased. Purchases would be linked to the appropriate customers by including the customers’ id foreign keys in the purchases table. If you wanted to display a customer’s information along with all of his or her purchases you would need to use a query to join the tables together.

Sample customer and purchase tables for a relational database

The top 5 relational database management systems in August 2018 include Oracle, MySQL, Microsoft SQL Server, PostgreSQL and DB2 as ranked by DB-Engines Ranking.

Note: PostgreSQL is an object-relational database: it is like a relational database but has support for objects, classes and inheritance. You can think of it as a relational style database with some non-relational features or as a hybrid.

Document databases

Not too surprisingly, a document database stores data as documents within collections. Collections correspond to tables in a traditional database, while the documents correspond to rows. The data inside each document is considered semi-structured. Each document is searchable, but the internal structure may vary between documents within the same collection. For our hypothetical retailer, each document might contain one customer including all of his or her purchases.

Example JSON Document for an e-commerce store

{
    'id' : 1,
    'firstName' : { 'Charlie' },
    'lastName' : { 'Brown' },
    'email' : { 'cbrown@email.com' },
    'Purchases' : [
        {
            'item' : 'shoes',
            'price' : 50,
            'date' : '3/20/1985'
        }, {
            'item' : 'belt',
            'price' : 25,
            'date' : '5/23/1990'
        }
    ]
}

When data is stored as JSON, as in the above example, JavaScript developers don’t need to take the extra step of transforming the data into an object before manipulating it. This makes app development a bit easier. Popular document databases include MongoDB, CouchDB, Amazon DynamoDB and Firebase Realtime Database.

Why choose one type of database over the other?

Consider a document database when several of the following are true

Speed is the priority — Storing all the data for a specific item inside one document makes data retrieval super fast
Relationships are less important — These databases work best for storing large amounts of data that is not tightly intertwined
The app will grow very large — Document databases may be spread over multiple computers allowing them to scale horizontally to meet the needs of even the biggest applications.
You are prototyping a new app — Because document store databases are schemaless, the database can evolve alongside the app throughout the development process.

Stick with a relational database when

in doubt — Unless you have a specific need for a NoSQL database, relational databases are usually the safer bet.
There’s value in the relationships — Relational databases allow you to easily work with connections within your data without creating duplicate copies.
Data must always be up to date — Most traditional relational databases guarantee consistency throughout the database. Many NoSQL databases instead use a model of eventual consistency in order to prioritize speed.

Pick the Right Tool(s) for the Job

SQL and NoSQL databases excel at different things; the key is to understand the data needs of a specific project and find the right tool for it. Sometimes that might mean using both relational and non-relational databases in the same application or utilizing a hybrid solution like PostgreSQL.

By Mark Madsen from his lecture “Perception is Key” at the 2013 Strata Conference in London

An example

Recently I had the opportunity to use Firebase Realtime Database, a document store database, during a four day Hackathon. The core feature of my app allowed users to take photos that were then displayed on a map. I chose Firebase Realtime Database because it integrated with other Firebase products in my project and because my data was pretty flat. It consisted of one collection of documents each with a link to a photograph and some information about the corresponding location. Because of the quick turnaround time for this project, I appreciated being able to dive right in without having to explicitly plan out schemas for the database. If I were to really scale up this app, it might also benefit from the speed of the Realtime Database. However, while Firebase was a good choice for the prototype, if I develop this app further I might consider switching to a PostgreSQL database to better handle the relationships between users, photographs and comments.

TL;DR

Non-relational databases are not right for every application (or even most), but they power the web to provide data in quantities and at speeds that would not be possible with relational databases alone.