What Is MySQL?
Before installing anything or typing a single query, it's worth being clear about what MySQL actually is and why it's built the way it is. MySQL is a relational database management system — usually shortened to RDBMS — a piece of software whose entire job is to store data in an organized, predictable shape and let you ask precise questions of it later using SQL (Structured Query Language). Once you understand the "relational" part, every later lesson in this track — tables, keys, joins, normalization — starts to feel like a natural consequence of one simple idea rather than a pile of separate rules to memorize.
A Relational Database, In Plain Terms
In MySQL, data lives inside tables — grids of rows and columns, similar in
shape to a spreadsheet at first glance. Each table is dedicated to one kind of thing. Over the
course of this track we'll build a small movie-streaming catalog called StreamHub,
and it will need a table for its users, a table for its movies, a table for genres, and so on.
Every row in the movies table is one movie; every column (title,
release_year, duration_minutes) describes one attribute of it.
What makes this "relational" is that tables don't just sit next to each other in isolation — they're connected. A review in StreamHub isn't just a floating rating and comment; it's tied to one specific user and one specific movie through keys, and MySQL actively enforces that those connections stay valid. You can't casually leave a review pointing at a user who doesn't exist. That enforcement is the whole point of a relational database, and it's explored in full in Primary & Foreign Keys later in this track.
Why "Relational" Is the Important Word
Picture tracking StreamHub's data in a single spreadsheet instead — one giant sheet with a row per review, and columns for the reviewer's name, their email, the movie title, its release year, the rating, and the comment, all repeated on every single row. Nothing stops you from typing "Jon Doe" on one row and "John Doe" on another for the exact same person. Nothing stops a movie's release year from being entered three different ways across three different reviews. There's no mechanism forcing consistency — the spreadsheet just holds whatever you type.
A relational database fixes this by storing each user once, in the users table,
and each movie once, in the movies table. A review simply references
them by id. Change a username once and every review that points at that user automatically
reflects it, because nothing but the reference itself was ever duplicated. This is the core
trade a relational database makes: a small amount of upfront structure (deciding what tables
and keys you need) in exchange for data that can't quietly drift out of sync with itself.
A First Look at StreamHub's Tables
Since StreamHub is the running example for this entire track, here's the full shape of it up front. You don't need to memorize this — it's here so that every table mentioned in later lessons already has a home to click back to.
| Table | Holds | Key columns |
|---|---|---|
users | People with a StreamHub account | id, username, email, signup_date |
movies | The catalog of movies available to watch | id, title, release_year, duration_minutes |
genres | The list of genre names (Drama, Sci-Fi, ...) | id, name |
movie_genres | Junction table linking movies to their genres | movie_id, genre_id |
reviews | A user's rating and comment on a movie | id, user_id (FK), movie_id (FK), rating, comment, review_date |
watchlist | Movies a user has saved to watch later | id, user_id (FK), movie_id (FK), added_date |
Notice that movie_genres exists purely to connect two other tables — a movie can
belong to several genres, and a genre obviously applies to many movies, so a single foreign key
column on either side can't express that relationship on its own. This "junction table" pattern
is covered in depth in Primary & Foreign Keys.
Here's a preview of the kind of query this structure makes possible, once these tables actually exist:
-- A preview: users and the movies they rated highly (we build these tables starting next lesson)
SELECT u.username, m.title, r.rating
FROM reviews r
JOIN users u ON u.id = r.user_id
JOIN movies m ON m.id = r.movie_id
WHERE r.rating >= 4;That single query pulls a username, a movie title, and a rating out of three different tables at once — safely, because the relationships between them are guaranteed by the database itself rather than by hoping nobody ever mistypes anything.
MySQL Compared to Other Databases You've Heard Of
MySQL isn't the only database out there, and it's worth knowing roughly where it sits next to the other names you'll run into.
| Database | How it relates to MySQL |
|---|---|
| PostgreSQL | Another hugely popular open-source RDBMS. It speaks a very similar dialect of SQL to MySQL, with its own extensions and stricter behavior in a few corners — most SQL knowledge transfers directly between the two. |
| MongoDB | A NoSQL, document-based database — not relational at all. Instead of rows in tables connected by keys, it stores flexible, self-contained JSON-like documents. A good fit when your data doesn't naturally break into clean, related tables. |
| SQLite | A lightweight, serverless, file-based database — the entire database lives in a single file with no separate server process to run. Great for small apps and embedded use cases. See the SQLite track on the Database hub as it becomes available. |
| MariaDB | A close relative rather than a competitor — see the dedicated section below. |
Who Actually Runs MySQL
MySQL's popularity isn't just a claim — it's backed by decades of real, heavy production use. Facebook's early infrastructure ran on MySQL at a truly enormous scale. WordPress, which powers a huge share of the websites on the internet, stores every post, page, and comment in a MySQL (or MariaDB) database — see this site's own WordPress track for how that works from the inside. And countless PHP and Laravel applications, including the examples in this site's PHP track and Laravel track, reach for MySQL as their default database. If you've used the web at all in the last two decades, you've almost certainly touched data that passed through MySQL at some point.
MySQL vs. MariaDB
You'll frequently see MySQL and MariaDB mentioned in the same breath, and for good reason. When Oracle acquired MySQL, several of MySQL's original developers forked the project and named it MariaDB. It remains largely compatible with MySQL — the same core SQL syntax, the same client tools, and often the same connection drivers work against either one without changes. Many Linux distributions even ship MariaDB as the default when you ask for "mysql-server." The two have since diverged in some newer features, but everything you learn in this track carries over to MariaDB almost without exception. Its own dedicated track is listed as "Coming Soon" on the Database hub.
When You'd Reach for Something Else Instead
MySQL is a strong default, but it isn't the right tool for every job. If your data is genuinely unstructured or deeply nested — think a document that might have wildly different fields from one record to the next, like flexible user-generated form submissions — a document database like MongoDB will usually fight you less than forcing that shape into rigid tables. And if you're building a small, single-user, embedded application that shouldn't need to run and manage a separate database server at all, SQLite's single-file simplicity is often the better fit. For StreamHub — a catalog of movies, users, and reviews with clear, stable relationships between them — a relational database is exactly the right shape, which is why it's the example running through this entire track.