Let me say something most engineers will not admit: using Google Sheets as a database is often the right call. Half of Indonesian SME operations run on spreadsheets, and for good reason. It is free, everyone already knows how to use it, it is accessible from any phone, and you can restructure it in seconds without calling a developer.
I have seen distribution companies track hundreds of millions of rupiah in monthly orders through a well-organized Sheet. It worked. So this is not an article telling you spreadsheets are unprofessional. This is an article about where Google Sheets as a database stops working, because the failure is rarely gradual. It works fine, works fine, works fine, and then one Tuesday your stock numbers are wrong and nobody knows why.
Knowing the failure modes in advance means you graduate calmly instead of migrating in a panic.
Why Sheets Works So Well at First
Credit where it is due. For a team of two to five people managing a few thousand rows, Sheets gives you things that even custom software often lacks:
- Zero deployment. Change a column, add a formula, share a link. Done.
- Universal literacy. Your admin staff, your warehouse lead, and your accountant all know how to filter and sum.
- Built-in collaboration. Comments, edit history, simultaneous viewing.
- Free integrations. Google Forms feeds rows in, Apps Script pushes data out.
Any replacement has to beat all of that, which is why "just build a proper system" advice from engineers often fails. The spreadsheet is winning on real merits.
Failure Mode 1: Simultaneous Edits and Silent Collisions
Sheets handles simultaneous editing at the cell level reasonably well. What it cannot handle is simultaneous business logic.
Concrete example: two admin staff both check the stock column for item A, both see 3 units available, and both record a sale of 2 units. A real database can be told "check and deduct in one atomic step." A spreadsheet cannot. Both edits succeed, your sheet now says 1 or negative 1 depending on timing, and you have promised 4 units when you had 3.
At low volume, humans catch this. At 50 or more transactions a day across multiple people, they stop catching it, and you find out from an angry customer.
Failure Mode 2: The Accidental Sort That Breaks Every Row
This one destroys more spreadsheet operations than anything else. Someone selects column C, sorts it to find something, and does not realize they sorted only that column. Now every customer name is paired with someone else's phone number and order value. Row 214's data is scattered across three hundred rows.
Version history can save you if someone notices immediately. In practice, the damage is discovered days later, after dozens of legitimate edits have been layered on top, and untangling it means a weekend of manual reconciliation.
A database makes this category of error structurally impossible. A row is a row. Its fields cannot be shuffled independently.
Failure Mode 3: No Validation, So Garbage Accumulates
A database column defined as a number will reject "2jt", "2.000.000", "2,000,000", and "dua juta". A spreadsheet accepts all of them cheerfully, and your SUM formula silently skips the ones it cannot parse.
Over months, this accumulates as sludge:
| Symptom | Root cause |
|---|---|
| Totals that do not match reality | Text stored in number columns |
| Duplicate customers | No unique constraint, "Budi S" vs "Budi Santoso" |
| Orphan records | Order rows pointing to a customer row someone deleted |
| Date chaos | 05/03/2022 meaning March to one person, May to another |
Data validation rules in Sheets help, but they are advisory and easy to bypass with copy-paste. Nobody enforces them, so nobody follows them under deadline pressure.
Failure Mode 4: Permissions Are All or Nothing
Sheets sharing has essentially three levels: view, comment, edit. Business operations need finer grain than that. Your sales team should update order status but never touch prices. Your warehouse staff should see quantities but not customer margins. Your intern should add rows but not delete them.
In Sheets, anyone with edit access can edit everything, delete anything, and download the entire file. That last point deserves attention: when an employee leaves, they may walk out with your complete customer list in their downloads folder, and you will never know. Protected ranges patch some of this, but maintaining them across a growing sheet becomes its own part-time job.
Failure Mode 5: Scale, the Boring Wall
Google Sheets caps at 10 million cells, but performance degrades long before that. Past 30 to 50 thousand rows with formulas, expect multi-second lags on every edit, failed loads on older phones, and VLOOKUP chains that take a minute to recalculate. Your team starts keeping local copies to avoid the lag, and now you have five conflicting versions of the truth, which is worse than any single failure above.
The Graduation Path, Without Panic
The signal to move is not row count. It is when the cost of errors exceeds the cost of software. Some honest thresholds from what I have seen with Indonesian SMEs:
- More than three people editing daily, or any process where two people act on the same rows.
- Money decisions made directly from the sheet, like stock commitments or credit approvals.
- More than an hour a week spent fixing or reconciling data. That is a salary line, not an annoyance.
When you hit two of those, graduate in stages:
- Stage 1, structure what you have. One sheet per entity (customers, orders, products), an ID column on everything, data validation on critical columns, protected ranges on formulas. Cost: one focused afternoon.
- Stage 2, no-code database tools. AirTable or similar tools give you real record structure, field types, and per-table permissions while keeping the spreadsheet feel. Roughly Rp 150 to 300 thousand per user per month. Fine up to a few tens of thousands of records.
- Stage 3, a small custom system on a real database, usually only for the one or two workflows where errors cost real money, with Sheets kept for everything else. A focused build like this for an SME typically lands between Rp 80 and 250 million depending on scope, and the biggest risk is not the technology, it is scope creep.
Do not jump from Stage 1 to a full ERP because a vendor scared you. Most companies I meet are not ready for ERP, and a premature one fails harder than any spreadsheet ever did.
The Practical Takeaway
Google Sheets as a database is a legitimate stage of company growth, not a mistake to be embarrassed about. The mistake is staying past the point where silent collisions, broken sorts, and unvalidated data start costing more than the software that would prevent them.
Watch for the three thresholds: multiple daily editors, money decided from the sheet, and weekly reconciliation time. Hit two, and start Stage 1 this week. The companies that get hurt are not the ones using spreadsheets. They are the ones that never decided when to stop.