Free lesson · Mastering SQL

What Is SQL?

Easy10 min readsqldatabase

Alex: Alright. Module 1. I am ready. But I want to start with the most basic question I can think of - what actually is SQL?

Emeka: Perfect starting point. Let me give you the one-sentence version first, and then we will unpack it.

SQL is a language for talking to databases. You write a statement that describes what data you want, and the database figures out how to get it for you.

That is it. That is the core idea. But that one sentence contains something subtle that most beginners miss, and it is the single most important thing I can teach you in this entire lesson.

Alex: What is the subtle part?

Emeka: The word describes. You describe what you want. You do not describe how to get it. That distinction - between describing the "what" and instructing the "how" - is the difference between SQL and almost every other programming language you have used or will use.

Declarative vs Imperative - The Mental Shift

Let me give you an analogy that makes this click.

Imagine you walk into a restaurant. You sit down and say to the waiter: "I would like a margherita pizza." That is a declarative statement. You described what you want. You did not say "go to the kitchen, open the refrigerator, take out the dough, stretch it on the counter, spoon tomato sauce onto it, spread the mozzarella, put it in the oven at 250 degrees for twelve minutes, take it out, slice it, bring it to table seven." You just said what you wanted, and the kitchen figured out how to produce it.

SQL works exactly like that. You say:

SELECT name, email
FROM users
WHERE country = 'Nigeria'
ORDER BY name;

That statement says: "Give me the name and email of every user in Nigeria, sorted alphabetically by name." It does not say how to find them. It does not say which index to use, which disk page to read, how to sort the results, or how to manage memory while doing it. The database engine - the kitchen - handles all of that.

Alex: So SQL is like ordering food, and the database is the kitchen?

Emeka: Exactly. And the kitchen is incredibly sophisticated. Modern database engines like PostgreSQL have query planners that analyze your request, consider dozens of possible ways to execute it, estimate the cost of each approach, and choose the fastest one. They do this in milliseconds, for every query. Your job is to describe what you want clearly. The engine's job is to figure out the fastest way to deliver it.

Now contrast this with an imperative language like Python or Java. If you wanted to find all users from Nigeria in Python, you would write something like this:

nigerian_users = []
for user in all_users:
    if user.country == 'Nigeria':
        nigerian_users.append(user)
nigerian_users.sort(key=lambda u: u.name)

See the difference? In Python, you are writing the instructions. Create an empty list. Loop through every user. Check the condition. Append if it matches. Sort the result. You are the chef, doing every step yourself.

In SQL, you are the diner. You state the result you want, and the database delivers it. That is what "declarative" means.

graph LR
    subgraph Imperative["Imperative (Python, Java)"]
        I1["You write the steps"]
        I2["Loop, check, filter, sort"]
        I3["You control HOW"]
    end
    
    subgraph Declarative["Declarative (SQL)"]
        D1["You describe the result"]
        D2["SELECT, WHERE, ORDER BY"]
        D3["Engine decides HOW"]
    end
    
    Imperative -.->|"Different paradigm"| Declarative

    style Imperative fill:#94a3b8,color:#000
    style Declarative fill:#6366f1,color:#fff

This diagram shows two boxes side by side. The left box, labeled Imperative and showing Python and Java, contains three items: you write the steps, loop check filter sort, and you control how. The right box, labeled Declarative and showing SQL, contains: you describe the result, SELECT WHERE ORDER BY, and engine decides how. An arrow between them indicates they are different paradigms. The declarative box is highlighted in indigo to show it is the focus of this course.

Important: This is the single biggest mental shift for anyone learning SQL. If you come from Python, JavaScript, Java, or any imperative language, your instinct is to think in loops and conditions. SQL requires you to think in sets and transformations. Instead of "loop through each row and check if it matches," you think "give me the set of rows that match this condition." The shift feels unnatural at first. By the end of Module 2, it will feel obvious.

Alex: Why does this matter? If both approaches give me the same result, why should I care whether I describe "what" or instruct "how"?

Emeka: Because the database engine is almost always better at choosing the "how" than you are. Let me give you a real example from my work.

At Netflix, we have tables with billions of rows. If I wrote an imperative program to scan through every row looking for matches, it would take minutes or hours. But when I write a SQL query, the database engine reads the query, checks which indexes exist, estimates how many rows will match, and often finds a way to answer the question by reading only a tiny fraction of the data. A query that would take an hour as a Python loop takes milliseconds as a SQL statement. Not because SQL is magic, but because the query planner has optimization strategies that would take you weeks to implement by hand.

That is the power of declarative. You get the engine's expertise for free, as long as you describe your intent clearly.

Where SQL Lives in a Real System

Alex: Okay, so SQL talks to databases. But where does a database actually sit? Like, when I open Instagram, is SQL involved somewhere?

Emeka: Everywhere. Let me show you.

graph TD
    U["User (you on Instagram)"] --> A["Application Server<br/>(Python, Java, Node.js)"]
    A -->|"SQL queries"| DB["Database<br/>(PostgreSQL, MySQL)"]
    DB -->|"Result rows"| A
    A --> U
    
    A -->|"SQL queries"| DW["Data Warehouse<br/>(Redshift, BigQuery)"]
    DW -->|"Analytics results"| DASH["Dashboards & Reports"]
    
    style DB fill:#6366f1,color:#fff
    style DW fill:#8b5cf6,color:#fff

This diagram shows the flow of a typical web application. At the top, the user interacts with an application server running Python, Java, or Node.js. The application server sends SQL queries to a database like PostgreSQL or MySQL, and receives result rows back. The application server also sends SQL queries to a data warehouse like Redshift or BigQuery, which feeds dashboards and reports. The database and data warehouse are highlighted to show that SQL is the interface layer for both.

When you open Instagram, here is what happens in the first second:

Your phone sends a request to Instagram's application server. That server - written in Python, in Instagram's case - needs to figure out what to show you. Your feed, your notifications, your stories. To do that, it talks to a database. And it talks to that database using SQL.

"Give me the twenty most recent posts from accounts this user follows." That is a SQL query. "Give me all unread notifications for this user, sorted by timestamp." That is a SQL query. "How many likes does this post have?" SQL.

The application server sends SQL to the database. The database executes the query and returns the result. The application server formats the result into the response your phone displays. This round trip happens hundreds of times per second, for hundreds of millions of users.

Alex: So the application code and the SQL are separate things?

Emeka: Yes. The application code handles user interaction, business logic, authentication, formatting. The database handles data storage, data retrieval, and data integrity. SQL is the bridge between them. The application does not know how the database stores data internally. The database does not know what the application does with the results. SQL is the contract between them.

And here is where it gets interesting for your career: SQL is not just used in web applications. It is used in data warehouses for business analytics. It is used in data pipelines for ETL processing. It is used in machine learning feature engineering. It is used in financial reporting, healthcare records, logistics optimization, fraud detection. Every industry that stores data - which is every industry - uses SQL.

Tip: SQL is the most universally useful technical skill in the world. Python is popular. JavaScript is popular. But SQL is used by software engineers, data analysts, data scientists, product managers, business analysts, financial analysts, and operations teams. No other technical skill crosses that many job functions. Learning SQL does not just prepare you for an interview. It makes you useful in virtually every data-touching role.

A Brief History - Why SQL Won

Alex: How old is SQL? Is it one of those ancient languages like COBOL?

Emeka: It is older than you think and more alive than almost anything else from its era. Let me give you the short version.

In 1970, a mathematician at IBM named Edgar F. Codd published a paper called "A Relational Model of Data for Large Shared Data Banks." That paper proposed that data should be stored in tables (relations), and that a language should exist to query those tables using mathematical set theory. At the time, databases were navigational - you had to write code that traversed data structures manually, following pointers from one record to the next. Codd proposed something radical: describe the data you want, and let the system figure out how to retrieve it. It was a fundamental shift in how humans interact with stored data - from telling the machine every step to simply telling it the answer you need.

In 1974, IBM built a prototype based on Codd's ideas. The query language they created was called SEQUEL - Structured English Query Language. They later shortened it to SQL for trademark reasons. The pronunciation debate - "sequel" versus "S-Q-L" - has been going on ever since. Both are correct. I say "S-Q-L." You can say whichever you want.

In 1979, a company called Relational Software released the first commercial SQL database. They later renamed themselves Oracle. Yes, that Oracle.

By the mid-1980s, SQL had been adopted by IBM (DB2), Oracle, and a growing number of vendors. In 1986, ANSI adopted SQL as a standard. In 1987, ISO followed. SQL became the universal interface for relational databases.

Alex: That was over forty years ago. How is it still the dominant language?

Emeka: Because the problem it solves - "I have data, I need answers" - never went away. Technologies come and go. Programming languages rise and fall. Frameworks are hot for three years and then forgotten. But the need to store, query, and analyze structured data is permanent.

In the 2010s, there was a movement called NoSQL - "Not Only SQL" - that argued relational databases were too rigid for modern applications. MongoDB, Cassandra, Redis, and others offered alternative data models. And for certain use cases, they were right. But here is what happened: most of those NoSQL databases eventually added SQL interfaces. MongoDB added an aggregation pipeline that looks suspiciously like SQL. Cassandra added CQL, which is basically SQL with restrictions. Google's BigQuery, Amazon's Redshift, Snowflake, Databricks - all of them use SQL as their query interface.

SQL did not survive because it is perfect. It survived because it is useful. It lets humans express complex data questions in a way that is readable, learnable, and powerful enough to handle everything from a three-row lookup to a billion-row analytical pipeline. Every year, someone predicts SQL's death. Every year, more systems adopt SQL as their interface.

The lesson for you as a learner is this: SQL is not a trend. It is infrastructure. Learning it is not a bet on a framework that might be irrelevant in five years. It is an investment in a skill that has been relevant for fifty years and shows no signs of fading.

At Netflix, I use SQL every day. Not because it is the only option. Because it is the best interface for the problems I solve. And the SQL I write in 2026 is recognizable to someone who learned SQL in 1996. The syntax has barely changed. The databases underneath have gotten astronomically more powerful. That is the beauty of a declarative language - the interface stays stable while the engine evolves.

Note: SQL is standardized by ISO/ANSI. The major versions of the standard are SQL-86, SQL-92, SQL:1999 (added recursive queries and window functions), SQL:2003 (added XML support), SQL:2011 (added temporal data), SQL:2016 (added JSON support), and SQL:2023 (the most recent). Most databases support SQL-92 fully, SQL:1999 and SQL:2003 partially, and cherry-pick features from later standards. PostgreSQL has the most comprehensive support of any open-source database.

What SQL Can Actually Do

Alex: So SQL is for querying data. Is that all it does?

Emeka: No, and this is a common misconception. SQL has four major sub-languages, and querying is only one of them.

DQL is what most people mean when they say "SQL" - writing SELECT statements to pull data. That is the focus of most of this course, because that is what interviews test. But SQL also lets you insert, update, and delete data (DML). It lets you create and modify tables (DDL). And it lets you control who can access what (DCL).

We cover all four in this course. DQL dominates Modules 2 through 7 and is the primary focus of interview preparation. DML and DDL appear in Module 8 - creating tables, inserting data, updating records. DCL appears in Module 14 where we cover database security. But all of it is SQL, and all of it runs against the same database engine using the same declarative approach.

Alex: One more question. You said SQL talks to databases. What exactly is a database?

Emeka: A database is a system for storing and retrieving structured data. The "structured" part is important - it means the data has a defined shape. Tables with columns that have names and types. Rows that follow the same structure. Relationships between tables.

The specific type of database SQL talks to is a relational database - one that stores data in tables that are related to each other through keys. That is what the next lesson is about: the relational model. It is the mental model underneath everything else you will learn.

We are going to spend the next lesson understanding tables, rows, columns, and relationships at a level deep enough that you never have to re-learn it. And then we move into the practical stuff - keys, constraints, normalization - the tools for designing databases that actually work in production.

Alex: Let us do it.

Tip: Your next step: Move on to Topic 1.2 - The Relational Model - where we build the mental model that every SQL concept depends on.

Back to Mastering SQL