When Google Sheets Stops Scaling
The Problem
You started with one sheet. Then you added VLOOKUPs. Then IMPORTRANGE across five workbooks. Now someone on the team spends every Friday afternoon reconciling rows because two people edited the same cell. The sheet takes 12 seconds to recalculate. You’ve hit the wall.
I’ve seen this cycle across three industries — manufacturing, music, e-commerce. The tool that got you here won’t get you to the next step.
Five Signs You’ve Outgrown Sheets
1. Row count is the bottleneck
Google Sheets has a hard limit of 10 million cells. In practice, performance degrades long before that — around 30,000–50,000 rows with even moderate formulas. If you’re deleting old rows to make room, you’ve already lost.
2. Data integrity is manual
No foreign keys. No constraints. No unique indexes. If someone types Acme Corp instead of Acme Corp. in the client column, nothing stops them. Your “database” now has three spellings of the same customer, and every report is suspect.
3. Multi-user editing causes silent corruption
Two people open the same sheet. One edits cell B12. The other edits B12 five seconds later. The first edit is overwritten — no warning, no audit trail. You discover it three weeks later when a payment doesn’t match.
4. Integration is copy-paste
Your Shopify orders land in one sheet. Inventory is in another. Accounting is in Excel on a shared drive. “Integration” means someone copies data between them every morning. That person is your most expensive API.
5. You can’t answer simple business questions
“How many repeat customers did we have last quarter?” becomes a 45-minute query involving three sheets, two pivot tables, and a prayer. A relational database answers this in one SQL statement.
What Happens Next
There are three paths, and I’ve walked clients through all of them:
| Path | Cost | Speed | When to choose |
|---|---|---|---|
| AppSheet on top of Sheets | Low | Days | You have 5–10 users and need a mobile UI quickly |
| Airtable / no-code DB | Medium | Days | You need relations but can’t afford custom dev yet |
| Custom Express + PostgreSQL | Higher upfront, lower long-term | Weeks | You need an API, integrations, and scalability |
AppSheet works until it doesn’t — typically around 20 users or when you need an API another tool can call. Airtable’s per-seat pricing scales linearly with your team. The custom path costs more to build but scales to thousands of users without per-seat fees.
I’ve written a detailed breakdown of one such migration — from an AppSheet CRM to a typed Express + PostgreSQL backend — as a case study. It covers the ETL strategy, the parallel-run cutover, and the schema decisions.
The Migration Doesn’t Have to Be Scary
The pattern I use on every migration:
- Extract cleanly. Read from Sheets via the API with an
updatedAtcursor — never re-read everything. - Model relationally. Don’t copy Sheets 1:1 to Postgres tables. Design the schema for the business, not the spreadsheet layout.
- Run in parallel. Keep the old Sheets live while the new system ingests data. Only cut over when both match for two weeks straight.
- Validate automatically. A property test that compares row counts and key aggregates between old and new every night during the parallel run.
This approach has never lost a record.
TL;DR
| Problem | Google Sheets at 50k+ rows, VLOOKUP chains, no audit trail, manual integration |
| Signs | Recalculate lag, data integrity errors, multi-user corruption, copy-paste “integrations” |
| Options | AppSheet (low cost, limited scale) → Airtable (medium cost, per-seat pricing) → Custom Postgres (higher upfront, scales) |
| Migration pattern | Idempotent ETL with updatedAt cursor, parallel run, automated validation |
| See also | AppSheet CRM → Express + PostgreSQL case study |