Using Google Sheets as a database: the six limits you eventually hit

Short answer: Google Sheets refuses almost nothing. That is its strength and precisely the problem. A database guarantees things: a type, a uniqueness rule, a permission, a trace. A spreadsheet guarantees none of them. The six limits below are not bugs to work around. They are the places where a spreadsheet structurally cannot help you.

1. No type is ever guaranteed

You decided a column holds dates. Sheets never agreed to that contract. Someone types "March 14", someone pastes "14/03/26" out of an email, someone else writes "mid-March". All three are accepted, and two of them will never sort correctly.

Data validation exists, but it applies to a range you defined by hand. Insert a row above it, paste 200 rows at once, duplicate the tab, and the rule does not always follow. You do not have a type. You have a convention your team honours when it remembers to.

2. Nothing prevents a duplicate

"Acme Ltd" and "Acme Ltd." are two different customers as far as your sheet is concerned. You find out the day you total revenue per customer and the number does not add up.

A spreadsheet has no concept of a unique key. You can add a formula that highlights duplicates, but it flags them after the fact, it does not refuse them. That difference is the whole point: a database rejects the write, a sheet keeps it and leaves you the cleanup.

3. Permissions stop at the sheet

Google sharing is excellent at the file level. It does not exist at the row level. If your external accountant should see amounts but not margins, or each rep should only see their own accounts, you have two options: duplicate the file, or hide columns.

Hiding a column is not a permission. It is hidden on screen, not in the export, not in the version history, not to an IMPORTRANGE from another file. Duplicating, meanwhile, creates a second version of the truth, and from then on nobody knows which one is current.

4. One volatile formula makes the whole file pay

A cell containing NOW(), IMPORTRANGE, GOOGLEFINANCE, or an ARRAYFORMULA stretched across a full column does not recalculate quietly on its own. It joins a dependency graph that Sheets re-evaluates. That is why a 4,000-row file can be slower than a 40,000-row one.

Row count is a poor indicator. What matters is the number of calculated cells and how volatile they are. We break down how many rows before a Sheet slows down separately.

5. History exists, but you cannot query it

Sheets keeps version history, and you can view a single cell's edit history. Now try answering: "who moved this order to Shipped, and when?" for one specific row, six months later, without knowing the approximate date.

You will be walking back through versions by hand. The information is there; it simply is not addressable. A database answers that question with a query. A spreadsheet answers it with archaeology.

6. No guaranteed link between two tabs

You have a Customers tab and an Orders tab, joined by a VLOOKUP. That join is not a link. It is a formula assuming the key exists. Delete a customer, rename one, insert a column in the source tab, and you get #N/A. Or worse, a shifted match that looks fine and is wrong.

Referential integrity is exactly the guarantee that an order cannot point at a customer who does not exist. No spreadsheet provides it.

What about the documented limits?

They exist, but they almost always arrive last:

If you are looking for a maximum row count, there isn't one: Google counts cells. And in practice a file becomes unpleasant to use long before it approaches any of these numbers.

When Sheets is still the right tool

Let's be clear, because half the articles on this topic are selling you a migration you don't need. Keep your sheet if:

• one person writes in it, even if ten people read it;
• you're doing calculation, analysis, pivot tables, which is where Sheets is unbeatable;
• the data is disposable: an event budget, a one-off sort, a scratch list;
• there is no rule you need enforced.

If your sheet is an order list specifically, an order tracking template hands you the columns already typed.

The tipping point is one question: is your sheet a calculation or a record? A calculation belongs in Sheets. A shared record, written to by several people, with rules, is a database, and the choice comes down to four questions.

The good news: it isn't either/or. You can keep the record in a real database and keep doing your maths in Sheets, with the file fed automatically. That's exactly what Rowbase does: entry is typed and attributed, and every row lands back in your Google Sheet within seconds. Your formulas and charts don't move.

See the same list in Rowbase →

FAQ

How many rows can a Google Sheet hold? There is no row limit, only a cell ceiling per file. Usability degrades well before that, and it depends on your formulas rather than your row count.

Isn't data validation enough to type a column? It helps, but it applies to a manually defined range and doesn't always survive insertions, bulk pastes, or tab duplication. It isn't a guarantee.

Can you grant access to a single row in Google Sheets? No. Protection applies to a sheet or a range, and hiding is not protecting. You'd have to duplicate the file, which creates a second source of truth.

Should you migrate as soon as you hit one of these limits? No. One annoying, workaroundable limit doesn't justify a migration. Two or three that come back every week does.