NoSQL databases, as the name suggests, do not follow relational patterns. NoSQL databases store data as JavaScript Object Notation (JSON) documents, which are hierarchical in structure. This means that related information such as an address can be stored with the primary record but embedded as a child object. Embedding data can also be used for multiple related records; for example, multiple addresses can be stored within the primary record.
With this in mind, a typical NoSQL JSON document might look like this:
{
“id”: “001”,
“firstName”: “Brett”,
“surname”: “Hargreaves”,
“category”: “Active”,
“addresses”: [
{
“type”: “billing”,
“street”: “999 Letsbe Avenue”,
“city”: “London”
},
{
“type”: “shipping”,
“street”: “20 Docklands Road”,
“city”: “London”
}
]
}
NoSQL databases can perform much faster than their SQL counterparts for specific scenarios, manage far greater volumes of data, and are considerably more scalable.
Another benefit is that you can easily mix records of completely different schemas.
For example, a container, which is synonymous to a table in SQL parlance, might contain the following records—and this would be perfectly valid:
[
{
“id”: “001”,
“firstName”: “Brett”,
“Surname”: “Hargreaves”,
“category”: “Active”,
},
{
“id”: “002”,
“title”: “Microsoft Azure Architect Design – AZ-304 Certification & Beyond”,
“publisher”: “Packt Publishing”,
}
]

The mixing of completely different record types, as in the prior example, would not be recommended. But it highlights the ability to have a flexible schema, which is immensely powerful, especially for applications built in an Agile manner.

Because a data schema in NoSQL does not need to be defined upfront, systems can be built interactively over time, adding to the data structure more easily.

Another benefit of a flexible schema is that your applications can be more dynamic. For example, in a Human Resources (HR) system that stores employee data, any requirement to add new fields to the employee record would typically need to be performed by a developer. The developer would need to change the database schema and update their code to take this change into account.

With a NoSQL schema, the system could be designed so that the data structure itself could be defined as a record. As new fields are required, the schema is updated within the definition record, and that additional piece of information starts getting stored in the primary collection. No redevelopment or database schema changes are required, and no downtime is necessary to update the system.

Flexibility can, of course, have its downside too. More programming effort is required to enforce data integrity, ensuring only certain types of data can be added.

With this in mind, SQL can be a better choice over NoSQL if a well-defined structure is essential or if a mistake that led to inconsistent data might be dangerous.

SQL can also be faster for multi-record updates—for example, if you must regularly update rows in large batches.

Now that we understand SQL and NoSQL, we will look in more detail at the differences between Azure SQL and Cosmos DB.