Almost every app you use, from a banking app to a to-do list, stores its data somewhere and needs a way to ask for it back: "show me this user's orders," "find every product under $20." SQL (Structured Query Language) is the language used to ask those questions of a relational database, and to add, change, or remove data in it.
Learning Objectives
- Explain what a relational database stores data in, and why that shape makes SQL possible.
- Describe where SQL sits between an application and its data.
- Tell SQL (the language) apart from MySQL, PostgreSQL, and other database systems that run it.
Your App
"Get this user's orders"
SQL Query
SELECT * FROM orders...
Database Engine
Finds the matching rows
Result
Rows sent back to your app
Data, Organized Into Tables
A relational database stores data in tables, which look a lot like spreadsheets. Each table holds one kind of thing, a users table, a products table, an orders table, and each row in that table is one record of that thing. Each column is one piece of information every row has.
| Spreadsheet term | Database term | Example |
|---|---|---|
| Sheet | Table | users |
| Row | Row (or "record") | one specific user |
| Column header | Column (or "field") | email, created_at |
| One cell | A value | "ada@example.com" |
"Relational" refers to how tables relate to each other, for example an orders row pointing at which users row placed it, not to any single table on its own. You'll build that connection yourself in a later lesson on joins.
Where SQL Fits
- Handles user input, business logic, and display
- Decides what question to ask the database
- Sends a SQL query and waits for a result
- Stores the actual data on disk
- Reads the SQL query and figures out how to run it fast
- Returns matching rows back to the application
SQL Is a Language, Not a Product
SQL itself is a standard (maintained by ISO/ANSI), not a piece of software you install. A very common mix-up for new developers: hearing "I'm learning SQL" and "I installed MySQL" and assuming they're the same statement. They're not, MySQL, PostgreSQL, SQLite, SQL Server, and Oracle Database are all separate database systems, built by different companies and projects, that all understand SQL as their query language. They agree on the core of SQL, the parts this course focuses on, but each adds its own extra features and small differences, the same way British and American English share a core but differ in spelling here and there.
| SQL database | Built by | Known for |
|---|---|---|
| MySQL | Oracle Corporation (open source) | The most widely used, especially in web hosting and WordPress-style stacks |
| PostgreSQL | Open source community | Strong standards compliance, advanced features, popular for new production apps |
| SQLite | Open source | No server, a database is just one file, used inside apps and for learning |
| Microsoft SQL Server | Microsoft | Common in enterprises already using Microsoft infrastructure |
| Oracle Database | Oracle Corporation | Long-standing enterprise use, especially large older systems |
| MariaDB | Open source (MySQL fork) | A drop-in MySQL alternative, used by many Linux distributions by default |
SQL vs NoSQL
SQL databases (also called relational databases) are only one branch of how databases store data. The other major branch is NoSQL ("not only SQL"), a broad umbrella term, not one single technology, covering several different ways of storing data that don't use the table-with-fixed-columns model this course is built around.
| NoSQL database | Data model | Known for |
|---|---|---|
| MongoDB | Document | The most popular document database, stores JSON-like records |
| Redis | Key-value | In-memory, extremely fast, often used for caching and sessions |
| Cassandra | Wide-column | Built to scale across many servers with no single point of failure |
| DynamoDB | Key-value / document | Amazon's managed NoSQL database, used heavily on AWS |
| Firebase Firestore | Document | Google's managed database, popular for mobile and small web apps |
| Neo4j | Graph | Built specifically for data that's mostly about relationships, social networks, recommendations |
- Data lives in tables with a fixed set of columns
- Every row in a table has the same structure
- Relationships between tables are explicit (foreign keys)
- Best fit when data is structured and relationships matter, orders, accounts, inventory
- Several different models: documents, key-value pairs, wide columns, graphs
- Structure can vary from one record to the next
- Built to scale across many servers easily
- Best fit for very large, fast-changing, or loosely-structured data, logs, caching, real-time feeds
This course focuses entirely on SQL and relational databases, by far the most common choice for a typical application's main data. NoSQL databases are worth knowing exist, and are often used alongside a SQL database for a specific job (Redis for caching, for example), rather than as a full replacement for it.
Frequently Asked Questions
Is SQL a programming language?
Not in the same sense as Python or JavaScript. SQL is a declarative language: you describe the result you want ("rows where age > 18"), not the step-by-step logic to get it. The database engine figures out how to actually fetch it.
What's the difference between SQL and MySQL?
SQL is the language. MySQL is one specific database system that uses SQL. It's the same relationship as HTML (the language) and a web browser like Chrome (software that reads it), the language doesn't change, but each database system implements it with its own small quirks and extras.
Is SQL case-sensitive?
SQL keywords (SELECT, WHERE, FROM) aren't case-sensitive, SELECT and select work the same. By convention this course writes keywords in uppercase to make queries easier to read. Table and column names can be case-sensitive or not depending on the database system and how they were created, so it's safest to be consistent with whatever casing you first used.
Common Beginner Mistakes
Saying "I'm learning MySQL" when you mean SQL in general
This quietly narrows every tutorial, job listing, and Stack Overflow answer you'll search for. Say "SQL" for the language and skill, and name the specific system (MySQL, PostgreSQL, etc.) only when a feature or quirk is actually specific to it.
Assuming a feature that works on one database works everywhere
Core SQL (SELECT, WHERE, JOIN, basic aggregates) is shared, but plenty of real features aren't, auto-increment columns, pagination syntax, and string functions all vary. Assuming otherwise is how a query that worked in development suddenly fails against a different production database.
Treating NoSQL as "the same thing, just newer"
NoSQL isn't a newer version of SQL, it's a different data model entirely (documents, key-value, graphs) that solves a different set of problems. Neither one replaces the other, they're suited to different kinds of data.
Assuming "relational" refers to real-world relationships
It actually refers to the mathematical concept of a "relation," which is just the formal term for a table. The everyday idea of tables relating to each other through foreign keys is real and important, but it's not where the word "relational" in "relational database" comes from.
Best Practices
- Say "SQL" when talking about the language or skill, and name the specific database system only when a difference actually matters.
- Write queries in standard SQL first, and reach for a database-specific extension only once you actually need it.
- Default to a relational database for a new project unless you have a specific, identified reason to reach for NoSQL.
- Get comfortable with at least two SQL database systems early, MySQL and PostgreSQL cover most jobs and most of what you'll read online.
Interview Questions
What actually makes a database "relational"?
Data is organized into tables (formally, "relations") with a fixed set of typed columns, where every row shares the same structure, and where tables can be explicitly connected to each other through foreign keys rather than nesting or duplicating data inside one record.
Name three SQL database systems and one thing that differentiates each.
MySQL: the most widely deployed, especially in web hosting and WordPress-style stacks. PostgreSQL: stronger standards compliance and more advanced features, popular for new production apps. SQLite: no server at all, a database is a single file, used for learning and embedded apps.
What's the difference between SQL and NoSQL, and when would you choose each?
SQL (relational) databases enforce a fixed table structure and make relationships between tables explicit, a good fit when data is structured and consistent, orders, accounts, inventory. NoSQL databases cover several looser models (document, key-value, graph) that scale more easily and tolerate records with varying shapes, a better fit for logs, caching, or very large, fast-changing data.
Is SQL a standard, and who maintains it?
Yes, SQL is standardized by ISO and ANSI. Database vendors implement that core standard and then add their own extensions on top, which is why two databases can both be "correct SQL" and still differ in places.
Summary
This lesson covered how a relational database organizes data into tables of rows and columns, where SQL sits between your application and the database engine that actually stores the data, why SQL (the language) is a separate thing from MySQL, PostgreSQL, and the other systems that implement it, and how SQL databases differ from the NoSQL databases that solve a different kind of data problem.
What's Next?
The next lesson gets a real database running on your machine, comparing SQLite, PostgreSQL, and MySQL, and picking the one with the least setup friction so you can start running the queries in this course yourself.