Seven signs your spreadsheet has quietly become a database

Nobody decides to run their business on a spreadsheet. It happens one column at a time.

It starts as a list. Then someone adds a status column. Then a second tab for the related thing. Then a lookup formula to stitch them together. Then a third tab whose only job is to summarise the first two. Two years later it is load-bearing, one person understands it, and everyone is slightly afraid of it.

Spreadsheets rarely fail loudly. They degrade. Here are the seven signs, roughly in the order they appear.

1. You have a tab whose only job is to join two other tabs

This is the earliest and clearest signal.

The moment you build a tab that exists purely to bring together data from elsewhere — a "Master" sheet, a "Combined" tab, a "Report" tab full of VLOOKUP or INDEX/MATCH — you have started hand-building something a database does automatically.

That joining tab is a relationship, implemented manually. It has to be maintained by hand, it breaks when rows move, and it silently returns wrong answers rather than errors when a key does not match.

What it means: your data has relationships in it. The tool does not support relationships, so you are simulating them.

2. The same real-world thing exists in more than one place

Open your sheet and look for a client, product or person whose name appears on more than one tab.

Now ask: if that name changed tomorrow, how many places would you have to edit? If the answer is more than one, every one of those places is free to drift out of sync — and eventually will.

The tell is a column of names that is typed rather than chosen. "Acme", "Acme Ltd", "ACME Limited" and "Acme " (with a trailing space) are four different things to a spreadsheet and one thing to you. Every filter and pivot you build on that column is quietly wrong.

What it means: you need one record per real thing, referenced from everywhere else rather than retyped.

3. You have rules that live in your head, not in the file

"Don't put anything below row 400, the formulas stop." "Column K is only for the ops team." "If status is Won you have to also set the close date." "Never sort the sheet — the ranges are absolute."

Every one of these is a constraint the tool cannot enforce, so a human enforces it by remembering. That works until the person who remembers is on holiday, or leaves, or is simply having a busy Thursday.

What it means: you need constraints the system enforces — required fields, controlled option lists, permissions — rather than conventions people are trusted to honour.

4. Two people editing is a coordination problem

Real-time co-editing solved simultaneous typing. It did not solve simultaneous restructuring.

If someone sorts while you are typing, inserts a column your formula depended on, or filters a view and then deletes what they think are the only rows, the damage is quiet and often permanent. So teams invent protocols: one person owns the file, changes go through them, everyone else requests.

That bottleneck is the real cost. The sheet stops being a shared tool and becomes one person's responsibility.

What it means: you need per-user permissions and an audit trail, so more than one person can safely work without a human gatekeeper.

5. Everyone needs a different view, so everyone has a copy

Sales want it by rep. Finance want it by month. The founder wants a summary. The warehouse wants only the open ones.

In a spreadsheet, each of those is either a filter that fights with everyone else's filter, or — far more often — a duplicate of the file. And the moment a duplicate exists, it starts diverging from the original.

Look in your shared drive for tracker_v4_FINAL_ops.xlsx. That file is the symptom.

What it means: you need many views over one set of records, not many copies of the records.

6. Answering a reasonable question takes hours

"How much did we invoice this client last year across all their projects?" "Which suppliers have we had a late delivery from twice or more?" "What is the average time from application to offer, by role?"

These are not exotic questions. If they take an afternoon of pivot tables and manual matching, it is not because the question is hard. It is because the relationships needed to answer it are not represented in the data, so a person has to reconstruct them each time.

What it means: the structure that would make the question trivial is missing.

7. You are afraid of the file

The clearest sign, and the one people mention last because it feels unprofessional to admit.

Nobody wants to touch it. Changes are made on a copy first. There is a formula in one cell that no one can explain and everyone works around. The file takes twenty seconds to open.

Fear is a rational response to a system with no undo, no audit trail, no validation and no tests. Every edit is a small gamble.

What it means: you have outgrown it, and you knew before you read this list.

What to do about it

You do not need a rewrite. You need to move the relational part of the problem into a tool that understands relationships, and let spreadsheets keep doing what they are genuinely excellent at.

Keep in a spreadsheet: financial models, scenario planning, ad-hoc analysis, anything where the value is in the calculation and the file is disposable.

Move to a relational workspace: anything that is a shared operational record — customers, projects, inventory, applications, assets — especially where several people edit it and several entities connect.

The migration is smaller than people expect, because most of the work is deciding the structure, not moving the data. A practical sequence:

1. Name your nouns. Each becomes a table. Clients, projects, invoices — not "Data" or "Tracker".
2. Draw the links. Which noun points at which, and is it one-to-many or many-to-many? Get this right before importing.
3. Import the messiest table first. It exposes modelling mistakes while they are cheap.
4. Replace lookup formulas with real relation fields. This is where the drift stops.
5. Add rollups. The summary tab you maintained by hand becomes a field that maintains itself.
6. Set permissions, then delete the copies. The duplicates are the thing that made you afraid.

Expect to get the structure slightly wrong the first time. That is normal and cheap to fix in week two — much cheaper than a spreadsheet that has been subtly wrong for a year.

The point

The question is not whether spreadsheets are good. They are extraordinary. The question is whether the specific job you are asking this one to do — be a multi-user, multi-entity, permissioned source of truth — is the job it was built for.

If you recognised three or more of the seven signs above, it is not, and the sheet has been telling you for a while.

If you want the conceptual grounding before you rebuild, start with what a relational workspace is. If you want to understand the specific failure behind sign 1, read why VLOOKUP keeps breaking.