Somewhere in the finance department there's a workbook with eighty-some tabs. Nobody built it in a weekend. It grew the way coral grows: one polyp at a time, over years, until the shape of the thing had nothing to do with any plan and everything to do with whichever problem needed solving on whichever Tuesday. One tab per month going back to 2019. A "Lookups" tab that fifteen other tabs quietly depend on. A tab literally called "DO NOT TOUCH" that three people touch regularly, carefully, holding their breath.
Nobody in that department would tell you they run a database. They'd tell you they have a spreadsheet, maybe an annoyingly complicated one, maybe one that "really needs a proper system" filed under someday. But functionally, that's exactly what it is: the single place where the department's numbers live, get looked up, get combined, and get reported on. It's doing a database's job. It never had a database's design, and nobody ever decided it should.
That gap is where the pain lives. Not in Excel being bad at math, it isn't, but in a tool built for one person thinking through one problem at a time quietly getting promoted, tab by tab, into infrastructure it was never engineered to be.
A database is a promise, not a file format
The difference between a spreadsheet and a database was never really about rows and columns - Excel has plenty of both. It's about what the tool guarantees once you start relying on it.
A database promises, roughly, that a piece of data lives in exactly one place and everything else refers to it rather than copying it. That the shape of the data is enforced - a customer ID column cannot suddenly start holding names, because the schema says so. That two people can write to it at the same time without one of them silently overwriting the other. That there's a record of who changed what, and when.
A spreadsheet promises none of that. It's astonishingly good at looking like it does, right up until it doesn't. A cell can hold a number, then a name, then a formula that returns an error, then a hardcoded 0 someone typed over the error to make it go away, and Excel will not stop you at any point in that sequence. Two colleagues can have two "final" versions of the same file open on two laptops, both saving, both correct in their own head. There is no lock, no conflict warning, no merge, only whichever version got saved last, silently.
That's not a defect in Excel. It was built to be a fast, flexible personal calculator that anyone could pick up. Every one of those guarantees it lacks is a guarantee it deliberately doesn't need for that job. The problem starts when the job changes underneath it.
What breaks once the workbook is doing a database's job
Somewhere around tab thirty, the eighty-tab workbook stops being a big spreadsheet and starts being the system of record for the department, and every guarantee it's missing turns from a shrug into an incident.
Someone renames "Q3 Actuals" to "Q3 Actuals FINAL v2" to keep an informal backup. Forty formulas across six other tabs were pointing at the literal string "Q3 Actuals." Most of them don't error - they were wrapped in IFERROR two years ago by someone trying to make a different problem look tidy, so they quietly return 0 instead. Nobody sees a red triangle. The regional total is wrong for a month, until someone reconciles it against a total that came from somewhere else and can't work out why the two disagree.
Two managers each keep a "master" copy on their own laptop, emailed back and forth as an attachment because there's no shared source of truth to write to. Both are right in isolation. Neither is right in aggregate. The merge, when it happens, happens by hand, at 6pm, by whoever noticed the discrepancy first.
A lookup column that used to be unique quietly stops being unique - two products end up with the same SKU because someone "fixed" a typo by adding a row instead of correcting the original - and every VLOOKUP built on the assumption of uniqueness starts silently returning the first match instead of the right one. A real database would have refused to let that duplicate exist, because a primary key says it can't. A spreadsheet has no opinion. It returns an answer, and the answer isn't flagged as suspect.
None of these are edge cases. They're the default behaviour of a tool with no schema, no constraints, and no concurrency control, once enough weight gets put on it.
Why nobody notices the line being crossed
This is the part that actually explains why careful people end up here: each step across that line looks, at the time, like the smallest possible addition. One more tab for this month. One more lookup to pull in a number that lives somewhere else. One more IFERROR to stop a red triangle from alarming someone in a meeting. None of those individually is a decision to build a database. Each one is a five-minute fix to whatever was in front of someone that day.
And Excel never says no. There's no moment where the tool refuses the eighty-first tab, or warns that a formula now depends on twelve other tabs that depend on twelve more. Every database and application framework you could compare it to has some version of a schema check or a build step that stops you and says this doesn't hold together. Excel's calculation engine will cheerfully recompute a workbook that has become, structurally, a haunted house, and hand back numbers with the same calm confidence it had when the file was three tabs and half a year old.
The tool looking like it's still working is the actual trap. Cells still turn green. Formulas still calculate. Nothing about the day-to-day experience of using the workbook signals that it crossed a threshold - the pain only shows up later, downstream, in a total that doesn't reconcile or a report that took someone's entire Thursday to explain.
Frequently Asked Questions
Does this mean I should never use Excel for anything that matters?
No. Excel is genuinely excellent at what it's for: a fast, flexible surface for one person or a small group to think through a problem. The issue isn't Excel handling important work, it's Excel quietly becoming the only system of record for a department without anyone deciding that on purpose.
How do I know if my workbook has already crossed the line?
Ask who could rebuild it from scratch if it disappeared tomorrow. If the honest answer is one specific person, and it would take them a week, it has already crossed. A real system of record survives the person who built it leaving.
Isn't this the same idea as "always back up your files"?
No - backups protect you from losing the file. This is about the file itself no longer having the guarantees you assume it does, even while it's sitting right there, being saved correctly, every day.
Does moving to Power BI or a proper database fix all of this immediately?
It fixes the structural gaps - enforced schema, a single source of truth, real concurrency - but only if the underlying data gets modelled properly first. Pointing a nicer tool at the same eighty-tab mess produces a better-looking version of the same problem.
What's the first real step, practically?
Stop treating "pull the data in" and "shape the data" as the same step done by hand inside the workbook. That separation is the whole idea behind Power Query from Scratch, Part 1: The mental model nobody teaches you - it's the natural next read if this piece landed for you.
The way to think about it
The way to think about it isn't "spreadsheets bad, databases good." It's that every piece of software makes an implicit bet about what it will and won't guarantee, and Excel's bet was never a database's bet. That's not a flaw to fix, it's a fact to respect. The moment a workbook starts being asked to guarantee things it never promised, one true version, enforced structure, safe concurrent access, the right response isn't another IFERROR or a more elaborate naming convention for "FINAL v2" files. It's noticing that the job has changed and going to find a tool that actually makes those promises, which, for the parts of this workbook that are really a fact table and a handful of dimensions wearing eighty tabs as a costume, is exactly what building a star schema from a single flat file is for (landing 28 July).