When Google Sheets breaks as an automation backend

Google Sheets stops working as an automation backend for reasons that have nothing to do with size. Every guide on this topic tells you to move when the data gets big or the formulas get complicated. That is the wrong meter. The two things that actually break are how a row is addressed and what happens when two runs write to it at once, and both of those fail at a few hundred rows. You will hit them years before the 10 million cell ceiling means anything.

The size limits are real and almost nobody reaches them

Google's own documentation puts the cap at 10 million cells or 18,278 columns per spreadsheet, whichever you hit first, counted across every tab in the workbook rather than per tab. A 15-column operations sheet gets you to roughly 660,000 rows. If you are running a service business, that is not the wall you are going to hit.

The API quota is closer to the ground: 300 read requests and 300 write requests per minute per project, plus 60 of each per minute per user per project. Notice which number is smaller. The per-user quota is shared by every automation authenticating with the same connected Google account, so a nightly sync and a form handler and a reporting job all draw from the same 60. That is how an operator ends up with a billing sync throwing 429s because an unrelated Zap got busy. As of August 2026, Google's usage limits page also states that exceeding these quotas is planned to start incurring Google Cloud billing charges later in the year, which turns a silent throttle into a line item.

Still, quotas are a tuning problem. Batch your writes, split the connected accounts, back off on 429. None of that is a reason to migrate. The next two things are.

In Zapier and Make, the row's position is its identity

This is the part that catches people. A database row has a primary key that stays with the record forever. A spreadsheet row has a number, and that number describes where the row currently sits, not what it is.

Zapier's help documentation is explicit about it: Google Sheets triggers deduplicate on the row number. Create a row and it becomes row 100, and the Zap fires on row 100. Delete three rows above it next week and that same record is now row 97, while row 100 holds somebody else's data. Zapier lists the full set of structural edits that break the trigger, and it is longer than most people expect: deleting rows or columns, adding a row anywhere other than the bottom, sorting the worksheet, renaming or rearranging columns, renaming the spreadsheet or the worksheet, and adding frozen, hidden, or protected rows or columns.

Every one of those is a thing a normal person does to a spreadsheet on a normal Tuesday.

Platform	How it addresses the row it updates	What breaks it
Zapier	Row number. Triggers deduplicate on row number.	Deletions renumber everything below. New rows only register when appended at the bottom. Sorting, renaming, and column edits all break the trigger.
Make	Row number, a required parameter on the Update a Row module.	Any row number you carried over from a Search Rows step is stale the moment another process inserts or deletes above it.
n8n	A column you pick as the match key.	Nothing structural, but Sheets will not enforce that your match column is actually unique. Two matching rows and the node updates one of them.

n8n's approach is the right one, and it is the reason n8n survives longer on Sheets than the other two. Matching on a value rather than a position means a sort does not hurt you. It just moves the problem: now you need a genuinely unique column, and a spreadsheet has no way to guarantee one.

There is a mitigation worth doing today regardless of what you decide long term. Add an ID column, populate it with something that never changes, and match on that column instead of the row. On Zapier that means switching from the row-based lookup to a "Lookup Spreadsheet Row" keyed on your ID and accepting that structural edits still break the trigger. It buys you time. It does not fix the next problem.

No unique constraint, no row lock, no error

A database will refuse to insert a second row with the same email if you told it not to. Sheets will not. It will happily hold four rows for the same customer and report no problem, which is why deduplication on a spreadsheet is always a workflow step you had to remember to build rather than a guarantee the storage gives you. We wrote about the general version of this in how to stop an automation from creating duplicates, and the spreadsheet case is the worst version of it, because there is nothing underneath to catch what the workflow misses.

The concurrency failure is quieter and worse. Two runs read the same row. Run A computes a new status, run B computes a new phone number, both write the full row back. The later write wins and the other change is gone. No error is raised, no retry fires, nothing shows up in the run log except two successful executions. You find out weeks later when someone asks why a customer's status reverted.

Google Apps Script does ship a real mutex for this in LockService, and it works. It also only protects code running inside Apps Script. A write arriving from Zapier, Make, or n8n through the Sheets API does not participate in that lock and cannot be made to. So the tool that solves the problem is unavailable to the tools that cause it.

If your automations overlap in time at all, and most scheduled ones do, read why the same record gets processed twice before you assume you are safe. Overlap plus no lock is exactly the lost-update recipe.

How to tell a tuning problem from a migration signal

Not every Sheets complaint means you have to move. Here is how to tell them apart.

What you see	What is actually happening	Verdict
The Zap stopped firing after someone tidied up old rows	Row-number deduplication lost its place when the rows renumbered	Fixable. Append only, never delete. Move if people genuinely need to edit the sheet.
A record shows one value in the sheet and a different one in the CRM	Lost update. Two runs read the same row and both wrote it back.	Move. There is no setting that fixes this.
Occasional 429 errors that clear on their own	You crossed 60 write requests per minute for that connected Google account	Fixable once. Batch the writes, split the account, add backoff.
Two rows for the same customer	No unique constraint. Nothing prevented the second row.	Fixable with a match step. Move if the sheet is the system of record.
The sheet takes 20 seconds to open	Volume plus live formulas recalculating	Fixable. Kill the ARRAYFORMULA and VLOOKUP columns first. Rarely the real reason to move.

Three of these five are tuning. Two of them are structural, and both structural ones can be true at 300 rows.

If the table does not settle it, run three tests against the sheet in front of you. Any single yes on the first two means the spreadsheet is no longer the right place for that data.

The address test. Pick a record. If somebody sorts the sheet by a different column, can your automation still find that exact record? If the answer depends on where the row sits, you do not have identifiers, you have addresses, and addresses move.

The writer test. Count everything that can write to the same row: each automation, the web form, the person doing corrections on their laptop. If that count is above one and their timing is not coordinated, you already have lost updates. You just have not found them yet, because nothing reports them.

The quota test. Add up writes per minute per connected Google account across every automation, at your busiest hour, not your average one. Above 60 and you are one heavy morning away from 429s.

How to move without giving up the spreadsheet

The reason operators resist this migration is not technical. It is that the sheet is where their team actually works, and every proposal to move sounds like taking it away. So do not take it away.

Put the system of record in a real database, Postgres or a managed equivalent, with a primary key and a unique constraint on whatever identifies a customer for you. Point every automation at the database. Then write a read-only mirror back into the same spreadsheet on a schedule, regenerating it rather than patching it. The team keeps the view they know. The automations stop competing with humans for the same cells, which is what was causing the lost updates in the first place.

That inversion is the entire fix, and it takes less work than the migration people imagine. The pattern is the same one behind deciding which system holds the data of record: pick the place where the value is authoritative, and make every other copy downstream of it.

Two things to get right while you do it. Backfill a stable ID onto the existing rows before you migrate anything, because reconciling later without one is genuinely painful. And leave the old sheet in place, renamed and read-only, for a month. You will want it the first time a number looks wrong.

Where to start this week

Do the writer test first. It takes ten minutes and it is the one that finds silent damage. Open the sheet's version history, filter to the last two weeks, and look for cells that changed twice within the same minute from different sources. Every one of those is a write that may have overwritten a change nobody knows about.

If you find any, that is your answer, and the size of the sheet is irrelevant to it. If you find none and your only complaint is speed or the occasional 429, tune what you have and revisit in six months. When you do decide the data needs a real home, our data intelligence work covers the migration and the mirror-back pattern, and workflow automation covers repointing the runs that currently read the sheet. If you want a second opinion on which of the three tests your sheet is failing, send us the shape of it and we will tell you straight.