Introduction to SQL

What is SQL?

SQL (Structured Query Language) is the standard language for working with relational databases. It was designed around one idea: describe the result you want, and let the database figure out how to get it. This declarative approach means you can express in a single statement what would take dozens of lines of imperative code in a general-purpose language. That’s what makes SQL so enduring — it maps directly to how people think about data.

Unlike general-purpose languages where you write step-by-step instructions, SQL is declarative: you describe the result you want, and the database engine figures out how to produce it. Instead of writing a loop to find all users in a specific city, you write:

-- Declarative: describe what you want, not how to find it
SELECT name, email FROM users WHERE city = 'Berlin';

SQL has been around since the 1970s and remains one of the most in-demand technical skills across software engineering, data science, and business analytics.

The Relational Model

Relational databases organize data into tables (also called relations). The central insight of the relational model is that each fact should be stored exactly once, and related data should be connected through keys rather than duplicated. This eliminates the update anomalies that plagued earlier flat-file systems: if a customer changes their email address, you update one row in one table, and every query that references them automatically sees the new value.

Each table has:

• Columns (fields) — define the structure and data type of each attribute (e.g., name TEXT, age INTEGER)
• Rows (records or tuples) — each row is a single instance of data, like one user or one order
• Primary Key — a column (or combination of columns) that uniquely identifies each row
• Foreign Key — a column that references the primary key of another table, establishing a relationship

Here’s a minimal example with two related tables:

-- A table of customers — each customer stored once
CREATE TABLE customers (
    id        SERIAL PRIMARY KEY,
    name      TEXT NOT NULL,
    email     TEXT UNIQUE NOT NULL
);

-- A table of orders linked to customers via foreign key
CREATE TABLE orders (
    id          SERIAL PRIMARY KEY,
    customer_id INTEGER REFERENCES customers(id),  -- the link back to customers
    amount      NUMERIC(10, 2),
    created_at  TIMESTAMPTZ DEFAULT NOW()
);

The customer_id column in orders is a foreign key — it links each order back to the customer who placed it. This relationship lets you answer questions like “what orders did Alice place?” without duplicating Alice’s data in every order row. This is the core idea behind the relational model: store each fact once, and connect data through relationships.

Popular Relational Database Systems

SQL is a standard, but each database engine implements it with its own extensions and quirks. Different engines optimize for different workloads — some prioritize raw transaction throughput, others feature richness or ease of embedding. Understanding which engine you’re working with matters because syntax differences are real, even if the core concepts transfer completely.

• PostgreSQL — open-source, feature-rich, production-grade. The best default choice for new projects. Supports JSON, full-text search, window functions, and much more.
• MySQL / MariaDB — widely used in web hosting and legacy applications. MySQL powers much of the early web (WordPress, Drupal, etc.).
• SQLite — a serverless, file-based database. Perfect for local development, embedded applications, and mobile apps. No setup required.
• SQL Server — Microsoft’s enterprise database, common in corporate environments and .NET stacks.
• Oracle Database — enterprise-grade, dominant in large financial and government systems.

This tutorial series focuses on PostgreSQL, but the core SQL concepts apply everywhere. Minor syntax differences will be called out where they matter.

When to Use a Relational Database

Relational databases shine when your problem fits the relational model: structured data, meaningful relationships between entities, and a need for correctness guarantees. They’re a poor fit when your schema is fundamentally dynamic or when you need to scale writes horizontally across hundreds of nodes — but those are relatively rare problems. For the vast majority of applications, relational is the right default.

Relational databases excel when:

• Your data has structure — you know the shape of your records upfront (users have names, emails, and signup dates)
• Relationships matter — you need to connect entities (orders belong to customers, comments belong to posts)
• You need consistency — ACID transactions guarantee that your data stays correct even if something goes wrong mid-operation
• You’re writing complex queries — JOINs, aggregations, and window functions let you answer sophisticated questions without writing application code

Common use cases include:

• Web applications — user accounts, products, orders, sessions
• Analytics and reporting — aggregating sales data, computing cohort metrics
• Data pipelines — transforming and loading structured data between systems
• Financial systems — where transactional integrity is non-negotiable

A document database (MongoDB) or key-value store (Redis) might be a better fit when your data is highly unstructured, you need extreme write throughput, or your schema changes constantly. But for the vast majority of applications, a relational database is the right starting point.

A Brief History

IBM researcher Edgar F. Codd proposed the relational model in 1970. IBM developed an early prototype called System R, and the query language it used — SEQUEL — was later renamed SQL. Oracle shipped the first commercial SQL database in 1979.

In 1986, ANSI published the first SQL standard. It has been revised multiple times (SQL-92, SQL:1999, SQL:2003, SQL:2011, SQL:2016), each adding features like window functions, CTEs, and JSON support. Despite decades of NoSQL alternatives, SQL remains the dominant language for structured data work.

What You’ll Build in This Series

By the end of this series, you’ll be able to:

• Design a normalized database schema
• Write queries that filter, sort, aggregate, and join data across multiple tables
• Use advanced features like window functions, CTEs, and full-text search
• Understand query performance and read execution plans

Start with the next tutorial to get PostgreSQL installed and running on your machine.