Databases: Relational vs Non-Relational
Files are great for sharing data, but databases are where data lives and works. Learn the fundamental difference between relational and non-relational databases.
What is a database?
A database is an organised collection of data that lets you store, find, and update information quickly.
Think of it as the difference between a pile of sticky notes on your desk (files) and a well-organised filing cabinet with labelled folders (database). Both store information, but the filing cabinet lets you find things fast and keeps everything in order.
There are two big families of databases: relational (everything in neat tables) and non-relational (flexible storage for different shapes of data).
Relational databases
A relational database stores data in tables (also called relations). Each table has a fixed set of columns, and each row represents one record.
Tables are linked together through relationships — a column in one table references a column in another. This is what makes them “relational.”
Jake’s example: CloudPulse’s customer database might have:
| Customers table | Orders table | ||
|---|---|---|---|
| CustomerID (PK) | Name | OrderID (PK) | CustomerID (FK) |
| 101 | Meridian Health | 5001 | 101 |
| 102 | Kiwi Fitness | 5002 | 101 |
The CustomerID column links the two tables. You can query “show me all orders for Meridian Health” by joining the tables on that shared column.
Key characteristics:
- Data stored in tables with fixed schemas
- Tables linked by keys (primary keys and foreign keys)
- Queried using SQL (Structured Query Language)
- Enforce data integrity (no orphan records, type checking)
- Examples: Azure SQL Database, MySQL, PostgreSQL
Non-relational databases (NoSQL)
A non-relational database (often called NoSQL — “Not Only SQL”) doesn’t use tables with fixed schemas. Instead, it stores data in flexible formats depending on the use case.
There are four common types:
| Type | How It Works | Example Use Case |
|---|---|---|
| Document | Stores JSON-like documents. Each document can have different fields. | User profiles, product catalogues |
| Key-value | Simple pairs: a unique key maps to a value. Ultra-fast lookups. | Session data, shopping carts, caching |
| Column-family | Groups related columns together. Optimised for reading large datasets. | IoT telemetry, time-series data |
| Graph | Stores data as nodes (entities) and edges (relationships between them). | Social networks, recommendation engines |
Aisha’s example: Her food app stores user profiles as documents in Azure Cosmos DB:
{
"userId": "aisha-001",
"name": "Aisha Mohammed",
"favourites": ["Chicken wrap", "Flat white"],
"dietary": ["halal"]
}Each profile can have different fields — Liam might not have “dietary” preferences. The flexibility of document storage handles this naturally.
| Feature | Relational | Non-Relational (NoSQL) |
|---|---|---|
| Data model | Fixed tables with rows & columns | Flexible: documents, key-value, graph, or column-family |
| Schema | Defined upfront (rigid) | Flexible or schema-on-read |
| Query language | SQL | Varies (API calls, SQL-like dialects, query builders) |
| Relationships | Enforced via foreign keys and joins | Typically embedded within documents or handled by the app |
| Best for | Transactional systems, structured business data | Flexible data, high scale, global distribution |
| Azure example | Azure SQL Database | Azure Cosmos DB |
When to choose relational vs non-relational
Choose relational when:
- Your data has a consistent, well-defined structure
- You need strong data integrity and relationships between entities
- You use complex queries with joins across multiple tables
- Example: Tom’s delivery tracking system (orders, drivers, routes — all tightly related)
Choose non-relational when:
- Your data shape varies between records
- You need horizontal scaling (distribute data across regions)
- You need ultra-fast reads/writes at massive scale
- Example: Aisha’s user profiles (each user has different preferences)
Many modern applications use both — relational for core transactions and non-relational for flexible or high-scale workloads.
Exam tip: the 'which database' pattern
The exam frequently gives you a scenario and asks which type of database fits best. Look for these signals:
- “Fixed schema,” “relationships between tables,” “SQL queries” → Relational
- “Flexible schema,” “JSON documents,” “varying fields” → Non-relational (document)
- “Fast lookups by key,” “session data,” “cache” → Non-relational (key-value)
- “Social network,” “recommendations,” “connected entities” → Non-relational (graph)
Flashcards
Knowledge check
Jake's startup, CloudPulse, needs to store customer billing records. Every customer has exactly the same fields: company name, billing address, plan tier, and monthly amount. The finance team needs to run SQL reports. Which database type should Jake choose?
Aisha's food app needs to store restaurant menus. Each restaurant has different categories, items, and pricing structures — some have combo deals, others have seasonal specials. The menu format varies widely. Which database type is the BEST fit?
Next up: Transactional Workloads: Keeping Data Consistent — learn what happens when data needs to be 100% accurate, every time.