Google Sheets as a Database: When It Works and When It Breaks

Related: Automated Reporting: How to Replace the Monday Spreadsheet

Most businesses do not decide to use a spreadsheet as a database. It happens gradually. A sheet for leads. A column for status. A script that adds rows from a form. Five people with edit access. One day it is running the business.

That is not a mistake. Sheets is a genuinely good place to start. The mistake is not noticing when it has stopped being one.

When Sheets works well

• A few thousand rows, not hundreds of thousands
• One or two people editing, rarely at the same moment
• Flat data: one row is one thing, with no links between tables
• Everyone who can see it is allowed to see all of it
• Mistakes are cheap and easy to fix by hand

Early lead tracking, simple inventories, content calendars, small event sign-ups. Sheets is excellent for all of these.

The real limits

Size

A spreadsheet can hold up to 10 million cells across all its tabs. You will feel it long before that. Heavy formulas, lookups across large ranges and imports between files make it slow well under the limit.

API quotas

Automations talk to Sheets through its API, which has per minute limits on reads and writes, both per project and per user. At the time of writing, reads and writes are each limited to 300 requests a minute per project and 60 a minute per user. Check Google's current quota page. A busy form, a sync tool and a reporting script together can hit those limits and start failing.

Script limits

Apps Script runs have a maximum execution time of 6 minutes. Scripts triggered on a schedule also share a daily total runtime. Long jobs have to be split up or moved elsewhere.

The problems that actually hurt

No safe concurrent writes

Two scripts, or a script and a person, writing at the same moment can overwrite each other or land rows in the wrong place. There are no transactions. Apps Script has a locking feature that helps with scripts, but it does not stop a person editing at the same time.

One sort can corrupt everything

Someone selects one column and sorts it. That column is now in a different order to every other column. Every row is quietly wrong. It happens more often than anyone admits, and nothing flags it.

No enforced structure

A date column accepts "next Tuesday". A price column accepts "TBC". A status column has "Won", "won" and "Won " with a trailing space, and every report counts them as three different values.

No relationships

Customers, orders and invoices are related things. In Sheets they become lookups between tabs that break when someone inserts a column or renames a tab.

All or nothing permissions

Sharing works per file. You cannot let a sales rep see only their own leads, or hide the margin column from one person, without splitting the data into separate files.

A weak audit trail

Version history and per-cell edit history exist, but answering "who changed this customer's status, when, and what was it before" across thousands of rows is hard.

Signs you have outgrown it

• People are scared to sort or filter the main sheet
• There is a tab called "DO NOT EDIT" and people edit it
• You have copies called "Leads FINAL" and "Leads FINAL v2"
• Automations fail on some days and nobody knows why
• It takes several seconds to open or recalculate
• You need to hide some data from some people
• A wrong number in it has already cost you money

Two or more of these and it is time to plan a move.

What to move to

• A no-code database tool. Keeps the spreadsheet feel and adds proper field types, links between tables and better permissions. Good next step, though these have their own row and automation limits.
• A real database with an admin interface. For example PostgreSQL, with an internal tool or a spreadsheet-style front end on top. Proper structure, safe concurrent writes, fine-grained permissions, and room to grow. See choosing a database.
• A purpose-built app, when the spreadsheet is really a CRM, an order system or a booking system in disguise. Sometimes an existing product fits. Sometimes it needs building.

How to move without breaking things

1. Write down what the sheet actually does. Every tab, every formula that matters, every script, every form or tool that writes to it, and every report that reads from it.
2. Clean the data first. Fix types, remove duplicates, standardise the status values. Moving messy data into a real database just produces a messy database that now rejects half of it.
3. Move the writes first. Point forms and automations at the new database.
4. Keep Sheets as a view. Sync the data back to a read-only sheet for the people who like it. Reporting in Sheets is fine. Sheets as the source of truth is the problem.
5. Run both for a short overlap and compare numbers before switching off the old writes.

Moving a business off a spreadsheet is one of the most common jobs we do. If yours is creaking, show us what it does and we will tell you honestly whether it is time. Also see automating data entry.