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.

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.