Google Sheets Limits: What You Need to Know Before Using Sheets as a Database

The numbers Google publishes

Google documents the limits for Google Sheets directly:

• 10 million cells per spreadsheet — this is the hard ceiling across all tabs combined
• 18,278 columns maximum per sheet (the column limit is derived from the spreadsheet column naming scheme, not an arbitrary cap)
• No explicit row limit — you are bounded by the 10 million cell ceiling divided by your column count
• 100 editors / 1,000 viewers per spreadsheet for sharing
• 256 MB is the point at which Google warns you about file size; it is not a hard cutoff but performance degrades noticeably above it

The 10 million cell limit is the one that catches people. If you have 50 columns and fill the sheet, you hit the limit at 200,000 rows. With 100 columns, you hit it at 100,000 rows. With 20 columns — which is typical for a product catalog or a CRM export — you have room for 500,000 rows.

Where performance actually degrades before you hit the hard limit

The hard limits are less dangerous than the gradual performance degradation that precedes them.

Formula recalculation slows down noticeably above roughly 50,000 rows if you have VLOOKUP, SUMIF, ARRAYFORMULA, or similar functions operating across the full range. The sheet becomes sluggish to open and edit. This is a Google Sheets UI problem, not an API problem — the API response time is largely unaffected.

API response time through SheetsAPI stays reasonable up to the limit of 1,000 rows per request. The limit parameter caps any single response at 1,000 rows. Above a few thousand total rows, use offset pagination to walk through the data in pages. That is not a workaround — it is the intended pattern.

Simultaneous editors become a coordination problem above a few dozen. Google Sheets handles concurrent editing gracefully for small teams. At scale, the shared editing model breaks down and you want a real database that can enforce write ordering.

The practical ceiling for SheetsAPI use cases

For the workloads SheetsAPI is designed for — content tables, configs, product listings, team directories, form responses — the realistic ceiling is tens of thousands of rows, not hundreds of thousands. By the time you are approaching 50,000 rows in a working dataset, you have almost certainly already encountered the organizational friction that signals it is time to graduate to a database.

The limit is rarely what forces the migration. The friction of editing a 50,000-row spreadsheet in a browser, the lack of relational integrity, the inability to do server-side joins — those bite first.

When to graduate to a real database

Migrate when any of these are true:

• Writes come from machines, not people — automated inserts, webhooks, event streams
• You need relational data — two or more tables with foreign keys and joins
• You need strict type enforcement or uniqueness constraints
• You are storing user-generated content at volume
• Response time SLAs matter and your dataset is growing

The honest framing: Google Sheets is a spreadsheet that happens to be queryable over HTTP. It is excellent at what spreadsheets are excellent at — human-edited, auditable, collaboratively maintained, small-to-medium datasets. The 10 million cell limit will not stop you. Your own requirements will move you on before you get close to it.

Start with SheetsAPI, ship fast, and migrate when the data earns a real database — not before.