When Google Sheets stops being enough

Google Sheets is genuinely excellent, and its greatest strength is also the reason teams overextend it.

Because sharing is effortless, Sheets becomes the default home for anything more than one person needs. That works far longer than it should, and then it stops — usually in one of four specific ways.

Ceiling 1: performance

Sheets slows down in a way that is hard to predict, because it depends less on row count than on formula complexity. A sheet with 50,000 simple rows can be fine. A sheet with 8,000 rows and a few hundred ARRAYFORMULA, QUERY and IMPORTRANGE calls can be painful.

The signs: a lag between typing and appearing, "Still loading…" on open, and — the real tell — someone switching to manual calculation "for speed". From that moment, the numbers on screen may not reflect the data, and people make decisions from a stale display without knowing it.

IMPORTRANGE is the most common culprit. It is also the thing people use to fake a relational model, which brings us to the next ceiling.

Ceiling 2: structure

Sheets has no types. A column holds numbers until someone types "n/a", and then every calculation on it silently changes behaviour. Data validation helps but is easy to bypass with a paste.

The consequence is that the shape of your data depends on everyone being careful, forever. In a team of three that works. In a team of fifteen with occasional contractors, it does not.

The second structural gap is relationships. Sheets has no way to say "this row refers to that row". You approximate it with VLOOKUP or IMPORTRANGE, both of which are text matching with a set of specific failure modes — trailing spaces, moved columns, silent wrong answers when wrapped in IFERROR.

Ceiling 3: permissions

Sheets permissions are file-level, with a partial escape hatch: protected ranges.

Protected ranges work for "do not edit this column". They do not work for:

• Each salesperson sees only their own accounts.
• The contractor sees the project but not the margin.
• A supplier sees their own orders and nobody else's.

The common workaround is a separate sheet per person or per client, fed by IMPORTRANGE. That multiplies files, multiplies the performance problem, and means the "restricted" data is one un-shared link away from being visible. It is a workaround, not a control.

Ceiling 4: one view for everyone

Sheets is a single grid. Filter views help — they let you filter without disturbing others — but they do not give you a calendar, a board, a timeline or a map over the same rows.

So teams make copies. And copies diverge, always.

The same job, both ways

One list of 3,000 deliveries, and three people who need to look at it differently. Dispatch wants this week on a calendar. The warehouse wants it grouped by status. The finance lead wants a total per region.

One grid cannot be three shapes, so the list becomes three artefacts. Sometimes that is three tabs driven by QUERY formulas, which work until somebody inserts a column and every one of them silently shifts. More often it is three copies, and from the moment the second one is made the honest answer to "how many deliveries are outstanding?" is "which file are you looking at?".

The relational answer is that a view is a lens, not a copy. The same 3,000 rows carry a calendar, a board grouped by status, and a report totalling by region — each saved, each with its own filters and column order, all reading the same records. Correct a delivery date once and it is corrected on all three, because there is only ever one row.

The thing to take from this is what a copy actually costs. It is not the disk space or the tidiness; it is that the moment a second copy exists, every number needs a footnote saying which file it came from. A tool that cannot show one dataset several ways will make you produce those copies, and no amount of discipline stops them drifting.

Ceiling 5: sign-off

There is a fifth ceiling that arrives later and hurts more, and it is the one that finally moves finance data off a sheet: a sheet cannot hold a decision still.

You can colour a row green. You cannot stop it being edited afterwards, know who approved it, require two people, or lock a whole month once it is closed. Every one of those becomes a convention enforced by people remembering — which works right up until the quarter somebody does not.

Approval workflows that actually hold covers what sign-off has to do to be worth anything, and the eight questions to ask of whatever you move to.

What to do at each ceiling

Performance: first, clean up. Replace IMPORTRANGE chains with a single consolidated pull, and swap volatile functions for static values where the history does not change. This buys real time and costs an afternoon. If the sheet is still slow after that, the problem is structural rather than fixable.

Structure: if the sheet has relationships in it — and the tell is a tab whose only job is joining two other tabs — no amount of tidying fixes it. That tab is a relationship maintained by hand, and hand-maintained relationships break.

Permissions: if you are splitting files to control access, stop. That approach gets less safe as it grows, not more. This ceiling alone justifies moving.

Views: if there are copies of the file, you have already hit it.

Where Sheets stays the right answer

Do not over-migrate. Sheets remains the best tool for:

• Ad-hoc analysis and one-off questions.
• Financial modelling and scenarios.
• Quick shared lists that will not outlive the quarter.
• Anything where the value is in the calculation.
• The output of a report, for someone who wants to pivot it themselves.

It is also unbeatable for the thing it invented: giving someone a link and having them contributing thirty seconds later. Nothing in this category matches that.

Moving the operational half

The pattern that works is a split, not a replacement:

• Records move to a relational tool: customers, inventory, projects, applications, assets.
• Analysis stays in Sheets, reading from the records rather than owning them.

If your relational tool has an API, connect Sheets to it so analysts keep their environment while the source of truth moves. The analyst stops being the person who merges everyone's edits and goes back to analysis. This is usually an easier internal sell than "we are replacing Sheets", because it is true and it is better for them.

The migration, briefly

1. Identify the entity tabs and the join tabs. Entities become tables; join tabs become real relationships and then get deleted.
2. Deduplicate while importing. Match on email, SKU or reference — not on name. See why every table needs a stable ID.
3. Replace typed names with relation fields.
4. Replace VLOOKUP with lookups and manual totals with rollups.
5. Rebuild only the views people use. Ask; half the tabs will turn out to be nobody's.
6. Point the analysis sheet at the new source and delete the copies.

One workflow at a time. The first one takes an afternoon; the rest go faster because you have learnt the shape.

The check before you start

Two questions worth answering honestly:

Is this relational, or just big? A single large flat list — a mailing list, a log — is not a relational problem. It might just need a tool that handles volume better, or none at all.

Is the pain structural, or is the sheet just messy? Sometimes a two-hour cleanup is the right answer and a migration is not. If nobody has tidied it in two years, tidy it first. You will make a better decision afterwards, and occasionally the decision will be "actually this is fine".

Next: spreadsheet vs database, or seven signs your spreadsheet has become a database.