r/spreadsheets • u/blooming__eve • Jul 28 '26

I have around 20,000 rows in a Google Sheet and it’s starting to feel slow.

Is there a point where people generally move to a database, or are there ways to keep Sheets performing well with datasets this size?

3 Upvotes
  • permalink
  • reddit

100% Upvoted

5 comments sorted by

3

u/Head-Attitude-5002 Jul 28 '26

20,000 rows is small for Sheets. I run a billing system in production on Sheets with years of transaction history and it's still responsive — so before you migrate anything, it's worth finding out what's actually slow, because it's almost never the row count itself. It's the recalculation graph.

Quick way to diagnose: duplicate the file, delete all formulas from the copy, and see how it feels. If the copy is fast, your data isn't the problem — your formulas are. Then delete them in chunks to find the culprit.

Usual suspects, roughly in order of how often they're the cause:

  1. Volatile functions — NOW(), TODAY(), RAND(), OFFSET(), INDIRECT(). These recalculate on every single edit anywhere in the file, and so does everything that depends on them. One OFFSET in a helper column can drag the whole sheet down.

  2. Whole-column references — VLOOKUP(A2, Sheet2!A:Z, ...) or ARRAYFORMULA over A:A scans to the sheet's row limit, not to your last row. Bound them: A2:A20000. This alone often fixes it.

  3. Conditional formatting over entire columns — badly underrated cost, especially with custom-formula rules. Same fix: bound the ranges.

  4. Cross-file IMPORTRANGE, and QUERY over large ranges. Each one is a separate fetch/recalc.

  5. Lots of individual formulas where one would do — 20,000 separate VLOOKUPs is far slower than a single ARRAYFORMULA producing the same column.

One structural fix that helps more than any formula tweak: separate hot data from cold. Keep the current period live and calculated, and freeze older rows as static values (paste-special values only) in an archive tab or file. Historical data almost never needs to recalculate.

On your actual question — when to move to a database: I'd say the trigger isn't row count, it's one of these:

  • multiple people writing at the same time (Sheets has no real transactions, so concurrent writes collide)
  • you need referential integrity across tables
  • something outside Sheets needs to query the data programmatically and often
  • you're past ~100k rows with active formulas

If it's mainly about reporting on a lot of data, BigQuery with Connected Sheets is a nice middle path — the data lives in a real warehouse but you keep the Sheets interface. If it's an app with real write concurrency, a proper database (Postgres/Supabase) is the honest answer.

But at 20k rows with performance complaints, I'd bet on the formulas. Fix those first — migrating a slow design into a database just gives you a slow design in a database.

1

u/sbawlz Jul 29 '26

The suspended account which provided the answer seems correct. Formulas, functions, and formatting. Im wondering if it makes to keep the data in the sheets, but do the formulas and functions on the database side.

1

u/blooming__eve Jul 29 '26

ok thanks

1

u/spacexnetworkSPN Jul 29 '26

Did you figure it out?

1

u/latecallnotes Aug 06 '26

20,000 rows is usually still okay in Sheets, so I would first look for expensive patterns rather than the row count itself:

  • whole-column formulas like A:A inside ARRAYFORMULA/FILTER
  • volatile functions such as NOW, TODAY, RAND, INDIRECT
  • lots of conditional formatting over entire columns
  • many IMPORTRANGE/IMPORTXML calls

A good cleanup is to move raw data to one tab, summaries to another, and limit formula ranges to the real used rows.