Google Sheets caps a file at 10 million cells over all tabs, but a working sheet breaks long before that. What is slow, which fixes buy time, when to move out.
Key takeaways
- 10 million cells and 18,278 columns (through column ZZZ) are limits on the whole file, not on one tab.
- 50,000 rows across 40 columns is 2,000,000 cells - a fifth of the ceiling. If that file is slow, capacity is not the problem.
- What slows it is the number of derived cells: every `VLOOKUP` over an open range, every conditional format rule, every volatile function that recomputes on any change.
- Apps Script is limited to 6 minutes per execution and 30 seconds per custom function. A script that touches every row will be cut off before it finishes.
- The right move is usually to move the data into a database and keep the sheet as the interface - not to replace the sheet.
Google caps a single spreadsheet at 10 million cells, shared across every tab in it. An operational sheet of 50,000 rows almost never reaches that ceiling - it becomes unusable long before, because every edit re-evaluates a dependency graph that grew alongside it. The decision point is recalculation, not capacity.
The two ceilings: the documented one and the one you hit first
The documented ceiling is clear and numeric. The practical ceiling is written nowhere, because it depends on what was built inside the file.
| Limit | Value | What it applies to |
|---|---|---|
| Cells per spreadsheet | 10,000,000 | The whole file, divided among all tabs |
| Columns | 18,278 (through ZZZ) | Per sheet |
| Characters per cell on Excel import | Over 50,000 - the cell is dropped | Excel to Sheets conversion |
| Connected Sheets pivot table | Up to 200,000 rows | A BigQuery-backed query result |
| Connected Sheets extract | Up to 500,000 rows or 5 million cells | Extracted into the sheet |
| Apps Script execution | 6 minutes | Per single run |
| Apps Script custom function | 30 seconds | Per call |
The common error is assuming each tab gets its own allowance. It does not. A file with 20 tabs divides the same 10 million cells among them, so splitting into tabs does not solve volume - it only spreads it.
What is actually slow when 50,000 rows feel slow?
Not the data. What is slow is the number of cells that must be recomputed after each keystroke. Five patterns produce most of the load:
- Open ranges. A
VLOOKUPoverA:Dis evaluated against every row the sheet allocates, not only the populated ones. - A lookup per row. 50,000 rows with two lookup formulas each is 100,000 evaluations on any change.
- Volatile functions.
NOW,TODAY,RANDandOFFSETrecompute on every change and drag every dependent cell with them. - Conditional formatting on whole columns. Each rule is a test against every cell in the range.
- Cross-file links.
IMPORTRANGEinserts a network wait into the calculation graph.
The reliable tell is that the slowness tracks the action rather than the size: opening the file is tolerable, but typing one value freezes the browser for several seconds. A sheet slow only on open is usually volume or images; a sheet slow on every keystroke is a calculation-graph problem.
The arithmetic on a real sheet
Take an orders sheet: 50,000 rows, 40 columns. That is 2,000,000 cells in one tab. Add six helper tabs of 5,000 rows by 20 columns - another 600,000. The file sits at 2.6 million cells, a quarter of the ceiling, and nobody will ever complain about capacity.
Now assume each row carries three lookups into a customers tab and a products tab. That is 150,000 lookup evaluations. If the ranges are open, each one scans the full allocated row count. The file will reach the cell ceiling in about four years - and it is already unusable today.
Fixes that buy you a year, and what each costs
- Close the ranges.
A2:D50000instead ofA:D. Cheap, immediate, but needs revisiting as data grows. - Replace a chain of lookups with one
QUERY. Fewer derived cells, harder to maintain for anyone who did not write it. - Freeze history. Move prior years into an archive tab or a separate file and convert them to values. Sheds load, gives up ad-hoc slicing over time.
- Remove volatile functions. Replace
TODAY()with a date written once a day by a script. - Narrow conditional formatting to exact ranges. Tedious, and frequently the single largest improvement.
All of these have a ceiling. They shrink the calculation graph, but they do not change the fact that every user loads all the data into their browser to look at one row.
When is this no longer a formula problem?
When the symptom moves from "slow" to "cannot be relied on". Five signals change the question:
| Signal | What it actually means |
|---|---|
| Users must be pushed out before an update can run | There is no concurrent update control |
| A script is cut off after 6 minutes | The workload exceeds the execution tool |
| Any structural change breaks another report | Data and presentation are not separated |
| Two reports disagree on the same figure | Several copies of the same fact exist |
| Only one person understands the file | The knowledge is not in the system |
The last three are not performance problems at all. They are data-model problems, and a faster spreadsheet will not fix them.
The architecture that keeps the spreadsheet as the interface
The usual transition is not abandoning the sheet but demoting it to its correct role: display and input, not storage.
- Decide which tab is the source of truth for each entity - orders, customers, products. It usually emerges that more than one claims to be.
- Move those tables into a database, with a primary key per row and an updated-at field.
- Keep the sheet as a view: it pulls the relevant slice, not the entire history.
- Move the heavy logic - lookups, aggregations, validations - to the server side, where no 6-minute ceiling applies.
- Keep data entry in the sheet if that is how people work. There is no reason to force a new screen at this stage.
The article on exceeding Google Sheets quotas in automation covers a different layer of the same problem - the API request-rate quota and the 429 response. This one is about the workbook itself. See also Airtable compared with Google Sheets and connecting Google Sheets to your other tools.
What to have ready before moving the data out
- A list of every tab and who actually writes to each one.
- The unique key identifying each row. If none exists, that is the first piece of work.
- A list of every report and external file pulling from this spreadsheet.
- A split between operational data and archive data, including the date from which history can be frozen.
- A decision on who keeps working in the sheet after the move and who moves to a screen.
Sources
Frequently asked questions
Does splitting into more tabs increase capacity?
No. The 10-million-cell limit applies to the whole file, and tabs divide that same allowance among themselves. Splitting helps with organisation and permissions, and can shrink the calculation graph if it severs dependencies, but it adds no capacity and does not speed up a file suffering from open ranges.
How many rows is "too many" in Google Sheets?
There is no such number. A 200,000-row sheet of plain values performs fine, and an 8,000-row sheet with three lookups per row over open ranges will crawl. The correct measure is how many cells recompute after a single keystroke, not how many rows exist.
What happens when a large sheet is exported to Excel?
Excel caps a worksheet at 1,048,576 rows, so most files fit. The risk is not size but conversion: functions specific to Sheets such as QUERY and IMPORTRANGE do not exist in Excel, and those links become errors or frozen values on the way across.
Does moving to BigQuery through Connected Sheets solve this?
It solves the analytical side. Connected Sheets supports a pivot table over up to 200,000 rows and an extract of up to 500,000 rows or 5 million cells without loading the data into the file. It does not solve operational input and update - that needs a database you can write to.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.