NoSQL Database

What is NoSQL?

NoSQL ("Not Only SQL") databases are non-relational database systems designed for large-scale data storage, flexible schemas, and high-performance access patterns. They emerged to address limitations of traditional relational databases when dealing with internet-scale applications, rapidly evolving data models, and massive horizontal scaling requirements.

Example

Traditional SQL: Structured tables, rigid schema, ACID, vertical scaling NoSQL: Flexible schema, BASE properties, horizontal scaling, high throughput

NoSQL does not mean "no SQL" — it means "not only SQL." Many NoSQL systems now support SQL-like query languages alongside their native APIs.

Types of NoSQL Databases

1. Key-Value Stores

The simplest model: each record is a (key, value) pair — like a giant hash map.

"user	1001" -> { "name": "Alice", "age": 25, "city": "Delhi" }
"session	abc123" -> { "expires": 1700000000, "user_id": 1001 }
"cart	1001" -> ["ProductA", "ProductB", "ProductC"]
Operations	GET(key), PUT(key, value), DELETE(key)
Strengths	Extremely fast (sub-millisecond), simple API
Weaknesses	No complex queries, no joins, value is opaque
Use cases	Caching, session management, shopping carts, leaderboards
Examples	Redis, Amazon DynamoDB, Memcached, Riak

2. Document Stores

Store data as semi-structured documents (typically JSON/BSON). Documents can have nested structures, arrays, and varying fields.

Example

// MongoDB document in "students" collection: { "_id": ObjectId("64a1b2c3d4e5f6..."), "name": "Alice", "age": 21, "department": "Computer Science", "courses": [ { "code": "CS101", "grade": "A" }, { "code": "CS201", "grade": "B+" } ], "address": { "city": "Delhi", "pin": "110001" } } // Another document in same collection (DIFFERENT structure -- that is OK!): { "_id": ObjectId("64a1b2c3d4e5f7..."), "name": "Bob", "age": 22, "department": "Physics", "publications": ["Paper1", "Paper2"] // field not in Alice's document }

Strengths	Flexible schema, natural JSON mapping for web apps, rich queries
Weaknesses	No joins (must denormalize), potential data inconsistency
Use cases	Content management, user profiles, catalogs, real-time analytics
Examples	MongoDB, CouchDB, Amazon DocumentDB, Firebase Firestore

3. Column-Family Stores

Data organized by columns rather than rows. Each row can have different columns, and columns are grouped into "families."

Row Key	"user:1001"
Column Family "personal"	{name: "Alice", age: 25, city: "Delhi"}
Column Family "academic"	{gpa: 3.8, major: "CS", year: 4}
Row Key	"user:1002"
Column Family "personal"	{name: "Bob", age: 22}
Column Family "academic"	{gpa: 3.2, major: "Physics"}
Column Family "work"	{company: "Google", role: "Intern"}

Strengths	Excellent for wide, sparse data; fast column-based aggregations
Weaknesses	Complex data model, limited query flexibility
Use cases	Time-series data, analytics, IoT sensor data, event logging
Examples	Apache Cassandra, HBase, Google Bigtable, ScyllaDB

4. Graph Databases

Data stored as nodes (entities) and edges (relationships). Optimized for traversing relationships.

Nodes

(Alice:Person {age:25})

(Bob:Person {age:22})

(DBMS:Course {credits:4})

Edges

(Alice)-[:FRIENDS_WITH]->(Bob)

(Alice)-[:ENROLLED_IN {grade:"A"}]->(DBMS)

(Bob)-[:ENROLLED_IN {grade:"B+"}]->(DBMS)

Query (Cypher - Neo4j)

MATCH (p:Person)-[:FRIENDS_WITH]->(f:Person)-[:ENROLLED_IN]->(c:Course)

WHERE p.name = "Alice"

RETURN f.name, c.name

// Find courses that Alice's friends are taking

Strengths	Fast relationship traversal, intuitive for connected data
Weaknesses	Not suited for bulk analytics, scaling can be challenging
Use cases	Social networks, recommendation engines, fraud detection, knowledge graphs
Examples	Neo4j, Amazon Neptune, JanusGraph, ArangoDB

SQL vs. NoSQL — Comparison

Feature	SQL (RDBMS)	NoSQL
Schema	Fixed (predefined)	Flexible (schema-on-read)
Scaling	Vertical (scale up)	Horizontal (scale out)
Transactions	Full ACID	BASE (eventual consistency typical)
Query language	SQL (standardized)	Varies by database
Joins	Native support	Generally avoided (denormalize instead)
Data model	Tables with rows/columns	Documents, key-value, columns, graphs
Best for	Complex queries, transactions	High scale, flexible data, speed
Examples	MySQL, PostgreSQL, Oracle	MongoDB, Redis, Cassandra, Neo4j

BASE Properties (vs. ACID)

NoSQL systems often follow BASE instead of ACID:

Property	Meaning
Basically Available	System guarantees availability (responds to every request)
Soft State	Data may be temporarily inconsistent across nodes
Eventually Consistent	Given time without updates, all replicas converge to same value

CAP Theorem

The CAP theorem states that a distributed system can guarantee only TWO of three properties simultaneously:

C - Consistency	Every read receives the most recent write
A - Availability	Every request receives a response (no timeouts)
P - Partition Tolerance	System continues despite network partitions
CP (Consistency + Partition Tolerance)	MongoDB, HBase
AP (Availability + Partition Tolerance)	Cassandra, DynamoDB
CA (Consistency + Availability)	Traditional RDBMS (single node, no partitions)

When to Use NoSQL vs. SQL

Use NoSQL When	Use SQL When
Schema evolves frequently	Schema is well-defined and stable
Massive scale (millions of ops/sec)	Moderate scale with complex queries
Data is hierarchical or graph-shaped	Data is naturally tabular
High availability is paramount	Strong consistency is mandatory
Development speed matters	Data integrity is critical (banking, healthcare)

In practice, many modern applications use both — SQL for transactional core data and NoSQL for caching, session management, search, or analytics (polyglot persistence).

What is NoSQL?

Example

Traditional SQL: Structured tables, rigid schema, ACID, vertical scaling NoSQL: Flexible schema, BASE properties, horizontal scaling, high throughput

NoSQL does not mean "no SQL" — it means "not only SQL." Many NoSQL systems now support SQL-like query languages alongside their native APIs.

Types of NoSQL Databases

1. Key-Value Stores

The simplest model: each record is a (key, value) pair — like a giant hash map.

"user	1001" -> { "name": "Alice", "age": 25, "city": "Delhi" }
"session	abc123" -> { "expires": 1700000000, "user_id": 1001 }
"cart	1001" -> ["ProductA", "ProductB", "ProductC"]
Operations	GET(key), PUT(key, value), DELETE(key)
Strengths	Extremely fast (sub-millisecond), simple API
Weaknesses	No complex queries, no joins, value is opaque
Use cases	Caching, session management, shopping carts, leaderboards
Examples	Redis, Amazon DynamoDB, Memcached, Riak

2. Document Stores

Store data as semi-structured documents (typically JSON/BSON). Documents can have nested structures, arrays, and varying fields.

Example

Strengths	Flexible schema, natural JSON mapping for web apps, rich queries
Weaknesses	No joins (must denormalize), potential data inconsistency
Use cases	Content management, user profiles, catalogs, real-time analytics
Examples	MongoDB, CouchDB, Amazon DocumentDB, Firebase Firestore

3. Column-Family Stores

Data organized by columns rather than rows. Each row can have different columns, and columns are grouped into "families."

Row Key	"user:1001"
Column Family "personal"	{name: "Alice", age: 25, city: "Delhi"}
Column Family "academic"	{gpa: 3.8, major: "CS", year: 4}
Row Key	"user:1002"
Column Family "personal"	{name: "Bob", age: 22}
Column Family "academic"	{gpa: 3.2, major: "Physics"}
Column Family "work"	{company: "Google", role: "Intern"}

Strengths	Excellent for wide, sparse data; fast column-based aggregations
Weaknesses	Complex data model, limited query flexibility
Use cases	Time-series data, analytics, IoT sensor data, event logging
Examples	Apache Cassandra, HBase, Google Bigtable, ScyllaDB

4. Graph Databases

Data stored as nodes (entities) and edges (relationships). Optimized for traversing relationships.

Nodes

(Alice:Person {age:25})

(Bob:Person {age:22})

(DBMS:Course {credits:4})

Edges

(Alice)-[:FRIENDS_WITH]->(Bob)

(Alice)-[:ENROLLED_IN {grade:"A"}]->(DBMS)

(Bob)-[:ENROLLED_IN {grade:"B+"}]->(DBMS)

Query (Cypher - Neo4j)

MATCH (p:Person)-[:FRIENDS_WITH]->(f:Person)-[:ENROLLED_IN]->(c:Course)

WHERE p.name = "Alice"

RETURN f.name, c.name

// Find courses that Alice's friends are taking

Strengths	Fast relationship traversal, intuitive for connected data
Weaknesses	Not suited for bulk analytics, scaling can be challenging
Use cases	Social networks, recommendation engines, fraud detection, knowledge graphs
Examples	Neo4j, Amazon Neptune, JanusGraph, ArangoDB

SQL vs. NoSQL — Comparison

Feature	SQL (RDBMS)	NoSQL
Schema	Fixed (predefined)	Flexible (schema-on-read)
Scaling	Vertical (scale up)	Horizontal (scale out)
Transactions	Full ACID	BASE (eventual consistency typical)
Query language	SQL (standardized)	Varies by database
Joins	Native support	Generally avoided (denormalize instead)
Data model	Tables with rows/columns	Documents, key-value, columns, graphs
Best for	Complex queries, transactions	High scale, flexible data, speed
Examples	MySQL, PostgreSQL, Oracle	MongoDB, Redis, Cassandra, Neo4j

BASE Properties (vs. ACID)

NoSQL systems often follow BASE instead of ACID:

Property	Meaning
Basically Available	System guarantees availability (responds to every request)
Soft State	Data may be temporarily inconsistent across nodes
Eventually Consistent	Given time without updates, all replicas converge to same value

CAP Theorem

The CAP theorem states that a distributed system can guarantee only TWO of three properties simultaneously:

C - Consistency	Every read receives the most recent write
A - Availability	Every request receives a response (no timeouts)
P - Partition Tolerance	System continues despite network partitions
CP (Consistency + Partition Tolerance)	MongoDB, HBase
AP (Availability + Partition Tolerance)	Cassandra, DynamoDB
CA (Consistency + Availability)	Traditional RDBMS (single node, no partitions)

When to Use NoSQL vs. SQL

Use NoSQL When	Use SQL When
Schema evolves frequently	Schema is well-defined and stable
Massive scale (millions of ops/sec)	Moderate scale with complex queries
Data is hierarchical or graph-shaped	Data is naturally tabular
High availability is paramount	Strong consistency is mandatory
Development speed matters	Data integrity is critical (banking, healthcare)

In practice, many modern applications use both — SQL for transactional core data and NoSQL for caching, session management, search, or analytics (polyglot persistence).

NoSQL Database

What is NoSQL?

Types of NoSQL Databases

1. Key-Value Stores

2. Document Stores

3. Column-Family Stores

4. Graph Databases

Nodes

Edges

Query (Cypher - Neo4j)

SQL vs. NoSQL — Comparison

BASE Properties (vs. ACID)

CAP Theorem

When to Use NoSQL vs. SQL

Study next in this module

NoSQL Database

What is NoSQL?

Types of NoSQL Databases

1. Key-Value Stores

2. Document Stores

3. Column-Family Stores

4. Graph Databases

Nodes

Edges

Query (Cypher - Neo4j)

SQL vs. NoSQL — Comparison

BASE Properties (vs. ACID)

CAP Theorem

When to Use NoSQL vs. SQL

Study next in this module