← All Kits · SQL Kit · Python Kit
How SQL and Python Work Together in Data Analysis
Every data analyst job posting asks for SQL and Python, which raises an honest beginner question nobody seems to answer directly: if both work with data, why do I need two tools? Aren't they competing? Which one do I reach for when? This guide answers that with a clear division of labor, a real project that uses both, and a straight recommendation on which to learn first.
- The one-sentence answer
- What SQL is actually for
- What Python is actually for
- The pipeline: how they hand off
- A real example: one project, both tools
- When to use which (the decision table)
- Which to learn first
The one-sentence answer
SQL works on data that is already inside a database; Python does everything around the database. SQL cannot fetch data from the internet, read a folder of files, send an email, or draw a chart. Python can do all of that, but for the core analytical moves — filtering millions of rows, joining tables, grouping and counting — a database running SQL is faster, simpler, and closer to how companies actually store their data. They aren't rivals. They're two stations on the same assembly line.
What SQL is actually for
SQL (Structured Query Language) is a language for asking questions of tables that live in a database. It is unbeatable at:
- Filtering — "only 2024 orders over $100" out of 50 million rows, in seconds.
- Joining — connecting the orders table to the customers table to the products table.
- Aggregating — revenue per region per month, computed where the data lives instead of hauling 50 million rows to your laptop.
- Defining truth — a saved SQL query is a precise, reviewable statement of how a metric is calculated.
Its boundary is just as important: SQL only sees what's inside the database. If the data you need is on a website, behind an API, or spread across 40 spreadsheets in a folder, SQL has no way to reach it.
What Python is actually for
Python is a general-purpose programming language, and for analysts that means it handles everything the database can't see:
- Collecting — calling web APIs, scraping pages, reading hundreds of files, pulling from cloud services.
- Automating — "do this same cleanup every Monday at 8am" is a Python script on a schedule.
- Analyzing beyond SQL's reach — statistics, forecasting, machine learning.
- Presenting — charts, dashboards, formatted Excel reports, emails with the numbers attached.
Python can also filter, join, and aggregate (the pandas library does exactly this), which is where the confusion comes from. The practical rule: when the data already lives in a database, do the heavy row-crunching there with SQL and let Python work with the smaller result — not the other way around.
The pipeline: how they hand off
Most real analyst work follows the same three-stage shape:
| Stage | Tool | What happens |
|---|---|---|
| 1. Collect | Python | Fetch from APIs, files, or exports; land the raw data in a database. |
| 2. Analyze | SQL | Clean, join, filter, aggregate — inside the database, where the data is. |
| 3. Present | Python (or a BI tool) | Turn the SQL results into charts, reports, or a model. |
Sometimes stage 1 is already done for you (the company database exists) and you live entirely in SQL. Sometimes stage 3 is Tableau or Power BI instead of Python. But when a job posting asks for both languages, this pipeline is why: they want someone who can go get data, not just query data someone else delivered.
A real example: one project, both tools
Finding songs the radio buried
A portfolio project asks: which songs by well-known artists did radio overlook, even though listeners loved them? Answering takes two datasets — Billboard Hot 100 chart history (what radio rewarded) and Last.fm play statistics (what listeners actually replay). Watch the pipeline:
Stage 1 — Python collects. The chart history is a CSV, easy. But the listener data only exists behind a live web API, and SQL cannot call the internet. So a ~60-line Python script reads a roster of 1,570 artists out of the SQLite database, asks the Last.fm API for each artist's top tracks (pausing politely between requests), and writes the answers to a CSV:
import sqlite3
import urllib.request
# SQL inside Python: pull the artist roster from the database
conn = sqlite3.connect("music_gems.db")
roster = [row[0] for row in conn.execute(
"SELECT primary_artist FROM known_artists")]
conn.close()
# Python-only territory: call a web API, once per artist
for artist in roster:
url = "https://ws.audioscrobbler.com/2.0/?method=artist.gettoptracks&..."
reply = urllib.request.urlopen(url) # SQL could never do this line
...
Notice the handoff in miniature: the script's second line runs a SQL query from inside Python (the built-in sqlite3 library does the bridging). The two languages literally share a script.
Stage 2 — SQL analyzes. The fetched CSV gets imported as a table, and every analytical question from there is SQL: which artists chart repeatedly (GROUP BY + HAVING), which tracks have high plays-per-listener, and the payoff query — a JOIN connecting the chart table to the listener table to find loved-but-never-charted songs. Filtering and joining hundreds of thousands of rows is exactly what the database is built for.
Stage 3 — Present. The final gem list is small enough for anything: a README table, a chart, a web page.
--, Python comments start with #. Same idea, different marker — and knowing which file you're in tells you which marker you need.When to use which (the decision table)
| You need to… | Reach for | Why |
|---|---|---|
| Filter, join, or summarize tables in a database | SQL | The database does it fastest, right where the data lives. |
| Get data from a web API or website | Python | SQL cannot make internet requests. |
| Read/combine many files in a folder | Python | SQL only sees inside its database. |
| Define a metric everyone can review | SQL | A saved query is a precise, shareable definition. |
| Run statistics, forecasts, or ML | Python | Beyond SQL's math; this is pandas/scikit-learn territory. |
| Automate a recurring job | Python (running SQL) | Python schedules and orchestrates; SQL does the data work inside it. |
| Build charts or reports from results | Python or a BI tool | Presentation happens after the query. |
Which to learn first
SQL first. Three reasons: it's the smaller language (a dozen keywords cover most analyst work), it appears in more analyst job postings than any other skill, and day one of a data job usually starts with "here's our database" — not "please build us a data pipeline." Get comfortable with SELECT, WHERE, JOIN, and GROUP BY, then add Python when you hit a wall SQL can't cross (usually: "the data I need isn't in a database yet"). That wall is the best Python motivation there is, because you'll know exactly why you're learning it.
The SQL Kit covers the core of analyst SQL — SELECT through JOINs — with worked examples, practice, flash cards, and a mock exam. The Python Kit picks up the other half: the language basics plus the pandas moves analysts actually use. Nothing to install for either.
Open the SQL Kit → Open the Python Kit →