01 — Relational Foundations: Why SQL Databases Look Like They Do

"Just background" was how I skipped past relational foundations before writing any query, and the skip cost me later. The idea that everything else hangs off: a relational database organizes data into typed tables, and links those tables with shared key columns — and SQL is the language designed specifically to talk to that shape. [1][2]

The framing that finally landed is the contrast. A database is just a place to store facts so I can get them back. There are many shapes such a store can take. The relational shape — tables of rows and columns, related by keys — is one specific, opinionated answer, and SQL was built to match it. Once I could see the shape, the commands stopped feeling arbitrary and started feeling like the only natural way to address a table.

What "relational" actually means

A relational database stores data in tables — grids of rows and columns [1]. Each table represents one kind of entity: a customers table, an orders table, a products table. Each column is an attribute with a fixed type (name, email, price), and each row is one concrete record. The word "relational" is the part I'd been underweighting: tables are linked to each other through shared key columns. orders.customer_id points back to customers.id, so I can ask "which orders did customer 1 place?" by following that link [2].

That's the whole shape. Everything in SQL — JOIN, foreign keys, normalization (splitting data across tables to avoid duplication), even the syntax of SELECT — is a consequence of tables being addressed by column and related by key.

Why this shape won: the benefits

The relational model earned its dominance because of what the table-plus-key structure guarantees [3]:

• Data integrity through constraints and keys. A primary key makes every row uniquely addressable; a foreign key makes the database refuse an order whose customer_id doesn't exist. Bad data is rejected at the door.
• ACID transactions. Operations group into units that are atomic, consistent, isolated, and durable — so a transfer between two accounts either fully completes or fully rolls back, never half-applied.
• A declarative query language. I describe what data I want; the engine decides how to fetch it. I don't walk a tree or loop a cursor.

The trade-off is rigidity: the schema is fixed up front, every row in a table has the same columns, and changing the shape (adding a column) is a deliberate operation.

Where the relational model strains: the limitations

The same rigidity that gives integrity is the limitation [3]:

• Horizontal scaling is hard. Splitting one logical database across many machines while keeping joins and transactions correct is genuinely difficult, so RDBMS usually scale up (bigger box) rather than out (more boxes).
• Rigid schemas resist unstructured data. When the data is documents, nested arrays, or fields that vary per record, forcing it into uniform columns feels like fighting the model.

That friction is exactly what motivated the NoSQL side of the conversation.

SQL vs NoSQL: a question of shape

SQL and NoSQL aren't enemies — they're different answers to "what shape should the store be?" [4]

• SQL (relational): fixed tables and columns, strict schemas, joins across tables, strong consistency. Best when the data is structured, relationships matter, and correctness is non-negotiable.
• NoSQL (non-relational): flexible or nested documents, looser schemas, denormalized (data duplicated across machines) for scale. Best when the data shape varies, the volume outgrows one machine, or availability beats strict consistency.

The decision rides on the same few questions every time: Is my data structured and related, or variable and nested? Do I need strong consistency or horizontal scale? Are complex joins central to the workload, or do I mostly fetch one document? [4] Most production systems I've touched use SQL for the core transactional truth and reach for something NoSQL-shaped at the edges — caches, logs, search indexes — where the shape fits better.

How I use this

The practical payoff is a sizing check before I write a single CREATE TABLE. I ask whether the data is structured and relationally linked (customers → orders → products), whether I need strong consistency for money-like writes, and whether the workload is join-heavy. If yes, the relational shape plus SQL is the default and I don't second-guess it. I reach for NoSQL when one of those flips — variable shape, massive horizontal scale, or document-style fetch patterns. Getting that call right up front saves the painful "we modeled it as documents and now we need joins" conversation later.

References

[1] Amazon Web Services, "What is a relational database?," AWS, 2024. [Online]. Available: https://aws.amazon.com/relational-database/

[2] Mode Analytics, "SQL Tutorial," mode.com, 2024. [Online]. Available: https://mode.com/sql-tutorial/

[3] Google Cloud, "What is a relational database? — Advantages and disadvantages of DBMS," Google Cloud Learn, 2024. [Online]. Available: https://cloud.google.com/learn/what-is-a-relational-database

[4] MongoDB, "Understanding SQL vs NoSQL databases," mongodb.com, 2024. [Online]. Available: https://www.mongodb.com/resources/basics/databases/nosql-explained/nosql-vs-sql