When Google Sheets is the right database

Engineers are trained to treat a spreadsheet-as-database as a confession of technical debt. Sometimes it is. But we have shipped production systems for national brands where keeping Google Sheets as the data store was the correct architectural decision, and the debt was not the spreadsheet. It was the missing engineering around it.

Here is the situation that keeps recurring in operational work. A team runs its operation on Sheets. They know every tab, every filter, every quirk. The data is readable by the people accountable for it, editable in emergencies, and free. Then the operation grows, software gets commissioned, and the default consulting move is a migration: replace the spreadsheets with a real database, retrain the team, and hope adoption survives. Often it does not. The team quietly keeps a shadow spreadsheet, and now there are two sources of truth.

What a spreadsheet actually lacks

The honest failure list of Sheets as a data store is short and specific: no locking, so concurrent writers can clobber each other. No transactions, so multi-step updates can half-complete. No idempotency, so a retried request can double-write. Aggressive rate limits, which arrive at the worst possible moments. And no audit trail beyond revision history that nobody reads. That is the whole list. Notice what is on it: guarantees. Not capacity, not speed, not queryability at the scale most operations teams run at.

Guarantees can be added from outside

For a national beverage brand's field operations platform, we kept Sheets as the database and put an API in front of it that supplies exactly the missing guarantees. A mutex per tab makes every read-modify-write atomic. Retries are idempotency-aware: safe operations retry with backoff and jitter, non-idempotent appends do not retry blindly. Every mutation lands in an audit log. The mobile app and the admin console talk only to the API; the operations team keeps full visibility into the tabs they trust. Zero migrations were forced on anyone, and the system behaves like it runs on a real database, because operationally it does. The case study is at /work/field-operations.

Know when you have crossed the line

The same judgment that says keep the spreadsheet must also say when to leave it. The signals are structural, not aesthetic. Multiple tenants whose data must be isolated by the backend, not by discipline. Workflow rules that need transactions and row locks to be trustworthy. Write volumes that live near the rate limits daily. Queries that join across entities constantly. When a client's validated AppSheet application hit that ceiling, we rebuilt it as a multi-tenant platform on Postgres, with the business rules extracted into specifications first. That story is at /work/coapp.

Appropriate technology is the discipline

The two systems look like opposites: one keeps the spreadsheet, one replaces it. They are the same decision made twice, honestly. Choose the data store that matches the operation's reality, then engineer the guarantees the store does not give you. The failure mode is not the spreadsheet; it is running production workflows on any store, spreadsheet or database, without locks, idempotency, and audit trails. Technology is appropriate when it fits the team that has to live with it. That is the standard we design to, and it is where our studio got its name.