What is NoSQL? Four Things, Actually


Posted on

nosql-textI’m almost certain the majority of you will have heard the term “NoSQL.” I’m sure many of you know exactly what it means, and some of you already use it in production! But for those who are unfamiliar–what is NoSQL? This is an overview of the many different options across four types of NoSQL databases.

NoSQL is a Database?

Yes, it is! But you knew that already, right? In the Database world, we have almost always been accustomed to a type of database known as a relational database. These include the very common MySQL, PostgreSQL, SQLite and MSSQL. In the relational database world, data is structured in a format that conforms to a predefined schema. The database schema is formed through columns and tables. If I were to tell you more about relational databases, I would go into the details of primary keys, inner joins, upper-left joins, etc. But this post is about NO SQL.

NoSQL as a term stands for exactly as it is spelled. It is a family of databases who do not conform to the SQL standard of data organisation and are a revolutionary form of data storage in modern web applications. Whereas SQL databases often have very rigid, inflexible data models made up of columns and tables, linked together through foreign keys, NoSQL databases often have no fixed schema whatsoever. For instance, in Document-orientated Databases, data is stored in document format i.e. JSON, and each record in the database could look entirely different to the last. I’ll go into details about document databases later.

So now we know roughly what the term NoSQL means; let’s take a look at some of the different types of NoSQL Databases.

Document-Orientated Databases

Document databases are a type of NoSQL database that store data in ‘documents.’ Each bit of data, such as a user record or commerce product, and stored in an individual document. These documents come in multiple formats ranging from HTML, XML and much more commonly JSON. Document databases often run in a Key-Value pattern, in which each document’s ID is the key; and the document body is the value. Querying document databases is often extremely time-efficient depending on how the database is architected. Many support a Map/Reduce ideology and use simple JavaScript to query data. Some even have fully HTTP/REST APIs.

Some databases included in the Document Database space are:

In-Memory Databases

In-memory databases are optimised for speed by storing and retrieving data from computer memory as opposed to fetching data from disk. Memory reads are well known to be faster than disk lookups, but many in-memory databases also now have disk-persistence. It would be the case that all data would be lost should a computer reset, but in-memory DBs get around this using modern methods such as replication, data snapshots and transaction logging. Most in-memory databases use key-value storage.

Some databases from the in-memory family are:

Graph Databases

Graph databases are exactly as the name says. Data is stored in graph structures and is optimised for fast querying and lookups. Graph databases, unlike other DBs, contain a storage pointer to their adjacent elements, and therefore no index lookups are necessary. Each item of data is referred to as a ‘Node’ and each node contains properties. The connections between each node are referred to as ‘Edges.’

Databases in the Graph Database category include:

Column Store Databases.

Column Store Databases defer from SQL databases, as instead of storing data tables in rows, they store data tables in a column format. The column-store approach has benefits when it comes to things like Ad-Hoc querying and aggregating data.

Databases belonging to the Column Store family include:

This post is indeed a brief overview of the types of NoSQL database. Later posts will take a deeper look into the various Databases, give examples on how and when to use them, and even take a look into what makes the databases so quick, how they’re made and the architectures of different databases.

In the meantime, you can start tinkering with a NoSQL database in another SendGrid blog post. My fellow evangelist Nick Quinlan showed how to store SendGrid Event data in Mongo using its REST API.

Post image via browniethoughts.com


SendGrid Devangelist. London based polyglot hacker, mainly playing with Golang and Ruby. Musical Hacker, Hardware hacker, Hackathon lover, API abuser and NoSQL user.

Robin Johnson on Twitter

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>