How many rows before a Google Sheet gets slow?
Row count predicts nothing. The five real causes, a four-minute diagnosis, and seven fixes ranked by what they actually buy you.
Short answer: there is no threshold. A 3,000-row file can be unusable while an 80,000-row file stays perfectly smooth. Google doesn't cap rows, it caps cells, at 10 million per file, and that ceiling is almost never what's slowing you down. What slows you down is the number of calculated cells and how volatile they are.
If you were promised a number, sorry. What we can give you is exactly what to measure.
The five real causes, in order of frequency
1. Formulas stretched across whole columns. =ARRAYFORMULA(...A2:A) on an open-ended column asks Sheets to consider every row in the file, not just the ones holding data. Multiply that by the number of columns doing it and you get hundreds of thousands of calculated cells for 2,000 useful rows.
2. Volatile functions. NOW(), TODAY(), RAND(), and GOOGLEFINANCE recalculate constantly and drag everything that depends on them along. A single =NOW() referenced by a column of calculations is enough to keep that column recalculating forever.
3. Chained IMPORTRANGE. Every import is a network call to another file. Three files importing from each other and you wait on the slowest of the three, every time you open one.
4. Cascading VLOOKUPs. A lookup column pointing at another lookup column pointing at another tab builds a dependency chain Sheets has to unwind in order. This is the pattern that blows up fastest.
5. Accumulated conditional formatting. Every rule is evaluated over its range on every change. Twenty rules stacked on whole columns often cost more than the formulas do, and nobody ever thinks to look there.
Notice what isn't on that list: the number of rows.
Measure your file in four minutes
- Count the cells you've actually created. Not your useful rows, the whole grid. If your tab runs to row 40,000 while your data stops at 1,800, you're carrying 38,200 empty rows, and they count.
- Count the cells holding formulas. In a free cell:
=SUMPRODUCT(--ISFORMULA(A1:Z50000)). Do it tab by tab. That number predicts your slowness; your row count doesn't. - List your volatile functions. Use
Ctrl+FforNOW,TODAY,RAND,IMPORTRANGEandGOOGLEFINANCE, with "also search within formulas" ticked. - Count your conditional formatting rules. Open Format, then Conditional formatting. The total is almost always a surprise.
You now have a diagnosis instead of a hunch.
The fixes, from best payoff down
Delete empty rows and columns. Select everything below your data, right-click, delete rows. Not "clear contents", delete. Best return on effort in the whole list, and it takes thirty seconds.
Bound your ranges. A2:A5000 instead of A2:A. Leave headroom, but finite headroom.
Replace volatile functions. A date frozen at entry beats a TODAY() that makes the whole file breathe. If you genuinely need today's date, put it in one cell and reference that.
Replace VLOOKUP cascades with a single QUERY(). One well-written query usually costs less than a column of lookups.
Freeze your history. Last year's rows don't need recalculating: copy them, paste as values, and move them to an archive tab, or another file entirely.
Split data from calculation. One "data" file, flat and formula-free. One "analysis" file that imports it once. Colleagues type into the first without making the second suffer.
Clean up conditional formatting. Delete orphaned rules, bound the ranges on the ones you keep.
For most files, those seven moves are the whole answer and you need nothing else.
When to stop optimising
There's a point where the problem stops being performance. You'll recognise it by these signs:
- you've already applied the fixes, and you have to reapply them every month;
- nobody but you can touch the file without breaking it;
- you had to duplicate the file for access-rights reasons;
- you spend more time maintaining the structure than using the data.
At that point the file isn't slow. It's become software you maintain alone inside a spreadsheet. That's a different problem, covered in the six limits of a Sheet used as a database. If you want to settle it, four questions are enough.
If your file is slow because it became the whole team's shared record, splitting the two jobs fixes the slowness in one move: rows live in a typed database, and your Sheet goes back to what it's best at, calculation, on clean data that arrives on its own.
FAQ
What's the row limit in Google Sheets? No limit is expressed in rows. The cap is 10 million cells per file, which is for example 400,000 rows across 25 columns. You'll meet slowness long before you meet the cap.
Why is my 2,000-row sheet slower than my colleague's 50,000-row one? Because slowness comes from calculated cells, not rows. Theirs is probably a flat grid; yours holds formulas stretched over whole columns.
Does deleting empty rows really speed things up? Yes, and it's often the most visible gain. A tab's empty rows genuinely exist as cells and get pulled into every open-ended range in your formulas.
Is switching to manual calculation a fix? It's a useful bandage while you clean up, not a long-term diet: you'll be working from stale values without noticing.
Try it on your own list.
14 days, no credit card. CSV import from Airtable in two minutes.