Types of Databases: Relational vs Non-Relational
Not all databases are built the same. Choosing the right type of database for your project can mean the difference between a fast, scalable system and one that struggles under load. In this chapter, we explore the two major database families — Relational (SQL) and Non-Relational (NoSQL) — and learn when to use each.
The Two Major Database Categories
Every database system in use today falls into one of two broad families:
Quick memory trick: SQL databases use a fixed schema — you define the structure before adding data, like a spreadsheet template. NoSQL databases use a flexible schema — data can vary in structure, like a JSON file or a filing cabinet where each folder can contain different documents.
Relational Databases (RDBMS)
Relational databases organise data into tables (also called relations), where each table represents one type of entity. The power of relational databases comes from the ability to link tables together using keys, eliminating data duplication and enabling complex queries across multiple datasets.
Core characteristics of relational databases include:
- Structured schema — columns and data types are defined before data is inserted
- ACID compliance — transactions are Atomic, Consistent, Isolated, and Durable
- Referential integrity — foreign keys enforce valid relationships between tables
- SQL — a standardised, powerful language for querying and managing data
- Normalisation — data is organized to reduce redundancy
Best for: Financial systems, e-commerce, ERP, CRM, healthcare records, government data — any system where data accuracy, consistency, and complex relationships are critical.
Non-Relational Databases (NoSQL)
NoSQL (“Not only SQL”) databases emerged to address the limitations of relational databases at massive scale. They sacrifice some rigidity in schema and consistency for tremendous gains in speed, flexibility, and horizontal scalability. NoSQL is not one thing — it’s a family of four distinct storage models:
Examples: MongoDB, Firestore, CouchDB
Examples: Redis, Memcached, DynamoDB
Examples: Apache Cassandra, HBase, Bigtable
Examples: Neo4j, Amazon Neptune, ArangoDB
Relational vs Non-Relational — Side-by-Side Comparison
Here’s a detailed feature comparison to help you understand the trade-offs:
| Feature | Relational (SQL) | Non-Relational (NoSQL) |
|---|---|---|
| Data Structure | Tables with fixed rows and columns | Documents, key-value, graphs, columns |
| Schema | Fixed and predefined (schema-on-write) | Flexible or dynamic (schema-on-read) |
| Query Language | SQL — standardised across vendors | Varies by system (MongoDB Query Language, CQL, etc.) |
| Relationships | Built-in via JOINs and Foreign Keys | Embedded documents or application-level joins |
| ACID Compliance | Strong ACID guarantees by default | Varies — many offer eventual consistency (BASE) |
| Scalability | Vertical scaling (bigger server) | Horizontal scaling (more servers) |
| Performance | Excellent for complex queries and joins | Excellent for simple, high-throughput reads/writes |
| Maturity | Very mature (50+ years) | Newer but rapidly maturing |
| Ideal For | Banking, ERP, e-commerce, CRM | Real-time analytics, IoT, social feeds, caching |
When Should You Use SQL vs NoSQL?
This is one of the most common architectural decisions in software development. Use the table below as a practical guide:
| Your Requirement | Use | Reason |
|---|---|---|
| Financial transactions, strict data integrity | SQL (Relational) | ACID guarantees are non-negotiable for money |
| Complex queries joining many related tables | SQL (Relational) | SQL and indexes make multi-table joins efficient |
| Storing JSON-like user profiles with varying fields | NoSQL (Document) | Schema flexibility avoids rigid column constraints |
| Session tokens, caching, real-time leaderboards | NoSQL (Key-Value) | In-memory key-value stores like Redis have microsecond latency |
| Social network friend-of-friend recommendations | NoSQL (Graph) | Graph traversal is native and extremely fast |
| Time-series sensor data from millions of IoT devices | NoSQL (Column) | Column stores handle append-heavy workloads at scale |
| Building a standard web application (blog, shop, CRM) | Either (SQL preferred) | SQL is well-understood, tooling is richer, easier to evolve safely |
Where Does MySQL Fit?
MySQL is a Relational Database Management System (RDBMS) — it belongs to the SQL family. Understanding the full database landscape helps you appreciate where MySQL excels:
MySQL is one of the most popular choices within the Relational family — proven, fast, and backed by Oracle.
Key Takeaways
- Databases are broadly classified into Relational (SQL) and Non-Relational (NoSQL) systems.
- Relational databases use tables with fixed schemas, enforce ACID compliance, and use SQL for queries.
- NoSQL databases come in four flavors — Document, Key-Value, Column-Family, and Graph — each optimised for different use cases.
- SQL excels at complex queries, relationships, and data integrity; NoSQL excels at scale, flexibility, and speed for simple access patterns.
- MySQL is an RDBMS — a Relational Database Management System — and is the focus of this entire course.
- Choosing the right database type depends on your data structure, access patterns, consistency requirements, and scale.
What’s Next?
In Chapter 1.3 — Core Relational Database Concepts, we’ll go deep into the building blocks of every relational database: Tables, Rows, Columns, Primary Keys, Foreign Keys, and the three types of Relationships (1:1, 1:N, and M:N) — all with practical examples.