A Look Inside Non-Relational Databases: Where Data Lives in Documents & Stays Flexible
In the previous article, we looked at how databases connect information using relationships and why this model is used almost everywhere. 👉 Relational Databases
Relational databases are fantastic when your information fits neatly into a predictable structure — rows, columns, and clearly-defined relationships. But not all data in the real world behaves that way. Think about:
- A long chat conversation
- A product review that includes text, images, and ratings
- A user profile where every person has different details
- A JSON file coming from a website or mobile app
You can’t easily force this kind of information into a strict table without losing flexibility or creating unnecessary complexity. This is where non-relational databases come in. They are built to store:
- Unstructured data → no fixed shape (like images, videos, logs)
- Semi-structured data → has some structure but not a strict table format (like JSON or XML)
Before we explore the different types of non-relational databases, let’s first understand what unstructured data and semi-structured data really mean — and why they matter.
Nonstructured Data: The 80% of the World’s Information 🚧
Most of the data we create today — nearly 80% by many professional estimates — is nonstructured. This means it doesn’t fit neatly into rows and columns, the way relational databases prefer. Examples of Nonstructured Data include:
- Pictures and videos
- Web pages
- Emails
- Documents (PDFs, Word files, slides)
- Text messages and chat logs
- Social media posts
Even though this data has some internal organization, it still isn’t structured in a way that a database table can easily store.
For example:
- An email has a sender, receiver, subject, and message body
- A photo has metadata like date, location, and file type
- A web page has headings, paragraphs, and links
But they are not uniform. They vary widely in length, size, and format, making them “unstructured” from a database perspective.
A Real-World Analogy 🌍
Imagine a big box filled with random items — family photos, handwritten notes, travel brochures, birthday cards, receipts, kids’ drawings. All of them contain information, but they come in different shapes, sizes, and formats. You can look inside each one to get details, but you can’t arrange them into a clean table with fixed rows and columns. That’s precisely what unstructured data is like.
A relational database expects everything to be nice and tidy. But nonstructured data is more like a mixed collection of meaningful things that don’t follow one consistent shape.
Note: Non-structured data is often referred to as unstructured data. They both mean the same thing.
Semi-Structured Data: Unstructured Data With Helpful Labels 📑
As the name suggests, semi-structured data sits between structured and unstructured data. The easiest way to think of it:
➡️ It’s unstructured data that has been tagged with a bit of information (metadata) that makes it easier to organize and search.
What Is Metadata? 🧩
Metadata = “data about data“. It’s small pieces of extra information that describe the main data.
Examples:
- A photo → date taken, location, camera model
- An email → sender, receiver, subject line
- A document → author, last edited date
- A video → title, length, resolution
This extra information gives the data a bit of structure, even though the main content itself is still unstructured.
Example (Using the Email Example From Above) 💡
Earlier, we said emails are unstructured because their main content varies widely. But… emails also have:
- From: John
- To: Sarah
- Subject: “Budget Update”
- Date: November 3
- Labels: Work, Important, Urgent
These labels (metadata) let us:
- Sort all emails from “John”
- Filter emails that are marked “Important”
- Search only emails from last week
So even though emails are unstructured overall, metadata allows us to treat part of the information as structured. That makes them semi-structured.
Why Semi-Structured Data Matters 🚧
Metadata gives unstructured data some shape, even if it’s not enough to fit perfectly into database tables. But it gives us just enough structure to query, filter, and organize it.
A large portion of today’s “unstructured” data actually includes metadata—so the line between unstructured and semi-structured gets blurry.
Non-Relational (NoSQL) Databases: Flexible Storage for Modern Data ⛃ ⛁
Unlike relational databases that rely on strict tables, rows, and columns, NoSQL databases offer flexible data models. They are built for the modern world, where data is:
- Huge in volume
- Rapidly changing
- Unstructured or semi-structured
- Distributed across many servers
NoSQL databases shine when your data doesn’t fit neatly into a fixed schema.
Key Features of NoSQL Databases 🔰
Flexible Data Models. NoSQL databases support a variety of ways to organize and store data:
- Document databases
- Key-value databases
- Column-family (wide-column) stores
- Graph databases
These are official classifications of NoSQL databases. Each type is designed to handle different data shapes and different use cases.
Types of NoSQL Databases (Classifications) 📑
Document Databases
Store data as JSON-like documents.
- Good for user profiles, catalogs, logs, content, product data
- Flexible structure — every document can be different
- Easy to query individual parts of a document
Example: MongoDB (the most popular document database)
Key-Value Databases
Store data as simple key-value pairs.
- Extremely fast
- Great for caching, sessions, and configurations
- Works like a giant dictionary or hashmap
Example: Redis (used heavily in web apps)
Column-Family (Wide-Column) Stores
Store data in column families instead of rows.
- Designed for very large datasets
- Great for analytics, large-scale logs, IoT, time-series
- High write speed and linearly scalable
Example: Cassandra
Graph Databases
Store data as nodes and relationships.
- Ideal when connections matter more than values
- Used for social networks, recommendation systems, fraud detection
Example: Neo4j
Why NoSQL Databases Are Popular 🚀
NoSQL databases are widely used in modern applications because they are:
- Scalable → can handle huge amounts of data across multiple servers
- Fast → optimized for performance
- Flexible → can store any type of data
- Perfect for unstructured & semi-structured data → images, logs, JSON, user profiles
- Used in cloud, mobile, big data, and web apps
For a beginner learning the fundamentals, the two most commonly used and easiest to understand are:
- Document Databases
- Key-Value Databases
So this article focuses mainly on these two, since they represent the majority of practical NoSQL usage in everyday applications.
Document Databases 🗂️
While relational (structured) databases are powerful, they are not known for flexibility. They expect every record to look the same — same fields, same structure, same format. Document databases take the opposite approach.
What Is a Document in a Document Database? 📄
In a document database, each record and its related data are stored together as a single document. Think of a document as a self-contained packet of information. Example:
- A photo and all of the details about it —
- the 15 keywords used to describe it
- the date it was taken
- the location
- the photographer’s name
can all be stored in a single document.
Why Document Databases Are Flexible ⭐
A few cool features make document databases incredibly flexible:
- Each document is independent. One document can contain a picture and keywords; another might contain only text. They don’t have to match.
- Documents do NOT need to have the same structure. Some may have a “description” field, others may not — and that’s perfectly fine.
- Perfect for unstructured and semi-structured data. Images, logs, JSON objects, articles, user profiles — all can be mixed.
- Easy to distribute across servers. Since documents don’t depend on each other, different documents can live on different servers. This makes scaling simple and efficient.
- No assumed relationships between documents. Every document stands on its own. This removes many of the rigid requirements traditional relational systems have.
Searchability 🔍
Because documents can contain rich, varied metadata, document databases need:
- Strong indexing systems (to find the right document fast)
- Powerful search engines (to mine the data inside documents)
This is a core part of what makes them useful.
Popular Document Databases 🛢️
Here are examples of well-known NoSQL document databases:
- MongoDB (most popular)
- CouchDB
- Amazon DocumentDB
- ArangoDB
- Couchbase
Key-Value Databases 🔑
The second major type of NoSQL database is the key-value database. These databases store data in a very simple and very fast way:
- ➡️ A key (a unique name)
- ➡️ A value (the data you want to store)
Think of it like a giant dictionary or phonebook inside a database.
How It Works 🧩
A key is a unique label used to identify one piece of data.
- It can be anything: a username, product ID, file name, or a random string.
- The key must be unique — like a person’s home address
A value is the actual data. The value can be anything:
- text
- numbers
- dates
- image files
- JSON
- or even a whole document
Values are stored as blobs (Binary Large Objects), which means the database does not care about the format
When you want your data back, you use the key to retrieve the value. This makes key-value stores incredibly fast, simple, and perfect for high-performance systems.
Real-world example: ⭐
Think of a key-value database like a school locker system:
- The key is the locker number → it must be unique
- The value is whatever is inside the locker → books, lunchbox, notes, anything
If you know the locker number (key), you can instantly open it and get whatever is stored inside (value). The school doesn’t care what type of items each student keeps — everything is stored and retrieved by the locker number.
That’s exactly how a key-value database works.
Why They’re Useful ⭐
Key-value databases are great for:
- Caching (storing temporary results to speed up applications)
- Session storage (keeping a user logged in)
- Shopping carts in e-commerce
- User preferences/settings
- High-traffic web applications
They are optimized for quick lookups — if you know the key, you get the value instantly.
Popular Key-Value Databases 🛢️
Some well-known key-value databases include:
- Redis (most popular)
- Amazon DynamoDB (key-value + document)
- Riak KV
- Hazelcast
- Memcached (used mainly for caching)
Wrapping Up 🧭
Non-relational (NoSQL) databases were created to solve a very real problem in the modern world: most data doesn’t fit into neat tables anymore.
From photos and documents to user profiles and JSON objects, today’s applications generate information in all shapes and sizes. NoSQL databases step in to store this data flexibly, at scale, and across multiple servers without the rigid structure required by traditional relational systems.
This article is part of the Database Fundamentals Series — where we break down what databases are, how they store information, and how data is organized, accessed, and used behind the scenes. 👉 — Database Fundamentals: Foundation of Data Storage