What is a NoSQL database?

There are five main types of NoSQL databases: 

Document databases, also called document-oriented databases or a document store, are used to store and query semi-structured data. Data is stored in a JSON-like document similar to the data objects that developers use in application code, making it easier to create and update applications without referencing a primary schema. Document databases are most commonly used for blogging platforms, ecommerce, real-time analytics, and content management systems.

Key-value databases, also referred to as key-value stores, are the simplest type of NoSQL databases. Data is stored in a “key-value” structure, where a unique key is paired with a value such as a string, number, boolean, or complex objects. You can use the key to store or retrieve its associated value. Key-value stores are most commonly used for user preferences, shopping carts, and user profiles in web applications.

Column-oriented databases, or wide-column stores, store and read data in rows and are organized as a set of columns. While similar to the tabular format of relational databases, column names and formatting in wide-column stores can vary from row to row in a single table. They are optimal for analytics use cases, where you may need to query across specific columns in a database and aggregate the value of a given column quickly. Wide-column stores are most commonly used for catalogs, fraud detection, and recommendation engines.

Graph databases organize data as nodes in a graph, focusing on the relationships between data elements. The connections between nodes (edges) are stored as first-class elements, enabling richer representations of data relationships while offering more simplified storage and navigation. Graph databases are most commonly used in systems that map relationships, including social media platforms, reservation systems, fraud detection systems, and logistics applications.

In-memory databases store data in memory in order to provide ultra-low latency for real-time applications. Redis and Valkey are examples of in-memory NoSQL databases. In-memory databases are most commonly used for caching, messaging, streaming, and real-time analytics.

NoSQL features are unique to the database you choose. However, they typically share several similar high-level qualities: 

• They follow flexible schemas that don’t require you to determine or declare a fixed schema for your data, making them ideal for semi-structured and unstructured data
• They scale horizontally, using range or hash distributions, instead of having to depend on vertical scaling to add capacity
• They’re optimized for specific data models and workload patterns, such as key-value, wide-column, or in-memory
• They often exhibit consistency at some later point (for example, eventual consistency model) rather than following the stricter ACID (atomicity, consistency, isolation, durability) properties of relational and SQL databases
• They usually don't support cross-shard transactions or flexible isolation modes

These features make non-relational databases ideal for applications that require large scale, reliability, high availability, and frequent data changes.

While NoSQL databases have gained huge popularity in recent years, there are some drawbacks to using them over relational databases. They are still relatively new and may lack the maturity of relational databases. Overall, NoSQL comes with less developer expertise, fewer available tools and products, and less support should undocumented issues arise. 

In addition, NoSQL has no lingua franca like SQL—each database may have its own language for querying and managing data. These languages are often similar but not fully compatible with the SQL standard.

In many cases, NoSQL databases lack the data integrity safeguards and high level of data consistency that are standard in SQL databases. However, there are some, like Firestore and MongoDB Atlas, that do support ACID transactions.

NoSQL databases usually aren’t a good choice for applications that run complex queries and joins. Managing indexes and queries across multiple nodes would be slow and may not return consistent results.

Still, eventual consistency models are sufficient for most NoSQL use cases, where a small millisecond delay doesn’t matter. For many applications, high availability and speed far outweighs the need for strong global consistency. 

So why do organizations use non-relational NoSQL databases for some applications but stick with relational SQL databases for others? Picking the right database often comes down to your use case. Here’s when to use SQL vs NoSQL.

SQL databases excel in managing structured, relational data and complex queries. SQL databases are ACID-compliant, making them suitable for transactional information.

SQL use cases:

• Financial transactions
• Healthcare data analysis 
• Customer and transaction information

NoSQL databases excel in use cases that require large numbers of globally distributed users to deliver highly personalized experiences. These interactive applications are best served with the agility of NoSQL databases. 

NoSQL databases prioritize high availability, deliver consistent performance, scale out quickly without downtime, and can handle large volumes of different types of data. 

These features of NoSQL databases make non-relational databases ideal for applications that require large scale, reliability, and high availability.

The most common NoSQL uses include: 

• Mobile, web, and IoT applications
• Real-time web applications
• Personalization, recommendations, and real-time customer experiences
• Inventory and catalog management
• Fraud detection and identity authentication 
• Ad tech