Tech Notes

SQL & Relational Database Fundamentals

5 min read

Why these SQL fundamentals matter

Before diving into PostgreSQL-specific features, it’s critical to understand how SQL databases think.

These concepts:

  • apply to all relational databases
  • are fundamental to system design
  • determine correctness, performance, and data integrity

Summary

SQL fundamentals define how data is structured, related, protected, and modified.

Relational database principles

Tables (relations)

At its core, a relational database stores data in tables.

Mental model:

  • table → spreadsheet
  • row → one complete record
  • column → attribute with a fixed type

Each column has:

  • a name
  • a data type
  • optional constraints

Example: users table

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

What this enforces:

  • each user has a unique ID
  • usernames and emails cannot duplicate
  • missing critical fields is impossible

Important

Constraints are enforced by the database, not your application.

Rows = real-world entities

Each row represents one real-world thing.

Example rows:

  • one user
  • one post
  • one transaction

When a user signs up:

  • a new row is inserted
  • constraints are validated automatically

Relationships – what makes databases “relational”

Relational databases shine because they model relationships explicitly.

Foreign keys

Foreign keys create links between tables.

Example: posts belonging to users

CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    content TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Meaning:

  • every post must belong to a valid user
  • invalid references are rejected automatically

Important

Foreign keys enforce data integrity at the database level.

Relationship types (critical)

One-to-one

  • user → profile settings
  • passport → person

One-to-many

  • user → posts
  • order → order items

Example:

  • one user
  • many posts

Many-to-many

  • users ↔ liked posts
  • students ↔ courses

Requires an explicit join table.

Join tables (many-to-many)

Example: likes

CREATE TABLE likes (
    user_id INTEGER REFERENCES users(id),
    post_id INTEGER REFERENCES posts(id),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (user_id, post_id)
);

Key ideas:

  • each row represents a relationship
  • composite primary key prevents duplicates
  • timestamps capture interaction history

Summary

Join tables model relationships as first-class data.

Normalization – structuring data correctly

Normalization means:

  • splitting data into logical tables
  • minimizing duplication
  • enforcing consistency

Benefits:

  • no repeated user data in posts
  • single source of truth
  • easier schema evolution

Important

Normalization prioritizes correctness and flexibility.

Denormalization – intentional rule breaking

Sometimes we break normalization for performance.

Example:

  • storing like_count directly in posts

Why:

  • counting likes every time is expensive
  • read performance matters

Trade-off:

  • faster reads
  • more complex writes
  • risk of inconsistency

Summary

Denormalization trades consistency for performance — a classic design decision.

Acid properties – database guarantees

PostgreSQL strictly follows ACID:

  • Atomicity
  • Consistency
  • Isolation
  • Durability

This is a major differentiator from many NoSQL systems.

Important

ACID ensures correctness even under failures and concurrency.

Atomicity – all or nothing

A transaction either:

  • fully succeeds
  • or fully fails

Example: money transfer

BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE account_id = 'savings';
  UPDATE accounts SET balance = balance + 100 WHERE account_id = 'checking';
COMMIT;

If anything fails:

  • all changes are rolled back

Summary

Atomicity prevents partial failure and data corruption.

Consistency – rules are never violated

Consistency means:

  • database constraints always hold
  • transactions move data between valid states

Example constraint:

  • balance cannot go negative

    CREATE TABLE accounts ( account_id TEXT PRIMARY KEY, balance DECIMAL CHECK (balance >= 0), owner_id INTEGER REFERENCES users(id) );

If a transaction violates this:

  • entire transaction fails

Important

ACID consistency ≠ CAP consistency. Don’t confuse them in system design.

Isolation – concurrent transactions

Isolation controls how transactions interact when running at the same time.

PostgreSQL uses MVCC (multi-version concurrency control).

Isolation levels (postgres view)

PostgreSQL effectively supports:

  • Read Committed (default)
  • Repeatable Read
  • Serializable

Read Uncommitted behaves the same as Read Committed in PostgreSQL.

Anomalies overview

isolation leveldirty readsnon-repeatable readsphantom readsserialization anomalies
read committednot possiblepossiblepossiblepossible
repeatable readnot possiblenot possiblepossiblepossible
serializablenot possiblenot possiblenot possiblenot possible

Important

PostgreSQL never allows dirty reads.

Durability – once committed, it stays

Durability means:

  • committed data survives crashes
  • power loss doesn’t lose acknowledged writes

PostgreSQL achieves this via Write-Ahead Logging (WAL):

  1. write changes to log
  2. flush log to disk
  3. commit transaction

Summary

WAL guarantees durability by logging before modifying data files.

Durability vs performance tradeoff

Some systems relax durability for speed:

  • synchronous_commit = off
  • risk losing recent writes on crash

Warning

Relaxing durability is dangerous for financial or security-critical systems.

Why acid matters

Use cases:

  • financial transactions → ACID required
  • authentication → ACID preferred
  • analytics → ACID often relaxed
  • social media likes → eventual consistency acceptable

Summary

Database choice depends on correctness requirements, not popularity.

Sql language – conceptual overview

You rarely write SQL in system design interviews, but you must understand what SQL can express.

Sql command categories

Ddl – data definition language

Defines structure.

CREATE TABLE users (...);
ALTER TABLE users ADD COLUMN username TEXT;
DROP TABLE users;

Dml – data manipulation language

Works with data.

SELECT * FROM users WHERE created_at > NOW() - INTERVAL '7 days';
INSERT INTO users (...);
UPDATE users SET email = 'new@email.com' WHERE id = 123;
DELETE FROM users WHERE id = 123;

Dcl – data control language

Manages permissions.

GRANT SELECT ON users TO read_only_user;
REVOKE INSERT ON users FROM read_only_user;

Tcl – transaction control language

Manages transactions.

BEGIN;
  -- operations
COMMIT;

ROLLBACK;

Interview perspective on sql

Interviewers care about:

  • access patterns
  • indexing strategy
  • normalization vs denormalization
  • transactional guarantees

Not:

  • memorizing syntax
  • writing complex queries

Summary

SQL knowledge is about reasoning, not syntax.

Final revision checklist

  • tables store rows and columns
  • primary keys uniquely identify rows
  • foreign keys enforce relationships
  • join tables model many-to-many
  • normalization improves integrity
  • denormalization improves performance
  • ACID ensures correctness
  • SQL expresses structure, data, access, and transactions

Summary

These fundamentals are the backbone of every serious SQL-backed system.

Graph View