Module 3: Databases & SQL Basics | MLOps & Data Engineering

"SQL is the language of data. Learn to ask a database questions, and half of data engineering opens up to you."

Level: Intermediate · Time: ~4 days · Prerequisites: Module 2

Learning Objectives

By the end of this module, you will be able to:

Explain what a relational database is
Read and write basic SQL queries
Distinguish SQL from NoSQL databases
Understand indexes and why queries can be slow

A relational database stores data in tables (rows and columns), where tables can relate to each other via shared keys. A customers table links to an orders table through a customer_id. This structure is decades-old, battle-tested, and everywhere.

Concept: The "relational" part is the superpower: you store each fact once and join tables to answer questions that span them — customers and their orders, products and their reviews.

2. SQL: Asking Questions

SQL (Structured Query Language) is how you talk to relational databases. The core query reads almost like English:

sql

[object Object], name, total
,[object Object], orders
,[object Object], total ,[object Object], ,[object Object],
,[object Object], ,[object Object], total ,[object Object],;

"Give me the name and total from orders where the total exceeds 100, biggest first."

Clause	Does
`SELECT`	Choose columns
`FROM`	Pick the table
`WHERE`	Filter rows
`JOIN`	Combine tables
`GROUP BY`	Aggregate (sum, count)
`ORDER BY`	Sort

Try this: In plain English, ask "how many orders did each customer make?" Then map it: SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id. Translating questions into SQL is the skill to practice.

A JOIN is worth seeing in action, since it's where relational databases earn their name. Suppose you want each order alongside the customer's name — but names live in a separate customers table. You link them on the shared key:

sql

[object Object], customers.name, orders.total
,[object Object], orders
,[object Object], customers ,[object Object], orders.customer_id ,[object Object], customers.id;

The database matches each order to its customer row and stitches the columns together. This is why you store a customer's name once (in customers) instead of copying it into every order — you join to bring it back when you need it.

3. SQL vs NoSQL

Not all data fits neat tables. NoSQL databases trade strict structure for flexibility and scale:

Type	Good for
Relational (SQL)	Structured data, complex queries, reliability
Document (NoSQL)	Flexible JSON-like records
Key-value	Fast lookups, caching
Graph	Highly connected data (Module on GNNs)

Concept: It's not "SQL vs NoSQL, pick a winner." Each fits different jobs. Relational databases remain the default for most business data; NoSQL shines for flexibility, huge scale, or special shapes.

4. Why Queries Get Slow (Indexes)

Without help, a database scans every row to find matches — fine for thousands of rows, painful for billions. An index is like a book's index: it lets the database jump straight to relevant rows.

Common mistake: Wondering why a query is slow on a big table with no index. Adding an index on the columns you filter or join on can turn minutes into milliseconds — but too many indexes slow down writes, so index deliberately.

The trade-off is real: every index is a separate structure the database must update on every insert or change. On a table that's mostly read (like historical orders), generous indexing is great. On a table hammered with writes, each extra index is a small tax on every write. The craft is indexing the columns you actually search or join on — and no more.

5. Databases in the Pipeline

Databases are both sources (where app data originates) and destinations (where cleaned data lands). Nearly every pipeline reads from or writes to one, so SQL fluency is foundational to everything ahead.

This is also why SQL is the single highest-leverage skill in the field: the very same query language works whether you're pulling from a tiny app database, a giant cloud warehouse, or a query engine sitting on top of a lake. Learn it once and it transfers almost everywhere, which is why later modules keep coming back to it.

Explain like I'm new: If data is a library, the database is the shelving system and SQL is how you ask the librarian for exactly the books you want — by author, topic, or year — without wandering every aisle.

✅ Checkpoint

What makes a database "relational"?
What do WHERE and JOIN do in SQL?
What problem does an index solve?

Answers: 1) Data lives in tables that relate to each other through shared keys, so you store facts once and join to combine them. 2) WHERE filters rows; JOIN combines rows from multiple tables. 3) It lets the database find matching rows quickly instead of scanning every row.

Key Takeaway: Relational databases store data in linked tables, and SQL is the near-English language for querying them (SELECT … FROM … WHERE … JOIN … GROUP BY). NoSQL options trade structure for flexibility and scale, each fitting different jobs. Indexes keep queries fast on large tables. Since pipelines constantly read and write databases, SQL fluency underpins the rest of this track.

Further Learning

Part of "MLOps & Data Engineering." Original content for this learning platform.