Why Python for analytics (and when to stay in SQL or Sheets)

You do not need Python for every analysis. You also do not need to apologize for using Python when a spreadsheet would force you into a maze of copy-paste steps. The real skill is choosing the right surface for the job: Sheets, SQL, or Python, without turning tool preference into identity.

This is Part 1 of Python for analytics, a series for people who already speak spreadsheet and a bit of SQL, and who want to open a notebook without panic. We start with judgment: when Python earns its keep, when it is overkill, and how the tools combine in a sane weekly workflow. If you are building foundations first, pair this with Analytics foundations and the practical path in From spreadsheets to real data.

What you will learn

Example:

• When Sheets still wins (and you should stop “learning Python” for that task)
• When SQL is the cleaner home for the work
• When Python is the tool that saves hours, not the tool that impresses LinkedIn
• The hidden cost of switching tools mid-analysis
• Simple workflow combinations you can use Monday morning
• The roadmap for Parts 2 through 10 of this series

Three tools, one decision problem

Most analytics work is not “write code.” It is: get trustworthy rows, shape them for a question, check the answer, and hand something off. Sheets, SQL, and Python all do versions of that. They differ in where the data lives, how repeatable the steps are, and how painful the next person will find your work.

Think of them as three desks in the same office, not three religions.

• Sheets are a visible grid. Great for small tables, quick math, shared review, and “can we try this filter live in the meeting?”
• SQL is a question language against data that already sits in a database or warehouse. Great when the source of truth is large, shared, and versioned by people who care about access control.
• Python is a general-purpose environment. With libraries like pandas, it treats tables as programmable objects: load, clean, join, loop, model, export. Great when the path from raw file to answer is a short script you want to rerun without clicking.

If you only remember one sentence from Part 1: pick the tool that matches grain, size, and reuse, not the tool that matches your insecurity.

When Sheets wins

Example:

Stay in Sheets when the table is small enough to see, the logic is light, and collaboration is half the point.

Classic wins:

• A budget scenario with ten line items and three what-if cells the CFO wants to poke.
• A meeting where five people need to sort, comment, and spot a wrong category in real time.
• A one-off list: “here are 40 vendors, flag the ones over $5,000.”
• Exploratory layout work for a slide: you are still deciding what the story is.

Sheets also win as a handoff surface. Many stakeholders will never open a notebook. Exporting a clean CSV into a shared sheet for review is not failure. It is product thinking. The spreadsheet series on this site exists partly because messy multiplayer sheets become liabilities. That does not mean “never Sheets.” It means know when the grid is a sketchpad versus a fake warehouse.

You might not need Python yet if your weekly job is: download a 2,000-row report, add two columns, pivot by region, and paste into a deck. Forcing pandas onto that workflow can cost more in setup time than it saves, especially before your environment is stable (that is Part 2).

When SQL wins

SQL wins when the data is already in a system designed for many users and many rows. Filtering, joining, and aggregating close to the source is usually faster and safer than downloading everything into a laptop and hoping your local copy is still “the” copy.

Classic wins:

• Warehouse tables with millions of events where you only need last month’s orders for two countries.
• Definitions that should live once: “active customer” as a view everyone can query.
• Joins across systems that already land in the same warehouse (CRM, billing, product).
• Auditable extracts: the query is the recipe, and the database enforces permissions.

If your team already has solid SQL habits from something like the SQL series (or your company tutorials), lean on them. Python is a poor first substitute for “I do not want to learn joins.” Joins in pandas are the same logic with different syntax. Moving confusion into a new language does not remove the confusion.

SQL also wins for stable metrics pipelines. When finance needs the same revenue cut every Monday, a warehouse query or scheduled transformation is usually more trustworthy than a personal script someone might forget to run. Python can sit after SQL, or schedule itself, but “default home” for shared truth is often the warehouse.

When Python wins

Python earns its keep when the work is awkward in a grid, awkward as pure SQL, or you need a repeatable local pipeline from files and APIs into a clean output.

Classic wins:

• Messy files: multi-sheet workbooks, weird headers, mixed date formats, “notes” columns that need parsing.
• Repeating the same ten cleaning steps every week on a vendor export.
• Logic that is easier as small functions: “for each customer, pick the first paid invoice after trial end,” with edge cases.
• Mixing data work with other code: calling an API, writing a report file, light stats, or (later) charts and models.
• Exploratory analysis where you want a log of what you tried, not a fragile chain of sheet tabs named after your mood.

Python is also the bridge when SQL got you 80% of the way and the last 20% needs programming. Pull a filtered extract with SQL, shape it in pandas, export a summary table for the deck. That hybrid is normal professional work, not a failure of purity.

Use the chooser as a conversation starter with yourself, not as a law. Edge cases exist. Your company tools matter. Still, if you cannot say which box you are in, pause before opening a new tab or a new notebook.

Decision matrix: tool by job

Here is a practical matrix. “Primary” means start there. “Secondary” means a common next hop. “Usually skip” means you can, but you are often paying a tax.

Notice the pattern: Sheets for small and social, SQL for large and shared at rest, Python for messy and repeatable on the laptop (or in a job runner). The middle of the matrix is where hybrids shine.

The cost of switching tools

Every hop has a tax: export time, format bugs, lost context, and the classic “which file is latest?” tax. Switching is not free just because it is familiar.

Common expensive hops:

• SQL to Sheets for everything. You pull 400,000 rows because filtering in the sheet “feels easier,” then the sheet freezes and the definition of active users drifts as people edit cells.
• Sheets to Python as a status symbol. You rewrite a five-minute pivot as a twenty-line script you do not yet know how to debug, and the meeting starts without you.
• Python to email CSV without a contract. You send “results_v3.csv” with silent row filters nobody can see. Next week, someone multiplies the wrong total.

A healthy rule: switch tools when the new tool removes a real friction you already felt, not when a blog post made you feel behind. If SQL already returns the monthly summary, stop. Paste it. Go outside.

Another cost is cognitive load. Each environment has its own failure modes. Sheets: accidental edits and formula drag errors. SQL: wrong join grain and silent duplicates. Python: environment mess, path issues, and “it works on my machine.” Paying all three taxes in one afternoon is a great way to ship nothing.

Workflow combinations that work in real jobs

Here are patterns you will see on healthy teams. Steal them.

1. SQL extract, Python clean, Sheets share

Query the warehouse for the narrow slice you need. Clean and aggregate in Python. Export a small table for stakeholders to review in Sheets. You keep heavy lifting off the grid and keep review friendly.

2. Python for files, SQL for the landing zone

A vendor drops CSVs in a folder. Python standardizes them. Results load to a table. Analysts query with SQL forever after. Python is the on-ramp, not the forever UI.

3. Sheets prototype, SQL or Python productionize

You invent a metric in a sheet because thinking is faster there. Once the business agrees on the definition, you rewrite the logic as a query or a script so it stops living in one person’s Drive.

4. Stay put when reuse is low

If this analysis will never run again, the “best” tool is the one that finishes before lunch with an answer you can defend. Elegance is optional. Clarity is not.

A Monday morning decision script

When a request lands, run this short script in your head before you open a tool:

1. Where does the truth live right now? Shared warehouse, vendor CSV, or a living sheet someone edits daily?
2. How big is “all of it” vs “what I need”? If you only need two countries last month, do not download five years globally.
3. Will this run again? Once, weekly, or become a company metric? Reuse pushes you toward SQL definitions or a Python recipe.
4. Who must poke the answer? If non-technical stakeholders need live filters, plan a small sheet handoff even if Python did the heavy lift.
5. What is the cost of being wrong? High cost favors shared definitions and reviewable queries over clever local notebooks nobody else can run.

You will not always get clean answers to those five questions. You will still get better tool choices than “I saw a viral post about notebooks.” Analytics judgment is mostly matching constraints, not collecting logos of tools on your résumé.

If your workplace already standardized on one stack, respect that gravity. Teaching yourself Python at home while shipping SQL at work is fine. Rewriting the company metric layer in a personal venv without owners or tests is not rebellion. It is risk.

Worked example: same job, three shapes

Suppose you have a small sales export and you need total revenue by region for regions over $10,000. In real life the file might be huge. For teaching, imagine a tiny table.

Sheets approach: pivot region on rows, sum revenue, filter or glance for totals above 10,000. East is 11,100. West is 11,300. South is 1,500. Done. For five rows, this is obviously the right desk.

SQL approach (when this lives in a table named orders):

SELECT
  region,
  SUM(revenue) AS total_revenue
FROM orders
GROUP BY region
HAVING SUM(revenue) > 10000
ORDER BY total_revenue DESC;

That stays beautiful when orders has five million rows. You never download the universe to count a region total.

Python / pandas approach (when you have a CSV on disk and will rerun the clean every Monday):

import pandas as pd

orders = pd.read_csv("orders.csv")

by_region = (
    orders.groupby("region", as_index=False)["revenue"]
    .sum()
    .rename(columns={"revenue": "total_revenue"})
)

result = by_region[by_region["total_revenue"] > 10000].sort_values(
    "total_revenue", ascending=False
)

print(result)

Same math. Different home. The Python version becomes valuable when “orders.csv” is actually twelve files, three date formats, and a step that drops internal test orders using a rule SQL does not own yet.

And here is the Part 1 punchline as code comments: you might not need this yet.

# You might not need pandas yet if:
# 1) the table is small and shared review is the main goal
# 2) the warehouse already has a trusted view for this metric
# 3) this is a true one-off and Sheets already answered it
#
# You probably do need Python when:
# 1) the same clean steps repeat weekly
# 2) the file is messy enough that formulas become archaeology
# 3) you need a clear, rerunnable recipe from raw to deliverable

Common mistakes

• Learning Python to avoid learning grain. If you do not know what one row means, pandas will happily give you a confident wrong answer. Fix grain first (the spreadsheet and foundations series both hammer this).
• Pulling the whole warehouse into memory because “Python can handle it.” Sometimes. Often your laptop is not the warehouse. Filter in SQL first.
• Treating Sheets as a database. Multiplayer editing plus silent cell overwrites is not a storage strategy.
• Rewriting working SQL into Python for style points. Style points do not ship.
• Skipping handoff quality. Whatever tool you use, name columns, document filters, and say what one row means in the output.
• All-or-nothing identity. “I am a Python person” is not a workflow. “I use Python when the steps need a script” is a workflow.

Rule of thumb: If a stakeholder needs to poke the numbers live, prefer a small sheet. If the source of truth is large and shared, prefer SQL. If the path is messy and will run again, prefer Python.

How this series is built (C2 to C10)

Part 1 is permission and judgment. The rest is muscle memory, step by step. You can always return to Learn for the full map of series on the site.

• Part 2: Setup without tears. Install Python, pick a notebook or editor, create a virtual environment, install pandas, open a tiny CSV.
• Part 3: DataFrames as tables. Rows, columns, types, .head(), shape, rename. Map to sheets and SQL tables.
• Part 4: Selecting, filtering, sorting. The SELECT / WHERE / ORDER BY family in pandas form.
• Part 5: Aggregations and groupby. The GROUP BY family; split, apply, combine.
• Part 6: Joins and merges. Match keys without exploding rows by accident.
• Part 7: Missing data and dtypes. Nulls, dates, casting without silent wreckage.
• Part 8: A light cleaning pipeline. Small steps, top to bottom, reproducible.
• Part 9: Export and handoff. CSV, tables, and charts tools without mystery files.
• Part 10: Python and SQL together. When each wins in the same project, including how to review generated code carefully.

Plotting gets its own later stretch (think Part 11). Do not stall Part 1 waiting for pretty bars. First get the table right.

Practice and next step

Before you install anything, write three lines in a note:

1. A task you should keep in Sheets this week (small, collaborative, or one-off).
2. A task that should stay in SQL (large shared table, simple aggregate).
3. A task that is a candidate for Python (messy file, repeating clean steps, or awkward logic).

If you cannot name a Python candidate yet, that is fine. Still do Part 2 setup so the option exists. Tool choice is easier when setup is not scary.

Next: Part 2, Setup without tears, walks through install, virtual environments, and a hello DataFrame in plain language.

Quick recap

• Sheets, SQL, and Python solve related problems on different desks.
• Sheets win for small, visible, collaborative work.
• SQL wins for large shared data and stable definitions near the source.
• Python wins for messy, repeatable, programmable table work and hybrids.
• Switching tools has a real cost; switch to remove friction, not to perform expertise.
• This series will teach pandas step by step without pretending you must abandon SQL or Sheets.

Sources

• Python Software Foundation, “What is Python?”: https://www.python.org/doc/essays/blurb/
• pandas documentation, “10 minutes to pandas”: https://pandas.pydata.org/docs/user_guide/10min.html
• pandas, “Group by: split-apply-combine”: https://pandas.pydata.org/docs/user_guide/groupby.html
• Analytics Made Simple, Learn hub: https://analyticsmadesimple.com/learn/
• Analytics Made Simple, Analytics foundations: https://analyticsmadesimple.com/series/analytics-foundations/
• Analytics Made Simple, From spreadsheets to real data: https://analyticsmadesimple.com/series/spreadsheets-to-data/
• Analytics Made Simple, SQL series: https://analyticsmadesimple.com/series/sql/

Merch on Etsy

Open store →

ETL Data Science Shirt View on Etsy → Python Coder Shirt View on Etsy → Apache Flink Shirt View on Etsy → Sigmoid Function Shirt View on Etsy →