Every earlier lesson in this course used a relational database without stopping to define what that word means. This lesson is the conceptual grounding — worth reading even after the syntax is comfortable.
Data is organized into tables (formally called relations), each with a fixed set of columns, and rows related to each other through shared keys — the foreign keys from the earlier Data Constraints lesson are exactly this relationship mechanism in practice.
A Relational Database Management System is the software that stores, organizes, and lets a program query relational data — PostgreSQL, MySQL, SQL Server, and Oracle Database are all RDBMSes; SQL is the language nearly all of them use.
| Benefit | Why it matters |
|---|---|
| Data integrity | Constraints (PRIMARY KEY, FOREIGN KEY, CHECK) enforce correctness at the database level, not just in application code |
| No duplicate data | Normalization (organizing data to avoid repeating the same information in multiple places) keeps updates consistent |
| A standard query language | SQL is broadly transferable between different RDBMSes, unlike most NoSQL query APIs |
| Strong consistency | A transaction's ACID guarantees (from the earlier lesson) make the data trustworthy under concurrent use |
| Limitation | Why it matters |
|---|---|
| A fixed schema | Every row in a table must fit the same column structure — awkward for data that's naturally irregular |
| Harder to scale horizontally | Splitting a relational database across many servers while keeping joins fast is a genuinely hard problem |
| Joins get expensive | A query touching many related tables can slow down significantly as data grows, without careful indexing |
A NoSQL database (MongoDB, Redis, Cassandra, and others) trades some of the relational model's guarantees for flexibility and easier horizontal scaling — commonly storing documents, key-value pairs, or graphs instead of fixed-schema tables.
| Question | Favors SQL | Favors NoSQL |
|---|---|---|
| Does the data have a clear, stable structure? | Yes | No — it varies row to row |
| Do relationships between records matter a lot? | Yes — joins are a core tool | Less — data is often self-contained per document |
| Is strict consistency (ACID) critical? | Yes — banking, inventory, anything money-related | Sometimes acceptable to relax for speed/scale |
| Does it need to scale to huge, distributed volume? | Harder, though modern RDBMSes have improved this | Often designed for this from the start |
Where to go next
This site's MongoDB course covers the NoSQL side of this comparison in depth — worth a look once the relational model here feels solid, to see the same problems solved a genuinely different way.