You now have the option to develop your application with or without SQL database. What is NoSQL programming?

What is NoSQL? NoSQL is a class of DBMs that are non-relational and generally do not use SQL database. SQL is the programming language used to interface with relational databases, as records in rows and tables with logical links between the rows and tables.

One of the most fundamental choices to make when developing an application is whether to use a SQL or NoSQL database to store the data. Conventional databases, meaning relational databases that use SQL (Structured Query Language) for queries, are the product of decades of technological evolution, good practice, and real-world stress testing. They are designed for reliable transactions and ad hoc queries, the staples of line-of-business applications. But they also come burdened with restrictions, such as rigid schema, that make them less suitable for other kinds of applications.

One of the most fundamental choices to make when developing an application is whether to use a SQL or NoSQL database to store the data. Conventional databases, meaning relational databases that use SQL (Structured Query Language) for queries, are the product of decades of technological evolution, good practice, and real-world stress testing. They are designed for reliable transactions and ad hoc queries, the staples of line-of-business applications. But they also come burdened with restrictions, such as rigid schema, that make them less suitable for other kinds of applications.

NoSQL databases arose in response to those limitations. NoSQL systems store and manage data in ways that allow for high operational speed and great flexibility on the part of the developers. Many were developed by companies like Google, Amazon, Yahoo, and Facebook that sought better ways to store content or process data for massive websites. Unlike SQL databases, many NoSQL databases can be scaled horizontally across hundreds or thousands of servers.

The advantages of NoSQL don’t come without a cost, though. NoSQL systems favor speed and scalability over the ACID properties behind reliable transactions promised by SQL databases. And the metaphors used to work with data in NoSQL systems are also relatively new, compared to the decades of institutional knowledge built up around SQL.

SQL and NoSQL databases offer different tradeoffs. While they may compete in the context of a specific project—as in, which to choose for this application or that application—they are complementary in the bigger picture. Each is suited to different use cases. The decision is not so much a case of either/or as it is a question of which tool is right for the job.

NoSQL vs. SQL

The fundamental difference between SQL and NoSQL is not all that complicated. Each has a different philosophy for how data should be stored and retrieved.

With SQL databases, all data has an inherent structure. A conventional database like Microsoft SQL Server, MySQL, PostgreSQL, or Oracle Database uses a schema—a formal definition of how data inserted into the database will be composed. For instance, a certain column in a table may be restricted to integers only. As a result, the data recorded in the column will have a high degree of normalization. The rigid schema of a SQL database also makes it relatively easy to perform aggregations on the data, for instance by combining data from two tables using the SQL JOIN command.

With NoSQL, data can be stored in a schema-less or free-form fashion. Any data can be stored in any record. Among the NoSQL databases, you will find four common models for storing data, which lead to four common types of NoSQL systems:

Document databases (e.g. MongoDB). Inserted data is stored in the form of schema-less JSON structures, or “documents,” where the data could be anything from integers to strings to free-form text. There is no inherent need to specify what fields, if any, a JSON document will contain.

Key-value stores (e.g. Redis). Free-form values, from simple integers or strings to complex JSON documents, are accessed in the database by way of keys, such as strings.

Wide column stores (e.g. Cassandra). Data is stored in columns instead of rows as in a conventional SQL system. Any number of columns (and therefore many different types of data) can be grouped or aggregated as needed for queries or data views.

Graph databases (e.g. Neo4j). Data is represented as a network or graph of entities and their relationships, where each node in the graph is a free-form chunk of data.

Schema-less data storage is useful in the following scenarios:

You want fast access to the data, and you’re more concerned with speed and simplicity of access than reliable transactions or consistency.

You’re storing a large volume of data, and you don’t want to lock yourself into a schema, as changing the schema later could be slow and painful.

You’re taking in unstructured data from one or more sources, and you want to keep the data in its original form for maximum flexibility.

You want to store data in a hierarchical structure, but you want those hierarchies to be described by the data itself, not an external schema. NoSQL allows data to be casually self-referential in ways that are more complex for SQL databases to emulate.

Querying NoSQL databases

The Structured Query Language used by relational databases provides a uniform way to communicate with the server when storing and retrieving data. SQL syntax is highly standardized, so while individual databases may handle certain operations differently (e.g., window functions), the basics remain the same.

By contrast, each NoSQL database tends to have its own syntax for querying and managing the data. CouchDB, for instance, uses requests in the form of JSON, sent via HTTP, to create or retrieve documents from its database. MongoDB sends JSON objects over a binary protocol, by way of a command-line interface or a language library.

Some NoSQL products can use SQL-like syntax to work with data, but only to a limited extent. For example, Apache Cassandra, a wide column store, has its own SQL-like language, the Cassandra Query Language or CQL. Some of the CQL syntax is straight out of the SQL playbook, like the SELECT or INSERT keywords. But there is no native way to perform a JOIN or subquery in Cassandra, and thus the related keywords don’t exist in CQL.