Skip to main content
Different jobs require different tools. In real-world systems it’s common to combine database types, selecting the right tool for each workload. This article compares relational and non-relational (NoSQL) databases, explains their core trade-offs, and shows a practical MongoDB CRUD demo that mirrors typical SQL workflows. NoSQL databases generally fall into four families: document, key-value, column, and graph. Each family targets different data shapes and access patterns. Table of contents
  • Comparison summary (analogy: library vs filing cabinet)
  • Structure, integrity, performance, and scale (with visual aids)
  • Quick pop quiz
  • MongoDB CRUD demo (Create, Read, Update, Delete)
  • Summary and key takeaways
  • Links and references
Why this matters (quick primer)
  • Relational databases: well-defined schemas, ACID guarantees, great for accuracy and complex transactions.
  • NoSQL databases: schema-flexible, often designed for horizontal scale and simple high-volume operations.
  • Choosing the right database depends on data shape, access patterns, and consistency requirements.
NoSQL families at a glance
FamilyDescriptionCommon use casesExamples
DocumentStores semi-structured JSON-like documents; each record can have varying fieldsContent management, user profiles, event logsMongoDB, Couchbase
Key-valueSimple mapping from key -> value (opaque values)Caching, session stores, feature flagsRedis, DynamoDB (in some patterns)
ColumnWide-column stores optimized for large-scale writes and reads across columnsTime-series, analytics, IoTApache Cassandra, ScyllaDB
GraphStores nodes and edges to represent relationships directlySocial graphs, fraud detection, recommendationsNeo4j, Amazon Neptune
Analogy: library (relational) vs filing cabinet (NoSQL)
  • Library (relational): every book follows the same catalog — title, author, ISBN, subject — placed on the correct shelf. That predictable catalog is a schema (tables, columns, data types).
  • Filing cabinet (NoSQL): drawers can be organized independently; each folder may contain different fields. You can add new fields without redesigning the entire system.
Structure
  • Libraries are predictable and consistent; schemas enforce the shape of data before it’s stored.
  • Filing cabinets (documents, key-value, etc.) are flexible, allowing varied records and easy schema evolution.
Why it matters: fixed schemas are ideal for predictable data (e.g., invoices). Schema flexibility works best for evolving data models (e.g., user-generated content). Data integrity
  • Libraries have librarians who enforce uniqueness and cross-references — analogous to relational constraints (primary keys, foreign keys, data types).
  • Filing cabinets can accept diverse entries quickly and reconcile them later — many NoSQL systems favor eventual consistency for higher write throughput.
Why it matters: strong consistency and constraints are essential when correctness matters (banking). Eventual consistency is often acceptable for social feeds or tag systems.
The image compares relational and non-relational databases using visual metaphors of a city library and a cabinet, highlighting aspects such as structure, integrity, performance, and scale. There's a person wearing a KodeKloud shirt speaking.
Performance
  • Libraries are optimized for deep research and complex cross-references — similar to SQL queries and joins across multiple normalized tables.
  • Filing cabinets can be faster for simple lookups when related data is stored together; many NoSQL systems store denormalized records for quick reads.
Why it matters: relational systems typically excel at analytical queries; NoSQL often outperforms for high-throughput key lookups and simple read/write operations.
The image compares relational and non-relational databases, highlighting features like schema structure, consistency, and scalability. It includes illustrations of a city library and a cabinet to represent each database type.
Scale
  • Vertical scaling (adding CPU, RAM) is like enlarging a library building — effective but expensive and finite.
  • Horizontal scaling (adding more cabinets/machines) is often simpler for NoSQL systems; many are built to shard and replicate across nodes.
Why it matters: NoSQL solutions typically simplify horizontal scaling for very large ingest rates and distributed workloads (e-commerce catalogs, streaming events).
The image compares relational and non-relational databases, illustrating differences in structure, integrity, performance, and scalability, with an explanation from a person in a KodeKloud shirt.
Which is better?
  • There is no universally “better” choice. Use relational databases when data integrity and complex transactions are critical. Use NoSQL when flexibility, massive scale, or specialized access patterns are more important.
  • Hybrid architectures are common: relational systems for core transactional data and NoSQL for flexible or high-throughput services.
Pop quiz Which statement is true? A. NoSQL databases are always faster than relational databases.
B. Relational databases require a fixed schema.
C. Graph databases store data in rows and columns. Answer: B is correct. Relational databases typically use a fixed schema (tables, columns, and data types are defined before storing data). Why the others are false:
  • A is false: NoSQL can be faster for simple operations, but relational databases may outperform for complex queries.
  • C is false: Graph databases use nodes and edges, not rows and columns.
From MySQL to MongoDB — same CRUD, different shape Below is a MongoDB demo that mirrors typical SQL CRUD operations. MongoDB stores flexible, JSON-like documents and returns JSON-style responses in the shell. Connect to mongosh and create a miaowtube database with users and videos collections: 
bob@mongodb-host ~ % mongosh --authenticationDatabase "admin" -u "myUserAdmin" -p
Enter password: ********
Current Mongosh Log ID: 688ca1c3d12a696511d6795
Connecting to: mongodb://<credentials>@127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&authSource=admin&appName=mongosh+1.4.2
Using MongoDB: 5.0.8
Using Mongosh: 1.4.2

> use miaowtube
switched to db miaowtube

> db.createCollection("users");
{ ok: 1 }

> db.createCollection("videos");
{ ok: 1 }

> show collections
users
videos
MongoDB collections are schema-flexible by default. You can enforce validation rules if you need stricter structure, but it’s optional and can be applied incrementally.
Create (insert) users Insert two user documents. We add a numeric user_id to mimic a conventional primary-key reference: 
miaowtube> db.users.insertMany([
  { user_id: 1, username: "fluffy", email: "fluffy@email.com" },
  { user_id: 2, username: "paws",  email: "paws@email.com" }
]);
{
  acknowledged: true,
  insertedIds: {
    '0': ObjectId("688ca2030aad588906929b1f"),
    '1': ObjectId("688ca2030aad588906929b2f")
  }
}
Read users Verify the inserted documents: 
miaowtube> db.users.find({});
[
  {
    _id: ObjectId("688ca2030aad588906929b1f"),
    user_id: 1,
    username: "fluffy",
    email: "fluffy@email.com"
  },
  {
    _id: ObjectId("688ca2030aad588906929b2f"),
    user_id: 2,
    username: "paws",
    email: "paws@email.com"
  }
]
Create videos Insert three videos, each referencing user_id: 
miaowtube> db.videos.insertMany([
  { user_id: 1, title: "Cat Skateboard",  link: "www.miaowtube/watch1", upload_date: "2025-05-25" },
  { user_id: 2, title: "Epic Cat Jump",   link: "www.miaowtube/watch2", upload_date: "2025-05-27" },
  { user_id: 1, title: "Cat vs Curtain",   link: "www.miaowtube/watch3", upload_date: "2025-05-29" }
]);
{
  acknowledged: true,
  insertedIds: {
    '0': ObjectId("688ca2310aad588906929b3f"),
    '1': ObjectId("688ca2310aad588906929b4f"),
    '2': ObjectId("688ca2310aad588906929b5f")
  }
}
Read videos (full documents) List all videos: 
miaowtube> db.videos.find({});
[
  {
    _id: ObjectId("688ca2310aad588906929b3f"),
    user_id: 1,
    title: "Cat Skateboard",
    link: "www.miaowtube/watch1",
    upload_date: "2025-05-25"
  },
  {
    _id: ObjectId("688ca2310aad588906929b4f"),
    user_id: 2,
    title: "Epic Cat Jump",
    link: "www.miaowtube/watch2",
    upload_date: "2025-05-27"
  },
  {
    _id: ObjectId("688ca2310aad588906929b5f"),
    user_id: 1,
    title: "Cat vs Curtain",
    link: "www.miaowtube/watch3",
    upload_date: "2025-05-29"
  }
]
Read videos (projection) Request only titles using a projection: 
miaowtube> db.videos.find({}, { title: 1, _id: 0 });
[
  { title: "Cat Skateboard" },
  { title: "Epic Cat Jump" },
  { title: "Cat vs Curtain" }
]
Update Rename “Cat Skateboard” -> “Flufferson on Skateboard”: 
miaowtube> db.videos.updateOne(
  { title: "Cat Skateboard" },
  { $set: { title: "Flufferson on Skateboard" } }
);
{
  acknowledged: true,
  matchedCount: 1,
  modifiedCount: 1,
  upsertedId: null
}
Verify update: 
miaowtube> db.videos.find({}, { title: 1, _id: 0 });
[
  { title: "Flufferson on Skateboard" },
  { title: "Epic Cat Jump" },
  { title: "Cat vs Curtain" }
]
Delete Remove “Cat vs Curtain”: 
miaowtube> db.videos.deleteOne({ title: "Cat vs Curtain" });
{ acknowledged: true, deletedCount: 1 }

miaowtube> db.videos.find({});
[
  {
    _id: ObjectId("688ca2310aad588906929b3f"),
    user_id: 1,
    title: "Flufferson on Skateboard",
    link: "www.miaowtube/watch1",
    upload_date: "2025-05-25"
  },
  {
    _id: ObjectId("688ca2310aad588906929b4f"),
    user_id: 2,
    title: "Epic Cat Jump",
    link: "www.miaowtube/watch2",
    upload_date: "2025-05-27"
  }
]
Schema flexibility is powerful but can lead to inconsistent or inefficient queries if unchecked. Use indexes and, where appropriate, schema validation to maintain performance and data quality.
Summary of the MongoDB demo
  • CRUD operations map directly to familiar SQL concepts, but MongoDB uses flexible JSON-like documents.
  • Shell responses return JSON-style objects (acknowledged, insertedIds, matchedCount, etc.).
  • Schema and integrity: SQL enforces structure up front; MongoDB gives you flexibility but lets you add validation rules or handle constraints in application logic.
  • Performance and scale: document models and horizontal-sharding designs commonly make MongoDB and other NoSQL systems suitable for high-throughput workloads.
The image compares MySQL and MongoDB in terms of structure, data integrity, and performance and scale, with a person wearing a KodeKloud t-shirt standing beside the comparison chart.
Key takeaways
  • Relational databases: structured tables, strong consistency, ideal for accuracy and complex transactions.
  • NoSQL databases: flexible formats (document, key-value, column, graph), better for varied or rapidly changing data and massive scale.
  • Use the right tool for the job — many systems combine relational and non-relational databases to leverage strengths from both.
  • Indexes and well-designed queries matter in both paradigms for search speed and overall performance.
Links and references

Watch Video

Practice Lab