When to Graduate from GAS: Limit Signals and Moving to an External DB

GAS is strong at short automation and Workspace integration, and weak at long-running, high-volume, high-concurrency work. It runs perfectly free at first, then hits limits as scale grows. Know the signals early and you get a planned migration instead of a sudden outage.

Signals to consider moving

• Data volume: past hundreds of thousands of rows the sheet slows → external DB (Cloud SQL, BigQuery, Firestore).
• Concurrency: hitting the 30-per-user ceiling → a queue or external backend.
• Runtime: more jobs don’t finish in 6 minutes → a durable backend like Cloud Run.
• Queries: complex joins/aggregations → a sheet is not a database.

Honest pitfall: quotas are shared per account

Put several client apps on one Google account and quotas add up. Trigger runtime (consumer ~90 min/day), 30 concurrent executions, and UrlFetch/email limits are shared across all apps. One client’s heavy job can stall another client’s app. Data-custody responsibility is tied to that one account too.

Account strategy (mass-creating accounts isn’t the answer)

• Free Gmail can’t be created in bulk (verification limits, abuse detection), and automated/mass creation violates the terms (a ban = data gone).
• Bundle light apps on a shared managed account, and isolate only heavy or sensitive apps on a dedicated account.
• When you genuinely need many accounts, move to Google Workspace (a domain, per-seat cost).

Deeper: what counts as “heavy”

Quotas mostly blow up on scheduled runs, bulk email, and frequent external calls. Light apps a person opens to save/export rarely touch them. So judge “is this app heavy + is the data sensitive” at the point of taking the work.

One line to keep: know the limit signals (volume, concurrency, time, queries) early, and isolate/migrate only the heavy ones.