Blog / Google Sheets Cell Limit: Max Rows, Columns, And When To Move To A Database

Google Sheets Cell Limit: Max Rows, Columns, And When To Move To A Database

Google Sheets does not have a row limit. It has a cell limit, and every row you can add is whatever is left after that budget is divided by your column count.

As of August 29, 2026, Google's official Drive documentation lists 10 million cells or 18,278 columns (column ZZZ) for spreadsheets created in or converted to Google Sheets, and the same ceiling for spreadsheets imported from Microsoft Excel. Source: Files you can store in Google Drive.

Two details in that sentence cause most of the confusion, and both are covered below: the budget belongs to the whole spreadsheet rather than to each tab, and it counts cells that exist, not cells that contain anything.

The gotcha: the budget is the file, not the tab

The limit is per spreadsheet. A workbook with twenty tabs splits one 10 million cell pool between all twenty. Google's own error message says so in plain language when you hit it: "This action would increase the number of cells in the workbook above the limit of 10000000 cells."

The second half matters more in practice. The count is of cells in the grid, not cells with data in them. A brand new tab in Google Sheets arrives as 1,000 rows by 26 columns. That is 26,000 cells consumed before anyone types a character. Add a hundred such tabs over three years and 2.6 million cells are gone to grids nobody ever filled.

This is why teams hit the wall far below the row counts they expected. The fix is unglamorous but real: delete unused rows and columns rather than clearing them. Clearing empties a cell. Deleting removes it from the count.

What your actual row ceiling is

Divide 10 million by the number of columns you keep.

Columns in use Maximum rows
10 1,000,000
20 500,000
26 (a default tab) 384,615
50 200,000
100 100,000
18,278 (the column cap) 547

That table is the honest answer to "what is the Google Sheets max rows." There is no single number, because the question is really about shape. A narrow log of ten columns holds a million rows. An operational tracker that has grown to eighty columns of status flags, dates, owners, and notes runs out at 125,000.

Worth noting: these are ceilings, not working sizes. Sheets slows well before them, particularly with volatile formulas, conditional formatting, and cross-sheet references.

The column limit

18,278 columns is column ZZZ, the end of Sheets' three-letter naming scheme. Practically nobody meets it. It appears here because it is the second half of Google's stated limit and people search for it, but if you are anywhere near 18,278 columns the column cap is not your problem.

The 20 million cell beta

On April 22, 2026, Google announced a beta that doubles the cell limit from 10 million to 20 million, for new, existing, and imported files. It is not general availability. Organizations register through a form and are allowlisted in waves, and it is offered to Google Workspace customers and personal accounts. Source: Faster performance and doubled cell limits in Google Sheets.

The same announcement covers performance work: spreadsheets opening up to 30% faster, and filtering and conditional formatting up to 60% faster on files above 1 million cells.

If your spreadsheet is at 9 million cells and growing slowly, this beta may be the whole answer. If it is at 9 million cells because it became the place the business runs, doubling the ceiling buys time rather than solving anything.

Google Sheets API limits

Automation usually meets a different wall. As of August 29, 2026, Google documents the Sheets API at 300 read requests per minute per project and 60 per minute per user per project, with the identical figures for writes. There is no daily cap as long as you stay inside the per-minute quota, and quota increases can be requested through the Google Cloud console. Source: Google Sheets API usage limits.

One forward-looking item on that page is worth planning around: Google states that exceeding the quota request limits is planned to incur charges to your Google Cloud billing account later in 2026.

The per-user quota is the one that surprises people. A single service account driving several integrations is one user, so five tools sharing one credential share 60 requests per minute between them.

Connected Sheets has its own numbers

If you are pulling from BigQuery to get past the cell limit, Google's limits page lists 200,000 rows for pivot tables and 500,000 rows or 5 million cells for extracts in Connected Sheets. Source: Files you can store in Google Drive.

Connected Sheets is a good answer for analysis on data that lives somewhere else. It is not a way to make a spreadsheet into an operational system, because the records still live in BigQuery and the spreadsheet is a view of them.

One more import detail

When an Excel file is converted to Sheets, any cell holding more than 50,000 characters is removed rather than truncated. Source: Files you can store in Google Drive. If long-form notes live in a column of your spreadsheet, check that column after a conversion rather than assuming it survived.

What usually breaks before the cell limit

Very few teams actually hit 10 million cells. They stop trusting the file first.

The pattern is consistent. A sheet becomes the official record for a recurring process. Then people need to know which columns they are allowed to edit. Then someone downloads a copy to work on, and now there are two. Then a formula gets overwritten by a paste and nobody notices for a week. Then a person who needs to see two columns is given access to all forty because sharing is per file.

None of that is a capacity problem. It is a structure and permissions problem, and adding cells does not touch it.

Stay in Google Sheets when

  • The work is calculation, analysis, modelling, forecasting, or charting
  • The file is a working document rather than a system of record
  • Flexibility matters more than rules, and the shape changes constantly
  • The people editing it are few and know its conventions
  • It is temporary, or its output feeds something else

Sheets is genuinely excellent at this job and there is no reason to leave it.

Consider a database-backed workspace when

  • The spreadsheet is the official source for a process the business depends on
  • Different people should see and edit different things
  • Records need files, comments, owners, tasks, due dates, and a real history
  • Intake happens by someone typing into a row and should not
  • Integrations read and write the file on a schedule
  • You are managing the file's size rather than the work in it

The signal is not the row count. It is that the team has started working around the file.

Where InfoLobby fits

InfoLobby is one option when a spreadsheet has become operational. Each account gets a managed MySQL database and file storage, then tables, typed fields, forms, views, tasks, comments, activity history, automations, and a REST API on top.

Capacity is counted in records rather than cells, which removes the empty-grid arithmetic entirely: 250,000 records on the $29 Starter plan, 1,000,000 on Team, and 5,000,000 on Business, all with unlimited users. You can also connect your own MySQL server when the data already lives there.

The comparison worth reading before switching anything is the best Google Sheets alternative for small business, which covers where Sheets is still the better tool.

A practical first move

Do not migrate the spreadsheet. Migrate one process out of it.

  1. Pick the tab that causes the most rework, not the largest one.
  2. List the columns that are actually fields, and the ones that are notes to a human.
  3. Decide who needs to read, who needs to edit, and who only needs to submit.
  4. Rebuild that one workflow with a form for intake.
  5. Run both for a fortnight, then retire the tab.

The migrations that go badly are the ones that treat a spreadsheet as rows and columns. By the time you are reading a page about cell limits, it is usually more than that.

Bottom line

Google Sheets caps a spreadsheet at 10 million cells and 18,278 columns, the pool is shared across every tab, and empty grid counts against it. Your real row ceiling is 10 million divided by your columns.

If you are close to that number, delete unused rows and columns first, and look at the 20 million cell beta. If you are close to it because the spreadsheet became how the business runs, the cell limit is the symptom rather than the problem.

Related reading: when to move from Google Sheets to a database, Airtable record limits, and stop using spreadsheets as your system of record.

FAQ

What is the Google Sheets row limit?

There is no fixed row limit. Google documents 10 million cells per spreadsheet, so the row ceiling is 10 million divided by the number of columns in use. With 20 columns that is 500,000 rows. With 100 columns it is 100,000.

Is the 10 million cell limit per tab or per spreadsheet?

Per spreadsheet. Every tab in the file draws from the same pool, which is why Google's error message refers to the limit "in the workbook."

Do empty cells count toward the Google Sheets cell limit?

Yes. The count is of cells that exist in the grid, not cells containing data. A default new tab is 1,000 by 26, or 26,000 cells, before anything is entered. Deleting unused rows and columns reclaims them; clearing their contents does not.

What is the maximum number of columns in Google Sheets?

18,278, which is column ZZZ. This applies to spreadsheets created in Sheets and to files converted or imported from Excel.

What is the Google Sheets API rate limit?

300 read requests per minute per project and 60 per minute per user per project, with the same figures for writes. There is no daily quota if you stay within the per-minute limits.

Can I get more than 10 million cells?

Google announced a beta on April 22, 2026 that raises the limit to 20 million cells. It requires registering your organization and being allowlisted, and it is not yet general availability.

Should I move off Google Sheets because of the cell limit?

Usually not for that reason alone. Delete unused grid, split analysis from operations, and see where you land. Move when the problem is structure, permissions, history, or intake, because those do not improve with more cells.