The spreadsheet stops being a database before you notice

It started as a list. Ten customers, four columns, made in an afternoon because a proper system seemed like overkill for ten customers.

Nobody ever decided to promote it. Somebody added a column for the deposit, somebody else added a tab for last year, and at some point an automation started writing new enquiries into it, which meant it had to be correct, which meant nobody could reorganise it any more. Today it holds the price a client was quoted, the date work was agreed, and the only record of who said yes to what. It is a database. It just never had a launch, a backup policy or an owner.

The limits are published and anybody can look them up. The reason this is worth an article is that the number in the help page - ten million cells - sits decades away from the business that is reading, while something else arrives years earlier, has nothing to do with how big the file is, and produces a failure that looks like nothing at all.

When does a spreadsheet stop being a database?

At the point where somebody would be in trouble if the file were wrong, which usually happens years before any limit is anywhere near. There is no moment, no message and no line in the file to mark it, so the transition is only ever noticed in hindsight.

Here is what that transition looks like from the inside. An app once wanted a Google Sheets integration - a quick button to push rows from the database into a spreadsheet. A few years pass, and the spreadsheet holds 470,000 rows with twenty-odd columns, is used almost daily, and the job of replacing it sits in the backlog until the day it hits a row or cell limit and suddenly becomes urgent.

Do the arithmetic, because nobody in that situation has. 470,000 rows at twenty columns is 9,400,000 cells against a published ceiling of ten million, and twenty is the floor. The file is at 94% of its maximum at the very least, it is used almost daily, and the work of replacing it is sitting in a backlog behind things that feel more pressing. Nothing is broken. Everything about the situation says "later".

That is the shape of the problem: a slow approach to a wall that nothing counts down to, with no dashboard and no documented warning, while the business becomes more dependent on the file every week.

What are the published ceilings?

Every one of these tools states its limits in its own help pages. Collected together, in the units each vendor chose:

Tool	Published ceiling	Where it bites
Google Sheets	"Up to 10 million cells or 18,278 columns (column ZZZ)"	The whole file, all tabs together
Excel, desktop	"1,048,576 rows by 16,384 columns" per worksheet	Per worksheet, not per file
Excel in a browser, from SharePoint	0-100 MB of file; 0-10 MB if opened from an email attachment	File size, not rows
Airtable	1,000 records per base on Free, 50,000 on Team, 125,000 on Business	Counted across all tables in the base
Notion	"Each Notion database can hold up to 250,000 rows"	Per database

Two conversions are worth doing before reading further. Google's ceiling is counted in cells, not rows, so the number of rows it allows depends entirely on how wide your sheet is: ten million cells is 833,333 rows at twelve columns, 500,000 rows at twenty, and 200,000 rows at fifty. Widening a sheet moves the ceiling towards you without adding a single record.

Excel's grid, by comparison, is enormous - 1,048,576 by 16,384 works out to over seventeen billion cells per worksheet, roughly seventeen hundred times Google's whole-file limit. But most small companies do not meet Excel through the desktop application any more; they meet it as a file in SharePoint opened in a browser tab, and there the limit is not a row count at all. Microsoft's page is blunt about what happens: a workbook that is too large "will either not open in a browser window, or let you edit or refresh data in the browser."

Airtable's numbers are the ones that surprise people, and they matter for a reason that comes back at the end of this article.

Why is the cell limit probably not your problem?

Because for a business of the size that reads this, the cell ceiling is decades away, and it has moved away twice already.

Forty patients a day, one row per visit, twenty columns: over 250 working days that is ten thousand rows a year, two hundred thousand cells, about 2% of Google's ceiling. At that rate the clinic fills its sheet in roughly fifty years. Change the units to viewings, or to class bookings, or to jobs booked by a two-van trade business, and the arithmetic lands in the same place. It stays decades away even if you are ten times busier than the example.

The ceiling has also been rising. Google raised it "from up to five million cells to up to ten million cells" in March 2022, having noted in the same announcement that "Over the course of the last four years, we've been steadily increasing the cell limit in Google Sheets: from 2 million to 5 million in 2019 and now to 10 million." In April 2026 it went further and opened a beta "to give users early access to doubled cell limits in Google Sheets—from 10 million cells to 20 million cells", with registrations "processed in waves".

So the size limit is real, published, and years away for the reader of this article. A second limit is much closer, and it has nothing to do with how big your file is.

The ceiling that actually arrives is a speed limit

The limit that reaches small businesses is on how many times per minute anything may read from or write to the sheet. Each of those touches is one request - fetching a row, adding a row, clearing a tab - and the allowance is counted in requests per minute. Google publishes it as a small table, and the numbers are lower than most people guess.

Read requests: 300 per minute per project, and 60 "Per minute per user per project". Write requests: the same, 300 and 60. Google explains the consequence in one worked example:

Sheets API has per-minute quotas, and they're refilled every minute. For example, there's a read request limit of 300 per minute per project. If your app sends 350 requests in one minute, the additional 50 requests exceed the quota and generates a 429: Too many requests HTTP status code response. If this happens, you should use an exponential backoff algorithm. After 1 minute, you can execute requests again.

Sixty per minute per user is one per second. An automation that writes rows one at a time, handed two hundred form submissions at once, needs two hundred write requests, which is three and a third minutes of writing at best - while every other automation, dashboard and person touching that sheet competes for the same allowance.

Two details on that page deserve the attention of an owner rather than a developer. The quota can be raised, but "Applying for an adjusted quota doesn't guarantee approval", and the request is made through a developer console. And the arrangement is changing: "All standard use of the Google Sheets API is available at no additional cost. Exceeding the quota request limits is planned to incur charges to your Google Cloud billing account later in 2026." Planned, not in force - but a thing that is free today and metered before the year is out belongs on somebody's list.

Which of your processes has quietly come to depend on one file, and what that would cost you in the week the file stops keeping up - that is the first half of the process audit: what can be automated, in what order, and what each piece is worth, in writing, in three business days.

Why does a sheet with a hundred rows get throttled?

Because the rate limit counts requests, not records, so a tiny sheet in a busy automation hits it while a huge sheet in a quiet one never does. Somebody described exactly this on the n8n community on 2 October 2025:

I keep running into issues where my automation errors and says Google Sheets is receiving too many requests from me, but I never have more than 100 rows and in some cases it errors at the first step of clearing the sheet, which only has a single input...

Nothing is wrong with their file. The size of the data has no bearing on the number of requests made to fetch it, and an automation that reads a sheet, loops over the rows and writes each result back can burn through sixty requests in a handful of records.

There is a stranger version of the same problem, and it belongs in this article because no amount of care with your own file prevents it: a workflow throttled by "The service is receiving too many requests from you" on a single execution, with the quota message naming a Google Cloud project the user never created and their own project showing no usage at all.

The per-user allowance is documented as "per user per project", and on a hosted automation platform the project can belong to the platform rather than to you. The mechanics of being slowed down by somebody else's traffic are covered in more detail in what happens when another app rate-limits your automation; the point here is narrower. Some of the ceiling belongs to whoever hosts your automation, and your own tidiness only reaches the part that is yours.

What does your automation do when it hits the limit?

Something specific, published, and easy to miss. Make documents its own behaviour as a table, and the top-left cell is the one that matters for a business, because it describes the most common setup: a scheduled scenario without the optional feature that stores failed runs.

In that configuration, Make states: "Make pauses the next scenario run for 20 minutes." and "Make doesn't rerun the incomplete execution."

Read the second sentence again. The rows that were supposed to be written are not written, and there is no second attempt. Nothing is broken in the automation itself: it will run again in twenty minutes and behave perfectly. Whatever was in flight at the moment the limit was reached is simply absent from the sheet, and nothing on Make's page promises anybody an email about it.

Make's own guidance on avoiding the problem contains the other half of the story: "If you require frequent scenario runs, such as one run per minute, lower the number of records processed per run. A limit of up to 20 records per run is recommended to avoid exceeding rate limits." Twenty records a minute is a safe speed, and it also means a backlog of two thousand rows takes a hundred minutes to clear. The automation runs an hour and forty minutes behind, and the dashboard someone is looking at is that far out of date. Nothing reports a failure, because by the tool's own terms there was not one.

Zapier documents a comparable ceiling of its own - "Zap workflows with instant triggers will encounter 429 errors if they exceed 20,000 requests every 5 minutes per user", 429 being the code a service returns when it is being asked too often. Zapier does send a message in one specific case, and it is worth knowing which case that is. When a large batch arrives at once, Zapier holds it: "if you have 100+ events that trigger a Zap at once, Zapier will hold them for you. ... You will receive an email requesting you to confirm these actions should run." That email is about a flood of incoming events, not about a rate limit from Google. This is the everyday version of an automation failure nobody was told about: the failure is documented, the behaviour is deliberate, and the record simply does not appear.

Two help centres, two sets of numbers

Here is a small thing that tells you how much of this a business owner is expected to reconcile on their own.

Google publishes 300 requests per minute per project and 60 per minute per user per project. Zapier's help page for getting started with Google Sheets lists, under its limitations, "6,000 read requests per minute per user" and "1,800 read requests per minute per user" - the same label twice, with two different numbers, neither of which matches Google's.

Which of those is stale, which is a typo, and whether they describe something else entirely, I could not establish, and the research behind this article did not settle it either. What is verifiable is the position it leaves an owner in. Two help centres, both official, both about the same connection, publishing numbers that are an order of magnitude apart - and the error message, when it arrives, quotes neither of them in language anybody outside the trade would recognise.

The cell that disappears on the way in

One limit does not wait for scale at all, and it is the only one in this article that destroys data rather than delaying it.

When a spreadsheet is converted from Excel into Google Sheets, Google's help page states plainly: "When you convert a document from Excel to Google Sheets, any cell with more than 50,000 characters will be removed in Sheets."

Removed. Not truncated, not marked, not left with a note in the corner - the verb is Google's. Fifty thousand characters is a lot of text, roughly twenty pages, so this will never touch a column of dates or amounts. It is aimed at the one column that some businesses care about most: the notes field, where somebody has been pasting the full text of email exchanges, scope agreements, or what a client asked for on the phone, for years, in the same cell.

Excel's own per-cell limit is 32,767 characters, which sits below Google's deletion threshold, so a cell filled in Excel itself cannot reach it. The rule bites the files Excel did not write: a .csv, or a workbook produced by another system, where nothing enforced that cap on the way in. And the moment of loss is a file conversion - the least suspicious operation in the working week.

Slowness is the early warning, and it is not written down

Long before any ceiling, a sheet used as a database gets slow. That is not an impression; the vendor has effectively confirmed it by treating it as a problem worth fixing.

In April 2026 Google announced performance work aimed at exactly this, and the threshold it chose is the interesting part. The announcement says users "can now open and start working in large spreadsheets (1M+ cells) up to 30% faster" and "can now filter large spreadsheets (1M+ cells) up to 60% faster". One million cells is a tenth of the published ceiling. A company shipping a speed programme for files at a tenth of the limit is telling you where the discomfort starts.

The people running those files describe it the same way every time, and the description is more useful than any number: a main spreadsheet with hundreds of tabs that runs into the cell limit, and that takes forever to update - change one thing and wait minutes for the cells to catch up; a browser showing gigabytes of memory for one file and formulas that take hours to run.

Slowness is the honest early warning, and it arrives with no number attached, so it gets treated as a personal inconvenience rather than as information about a system the business depends on.

Does anything tell you that you are getting close?

One of the tools in this article documents a warning as you approach its limit, and it is not the one most small businesses are using.

Notion's help page describes both stages: "Approaching the limit: You'll see a warning in your database that you're getting close. You can still add rows." And then: "At or over the limit: You won't be able to add new rows. Requests to add rows will return an error."

That is what a designed ceiling looks like from the user's side - a signal while there is still time, then a refusal. For Google Sheets, Microsoft Excel and Airtable, the research behind this article found no documentation of a warning as a file approaches its published ceiling. That is a statement about what the vendors publish, not proof that no message ever appears on anybody's screen. But if you were hoping to plan around a documented alert, only one of the four publishes one.

Which puts the counting back with you, and the counting is not hard: a sheet's cell count is rows multiplied by columns, added up across the tabs. Doing it once a year takes ten minutes and turns an invisible ceiling into a date.

The tool you would move to may hold less

The obvious conclusion at this point is to move the whole thing into a proper database tool. It is worth checking the numbers before doing that, because they do not go the way people assume.

A Google Sheet at twenty columns holds around 500,000 rows before the cell ceiling. Airtable's Team plan holds "50000 records per base", and the limit is cumulative: "your plan's record limit is cumulative over different tables. For example, a base with one table that has 50,000 records and a base with two tables of 25000 records each would both be at the limits of the Team plan." The Free plan holds a thousand.

So the move from a spreadsheet to the tool most often recommended as its replacement can reduce your ceiling by a factor of ten, and change its character: the spreadsheet's limit is a property of the file, while the other is a property of your subscription, and it moves when the plan does. That is a different category of problem, closer to what actually happens when you hit a plan limit than to anything in this article.

Stay or move, either can be right. What decides it is what the tool does for you - structure, permissions, a record of who changed what - and knowing which number you are trading for which, instead of a vague belief that the new one holds more.

What should you check in your own sheet?

Five checks, none of which needs a developer, and all of which produce a number you can write down.

1. Find out how many times an hour anything writes to the file. The speed limit is the one you will meet first, and the answer is usually held by whoever built the automations. If nobody knows, that is itself the finding.
2. Count the cells rather than the rows. Rows times columns, summed across every tab, including the ones nobody opens. Compare it against ten million. Do it once, then again whenever the sheet gains columns, and the ceiling stops being invisible.
3. Look for the column that holds long text. Notes, transcripts, pasted correspondence. That is where the fifty-thousand-character rule waits, and a file conversion is where it fires.
4. Ask what happens to a row that fails to write. Not whether failures are possible - what specifically happens to the record. On a scheduled Make scenario in its default configuration, the documented answer is that it is not retried.
5. Decide which single sheet is a system of record, and say so out loud. Most businesses have exactly one file that would genuinely hurt to lose, and it is rarely the one with the most rows. Recording it alongside everything else that is automated turns an assumption into something a second person can check, and settles which system owns which field while everyone still agrees.

When this stops being a spreadsheet question

For most businesses reading this, the sheet is fine. It will stay fine for a long time, and replacing it early would cost more than it saves.

It stops being fine at a point that has nothing to do with size: when the file has become the only place a fact is recorded, when more than one automation writes to it, and when nobody could say what happens to a row that fails to go in. At that point the question has changed: which part of your business runs on something nobody owns, and who would notice if it stopped.

If you would rather have somebody work out which processes are worth moving off a file, which are better left exactly where they are, and what each piece is worth, that is the process audit. $299, three business days, and a written map you keep whether or not you hire us.