Skip to main content
We’ve spent the last few lessons building tidy, structured databases using entities, relationships, and keys. To recap, here’s what Kodi’s MeowTube looks like as a relational database: three linked tables—users, videos, and comments—joined using primary and foreign keys. Each table has a fixed set of columns, which enforces consistency.
The image shows a person standing in front of a database schema diagram featuring tables for videos, users, and comments.
That rigid structure keeps data clean, but it can become cumbersome as your data variety grows. Consider an online store: at first a products table with columns like name, price, and category is fine. Later you may need size, color, voltage, or material—many of which are empty for some products. Splitting those attributes into separate tables leads to more joins, which slows searches as tables grow.
The image shows a person standing next to a graphic of an online shopping interface with categories like Name, Price, and Size. There's also a depiction of shopping elements like a cart and a credit card.
One workaround is to store attributes as multiple rows for the same product (attribute-per-row). For example:
  • 42, color, red
  • 42, size, M
  • 42, price, $149.99
This trades columns for rows, but it doesn’t scale well. If you have 10 million products and each has 100 attributes, you end up with 1 billion rows. Multi-filter searches then require multiple passes over the attribute table (one pass per filter), producing large intermediate result sets that must be intersected—an expensive operation. If numeric values are stored as text (e.g., price as a string), the database must also convert types during queries, adding extra overhead.
The image shows a diagram explaining a search query for a "Medium Red Jacket under $150," highlighting filtering criteria and processes, along with a person standing in front.
This approach can work for small datasets but struggles at scale. That’s where non-relational (NoSQL) databases often provide a better fit. By the end of this lesson you’ll be able to:
  • Describe different types of non-relational databases
  • Compare relational and non-relational approaches
  • Perform and interpret CRUD operations in a NoSQL database (we’ll use MongoDB as a concrete example)
The image shows a person standing next to a list outlining three tasks related to databases, with a cartoon cat on the side. The tasks include describing non-relational databases, comparing relational and non-relational databases, and performing CRUD operations in a NoSQL database.
What does NoSQL mean? It stands for Not Only SQL — a family of databases that relax the rigid relational schema to gain flexibility, performance, or scalability for specific data access patterns.
NoSQL databases are not a single technology. They include document stores, key-value stores, wide-column stores, graph databases, time-series databases, and vector databases—each optimized for different workloads and query patterns.
Below is an overview of common NoSQL flavors and how they apply to an app like MeowTube.
The image shows a person standing next to a list of database types, including document stores, key-value stores, wide-column stores, graph databases, time-series databases, and vector databases, with a stylized folder icon in the center.
Document stores
  • Store related data together in a single document (typically JSON/BSON).
  • Great for objects with many optional or evolving fields because you can add attributes without schema migrations.
  • Example document for a MeowTube video (JSON):
Objects are human- and machine-readable. Curly braces denote objects and square brackets denote lists. Sensitive fields (like email) can be omitted or kept in a separate collection with stricter access controls. If you need to add a new field—say dislikes—you can simply insert it into the document without changing a schema or running migrations:
If you prefer to store sensitive user details separately:
Key-value stores
  • Think of these as supercharged dictionaries: a unique key maps to a value (often a blob or JSON document).
  • Extremely fast for single-key lookups.
  • You lose automatic grouping of related data; you must fetch multiple keys and assemble results in the application.
Example key-value entries (pseudocode):
Wide-column stores
  • Rows resemble tables but columns are flexible per row.
  • Each row can have variable columns; you design “wide tables” optimized for specific access patterns.
  • Excellent for very large datasets and distributed workloads (e.g., regional sales metrics across millions of products).
The image illustrates a wide-column store database structure, showing tables for videos, users, and comments. It includes labels for various database types and a person standing beside the graphic.
Graph databases
  • Model data as nodes (entities) and edges (relationships).
  • Extremely efficient at traversing relationships (e.g., “users who liked videos uploaded by Fluffy”).
  • Ideal for social networks, recommendation engines, and fraud detection, where relationship queries are frequent and complex.
Time-series databases
  • Optimized for timestamped data where “when” is as important as “what”.
  • Rather than updating a single record, time-series DBs append new entries with timestamps to build a full history (e.g., daily views for a video).
  • Great for monitoring, metrics, analytics, and trend detection.
The image features a person in a "CodeKoda" shirt discussing data trends over time, with a focus on time-series databases. There are also cartoon cat characters labeled Kody, Kofi, and Kade.
Vector databases
  • Store vectors (lists of numbers) produced by machine learning models that capture semantic meaning.
  • Support nearest-neighbor searches to find similar items even when text or IDs don’t match exactly (e.g., “cat skateboard” → “fluffy kitten longboard”).
  • Useful for semantic search, recommendations, and AI-driven retrieval.
The image features a person in a "KodeKloud" shirt next to a graphic depicting a vector database search interface with cat illustrations. It highlights the use of vector databases for recommendations and AI-powered search.
Quick comparison table
Database TypeBest ForExample
Relational (SQL)Strong consistency, complex joins, transactional systemsOrders, inventory, banking systems
Document storeEvolving schemas, nested objects, fast reads of full objects{"video_id":1, "title":"Cat Skateboard", "comments":[...]}
Key-value storeExtremely fast single-key lookupsKey: video:1 -> Value: {...}
Wide-column storeMassive, sparse datasets with varied columnsRegional sales stats across millions of products
Graph databaseDeep relationship traversal and network queriesUsers and their connections/likes
Time-series DBTime-indexed metrics and historical trendsDaily video view counts over time
Vector databaseSemantic search and similarity queriesVectors produced by NLP/vision models
When to choose what
  • Use a relational database when you need transactions and strict schema/enforced integrity.
  • Use document stores when your objects are hierarchical, have many optional fields, or the schema evolves quickly.
  • Use key-value stores for caches and sessions when you only need single-key access.
  • Use wide-column stores for huge, sparse datasets distributed across many machines.
  • Use graph databases when relationships are first-class and you need fast traversals.
  • Use time-series DBs for metrics and monitoring.
  • Use vector DBs for semantic search and AI-driven recommendations.
Links and references
Flexible schemas simplify development but don’t eliminate the need for thought: design for your query patterns, enforce constraints where necessary, and keep sensitive data properly separated and secured.

Watch Video