What Is NoSQL? Database Models Compared
Understand NoSQL database types: document, key-value, column-family, and graph. Learn when to choose NoSQL over relational and where MongoDB fits. Lesson 1 of the MongoDB & NoSQL Mastery course.
NoSQL does not mean "no SQL" — it means "not only SQL." The term covers a broad family of databases that reject the relational model's fixed schema and table structure in favour of data models better suited to specific access patterns. Understanding the landscape before choosing a database prevents the most expensive architectural mistake: picking the wrong storage engine for your workload.
Why NoSQL Emerged
Relational databases — PostgreSQL, MySQL, Oracle — have dominated data storage for four decades. They are excellent tools. But at web scale, three constraints become painful:
- Schema rigidity: every row must conform to a fixed schema; changing it requires a migration that locks tables
- Horizontal scaling: relational databases scale vertically (bigger servers) more easily than horizontally (more servers); sharding is complex and expensive
- Impedance mismatch: application objects — nested, polymorphic, variable-shape — must be decomposed into normalised tables and reassembled on every read
NoSQL databases trade some of the guarantees of the relational model (typically ACID across multiple tables) for flexibility, horizontal scalability, and a data model that matches how applications think about data.
The Four NoSQL Database Models
Document Databases
Documents are self-contained records expressed as JSON (or BSON in MongoDB's case). A document can contain nested objects and arrays — an entire order, with line items and shipping address, in a single record.
| Database | Notes |
|---|---|
| MongoDB | Most widely adopted; rich query language and aggregation pipeline |
| Couchbase | Built-in caching layer; SQL-like query language (N1QL) |
| Amazon DynamoDB | Managed AWS service; also supports key-value access patterns |
| Google Firestore | Serverless; tight integration with Firebase/GCP |
Best for: content management, product catalogues, user profiles, event logging, any workload where each record is naturally a self-contained object.
Key-Value Stores
The simplest model: a hash map. Each value is opaque — the database stores and retrieves it by key with no awareness of its structure.
| Database | Notes |
|---|---|
| Redis | In-memory; supports rich data structures (lists, sets, sorted sets, hashes) |
| Amazon DynamoDB | Supports key-value at massive scale with predictable single-digit millisecond latency |
| etcd | Distributed key-value store used by Kubernetes for cluster state |
Best for: session storage, caching, leaderboards, rate limiting, feature flags, real-time pub/sub.
Column-Family (Wide-Column) Stores
Data is stored by column rather than by row. Each row can have a different set of columns, and columns are grouped into families. Optimised for writes at massive scale and time-series data.
| Database | Notes |
|---|---|
| Apache Cassandra | Decentralised; no single point of failure; used by Netflix, Apple |
| Apache HBase | Hadoop ecosystem; modelled on Google Bigtable |
| Google Bigtable | Managed GCP service; petabyte scale |
Best for: IoT sensor data, time-series analytics, write-heavy workloads at massive scale, click-stream data.
Graph Databases
Data is modelled as nodes (entities) and edges (relationships). Traversing relationships is a first-class operation — far more efficient than recursive SQL joins.
| Database | Notes |
|---|---|
| Neo4j | Most mature graph database; Cypher query language |
| Amazon Neptune | Managed AWS service; supports Gremlin and SPARQL |
| ArangoDB | Multi-model: document + graph + key-value in one |
Best for: social networks, recommendation engines, fraud detection, knowledge graphs, identity and access management graphs.
NoSQL vs Relational: Choosing the Right Tool
| Criterion | Relational (PostgreSQL, MySQL) | NoSQL (MongoDB, Redis, etc.) |
|---|---|---|
| Schema | Fixed, enforced | Flexible, optional |
| Relationships | First-class (foreign keys, joins) | Application-managed or embedded |
| Transactions | Full ACID across many tables | Varies; MongoDB supports multi-document ACID since v4.0 |
| Scaling | Primarily vertical; horizontal is complex | Designed for horizontal sharding |
| Query language | SQL — powerful, standardised | Database-specific |
| Consistency | Strong by default | Configurable (eventual to strong) |
| Best fit | Financial records, ERP, normalised domains | Hierarchical data, high-write workloads, flexible schemas |
The real question is not "SQL or NoSQL" — it is "what are my access patterns?" Design your storage layer around how your application reads and writes data, not around how data is logically related in the abstract.
Where MongoDB Fits
MongoDB is a document database — the most versatile NoSQL model for general application development. It occupies the space between a pure key-value store (too simple for complex queries) and a relational database (too rigid for flexible schemas).
MongoDB's strengths:
- Rich query language: filter, project, sort, and paginate with a native query API
- Aggregation pipeline: multi-stage data transformation equivalent to SQL's
GROUP BY,HAVING, and window functions - Flexible schema: fields can be added without migrations; documents in the same collection can have different shapes
- Horizontal scaling: built-in sharding across multiple nodes
- ACID transactions: multi-document, multi-collection transactions since MongoDB 4.0
MongoDB's limitations:
- No cross-collection joins (use
$lookupin the aggregation pipeline — but it is expensive) - No enforced referential integrity between collections
- Memory usage is higher than column stores for analytical workloads
- Not ideal for highly relational data where many-to-many relationships dominate
ACID in NoSQL Context
A common misconception: NoSQL databases are not ACID-compliant. In reality, most modern NoSQL databases offer ACID guarantees at some level:
- MongoDB: ACID at the single-document level since v1.0; multi-document ACID transactions since v4.0
- DynamoDB: ACID at the single-item level; transactions available via TransactWriteItems
- Cassandra: Lightweight transactions (compare-and-set) via Paxos; eventual consistency by default
- Redis: Atomic operations on individual data structures; MULTI/EXEC for batched operations
For most application workloads, MongoDB's single-document ACID guarantee is sufficient — because a well-designed document schema embeds related data, eliminating the need for cross-document transactions.