What is the row limit in Google Sheets?

There is no fixed row limit. A spreadsheet is capped at 10 million cells in total, so the number of rows you can have depends on how many columns you use. At 26 columns that works out to roughly 384,000 rows. The cap covers all tabs in the spreadsheet, and blank cells count.

Why is my Google Sheet so slow when it is not that big?

Usually formulas rather than size. Volatile functions such as NOW, TODAY, RAND, and INDIRECT recalculate on every single edit anywhere in the file. Whole-column references like VLOOKUP over A:Z scan every row including the empty ones. Conditional formatting and heavy IMPORTRANGE chains add more work on top.

Does deleting empty rows speed up Google Sheets?

Yes, in two ways. Blank cells count toward the 10 million cell cap, and whole-column formulas evaluate across them. Deleting unused rows and columns, rather than just clearing their contents, reduces both.

When should I move off Google Sheets?

When you are optimising the spreadsheet rather than working on the data. If you are deleting columns to buy headroom, splitting tabs to keep it responsive, or telling colleagues not to open it while you work, the tool has become the project.

Why Google Sheets slows down with large datasets

There is a specific moment, familiar to anyone who has run a business on a spreadsheet, when Google Sheets stops feeling like software and starts feeling like weather. You type a value. The cell sits empty. A spinner appears in the corner. Four seconds later your value shows up, along with the recalculated results of nine hundred formulas you had forgotten were there.

Everyone’s first theory is that the file is too big. Usually it isn’t. The size is what makes the real cause expensive.

What are the actual limits?

A Google Sheets spreadsheet is capped at 10 million cells — raised from 5 million in 2022 — and that budget is shared across every tab in the file. There is no separate row limit; rows and columns trade against each other out of the same pool. At 26 columns you get roughly 384,000 rows. At 100 columns, about 100,000. You can have up to 18,278 columns (out to ZZZ) and up to 200 tabs.

The detail that catches people: blank cells count. A tab created with the default 26 columns and 1,000 rows has already spent 26,000 cells whether or not you have typed anything into it. Ten mostly-empty tabs are not free.

But almost nobody reaches 10 million cells. They get to two million and the file becomes unusable, which means the cap is not the thing hurting them.

Why does it get slow long before the cap?

Because a spreadsheet is a reactive program that runs in your browser, and it is running the whole program on every keystroke.

Sheets maintains a dependency graph: this cell feeds that formula, which feeds that chart. When a value changes, everything downstream of it is recalculated. That is the feature — it is the entire reason spreadsheets are useful. It is also why a file gets slow in a way that has little to do with row count and a lot to do with how the formulas are written.

Four things do most of the damage:

Volatile functions. NOW(), TODAY(), RAND(), RANDBETWEEN(), and INDIRECT() recalculate on every edit anywhere in the file, and so does everything that depends on them. One TODAY() feeding a column of 50,000 date comparisons means 50,000 recalculations every time anyone types anything.
Whole-column references. VLOOKUP(A2, Sheet2!A:Z, 4, FALSE) asks Sheets to consider every row of that range — all the empty ones too. Bound the range: Sheet2!A2:Z50000. This one change is frequently the whole fix.
Conditional formatting. Each rule is a formula evaluated against every cell in its range, on every render. Rules applied to entire columns, and rules layered on rules, cost more than people expect for something that only changes a colour.
IMPORTRANGE chains. A sheet that pulls from a sheet that pulls from a sheet is a distributed system with no error handling, and it is being evaluated in a browser tab.

Add collaborators and every one of them is running this same recalculation locally while also receiving everyone else’s edits.

How do you speed up a slow Google Sheet?

In rough order of how much they usually buy you:

Delete unused rows and columns. Not clear them — delete them. This shrinks both the cell count and the range that formulas sweep across.
Bound every range. Replace A:A with A2:A50000 everywhere.
Remove volatile functions from anything that fans out. If you need today’s date, put TODAY() in one cell and reference that cell.
Replace lookup columns with a single QUERY where you can. One formula returning a range beats 50,000 formulas returning a value each.
Convert finished formulas to values. If last quarter is closed, it does not need to be recalculated for the rest of time. Paste-special as values only.
Split reference data into its own file and stop importing it live.

Done thoroughly, this reliably takes a four-second edit down to something usable. It is worth doing. It is also, and this is the part worth being honest about, a treatment rather than a cure. You have not made the spreadsheet capable of holding the data. You have made it cheaper to recalculate a thing that should not be recalculating.

When should you stop optimising and move the data?

Here is the test I would apply: are you working on the data, or on the spreadsheet?

If you are deleting columns to buy headroom, splitting tabs to keep the file responsive, converting formulas to values to stop the recalculation storm, or asking a colleague not to open the file while you are in it — the tool has quietly become the project. Every hour spent there is an hour not spent on the question the data was supposed to answer.

The other signal is structural. Spreadsheets are a flat grid; they have no concept of a column having a type, or a value being required, or a row being related to a row somewhere else. Once you find yourself enforcing those rules by convention and vigilance — a note at the top of the sheet saying please enter dates as YYYY-MM-DD — you are hand-rolling a database with no constraints and no undo. That data is going to get messy, and the cleanup has its own reliable order.

What changes when the rows live in a database?

The reason Sheets recalculates the whole file in your browser is that the whole file is in your browser. That is the design. It is what makes a small spreadsheet feel instant.

Tablitsa inverts it. Import a CSV or XLSX file and the rows are parsed and stored in a database. The grid holds the rows you are looking at and fetches more as you scroll, so what your browser is doing does not grow with the size of the sheet. Columns have real types, detected on import. Filtering and sorting happen against stored data rather than against a live formula graph. And because the rows are in a database, you can ask questions of them in plain English — a total, a breakdown, a filtered view — instead of writing a formula and hoping the range was right.

It is not a replacement for a spreadsheet in every respect: if your file is small and it is mostly formulas doing modelling, Sheets is the right tool and will stay the right tool. Tablitsa is for the other case — the sheet that is really a table of records, that has quietly grown to hundreds of thousands of rows, and that three people need to be in at once.

Sheets per workspace and rows per sheet are capped by plan (1,000 rows on Free, 100,000 on Pro, 1,000,000 on Team), and collaboration is a paid feature: Free is solo, Pro adds 3 collaborators, Team adds 10.

If you recognised the four-second edit, import the sheet and have a look. It costs you an upload to find out whether the problem was the data or the container.