The question is not which tool is better
I get asked this a lot: should I be doing my analysis in a spreadsheet, a notebook like Jupyter, or should I just learn SQL and query the database directly. People usually want a single answer, one tool to standardize on. I don’t have one. I use all three, depending on what I’m trying to find out, and I switch between them in the same week, sometimes the same afternoon.
The honest answer is that these tools aren’t competing for the same job. A spreadsheet, a notebook, and a query tool solve different problems, and the mistake I see solo operators make isn’t picking the “wrong” one, it’s using one tool for everything and then wondering why the work feels harder than it should.
What a spreadsheet actually gives you
A spreadsheet is a grid you can see and touch. Every cell is visible, every formula is inspectable by clicking on it, and you can eyeball a column of numbers and immediately notice something looks off. That’s not a small thing. When I’m looking at a month of daily conversion numbers for one of my sites, I want to see all thirty rows at once, not query them into existence and then have to print or plot them to look at them.
Spreadsheets are also where I do anything that needs a human in the loop before it’s final. Say I’m building a cohort retention table by hand, pulling signup dates and cancellation dates for a small customer list. I can paste the raw numbers in, build the cohort buckets with formulas, and then sanity check each row against what I remember about that month, like a pricing change or a site outage. The spreadsheet doesn’t hide the working. Anyone, including me six months later, can click a cell and see exactly how a number was built.
Where spreadsheets fall apart is scale and repeatability. Once you’re past a few thousand rows, or once you need to run the same analysis every week without rebuilding it by hand, formulas get fragile. A single misdragged cell reference can quietly break a calculation and you won’t notice until the number looks wrong weeks later. I’ve had that happen with an MRR tracker where one row’s formula referenced the wrong column after I inserted a new row above it. Nothing crashed. It just quietly reported the wrong number for a month.
Where notebooks earn their keep
A notebook, the kind where you write code in cells and see the output right below each one, is what I reach for when the analysis has more than one step and I need to remember how I got from raw data to conclusion. This matters more than people expect. If you’re building a funnel analysis, calculating drop-off between five steps of a checkout process, you’re not writing one formula, you’re writing a sequence of transformations: filter to the date range, group by step, count uniques, calculate the ratio between steps. A notebook lets you do that step by step, check each intermediate result, and keep a written record of exactly what you did.
That written record is the real value. Six months from now, if I want to redo the same funnel analysis for a different product, I don’t have to remember what I did. I open the notebook, change the input file or the date range, and rerun it. Try doing that reliably in a spreadsheet with fifteen interlocking formulas and no comments.
Notebooks are also where I do anything statistical, like checking whether an A/B test result is likely to be noise or a real difference. That kind of calculation is easy to get subtly wrong in a spreadsheet formula and hard to double check. In a notebook, I can write the calculation once, label each step, and print the intermediate numbers so I can see the logic held together.
The tradeoff is that a notebook has a floor. You need to know at least a little code, and if you don’t touch it for a while, you’ll spend ten minutes remembering what a given cell does before you can trust it. It’s also easy to run cells out of order and get a wrong answer without any error message telling you something’s off. That’s a real failure mode, not a hypothetical one. I’ve had notebooks that gave a different answer depending on which order I clicked “run” on the cells, because a variable from an earlier version of the analysis was still sitting in memory.
Query tools are a different kind of tool entirely
A query tool, whether that’s a SQL client hitting your database directly or a BI tool with a query builder behind it, isn’t for analysis in the same sense. It’s for retrieval. Its job is to pull the right slice of data out of a much bigger pile, fast, without you having to load the whole thing into memory or a spreadsheet first.
This is the tool I use when the source data lives somewhere I don’t control the shape of, like a production database with a customers table, a subscriptions table, and an events table that I need to join together to answer something like “what’s the CLV of customers who came in through a specific channel.” Trying to do that join by exporting three separate CSVs and stitching them together in a spreadsheet is painful and error prone. A query does it in one step, and because the logic is written as text, I can read back exactly which tables I joined and on what condition, which matters when someone questions the number later.
Where a query tool stops being useful is anything that needs judgment calls made visually, or anything iterative. If I’m trying different cohort definitions to see which one tells a clearer story about retention, I don’t want to rewrite a SQL query five times and rerun it against a live database each time. I’d rather pull one clean dataset with a query, then move it into a notebook or spreadsheet where I can experiment freely without hitting the database again.
A concrete example: chasing down a churn number
Here’s how this actually plays out. Say my churn number for one of my subscription products looks higher than expected for a given month. I start with a query, because the raw event data lives in the database and I need to pull cancellations for that specific month with the plan type and signup date attached. That gets me a clean, small dataset, maybe a few hundred rows.
From there I usually drop it into a notebook if I want to break it down multiple ways, by plan, by signup cohort, by whether they’d had a support ticket in the prior month. A notebook lets me try several cuts of the same data without retyping formulas each time, and I can keep notes right next to the code about what each cut showed.
But if I need to hand that breakdown to myself for a monthly review, or eyeball it next to last month’s numbers side by side, it goes into a spreadsheet. That’s the format I actually read on a Monday morning with coffee, not a notebook cell output and not a query result in a terminal.
None of these tools replaces judgment. A higher churn number in one segment might mean something real, or it might mean five customers in a small plan canceled in the same week for reasons that have nothing to do with the product. The tool gets you the number faster or more reliably. It doesn’t tell you what the number means.
Picking based on the shape of the problem, not the tool’s reputation
If I had to boil this down: use a query tool when the problem is “get me the right rows out of a big pile of data.” Use a notebook when the problem is “I need to do several steps in sequence and I want a record of how I got the answer.” Use a spreadsheet when the problem is “I need to see everything at once and adjust it by hand.”
Most real analysis touches all three at some point. The mistake isn’t choosing the wrong tool, it’s assuming you only get to pick one.
If you want more of this kind of plain-English breakdown of the metrics and methods that actually run a small business, from churn and MRR to how to read an A/B test without fooling yourself, you can find the rest of it on the Data Research Analysis Collection home page.
Get new guides and videos first — join the Telegram channel.