Use Google Sheets as an App Backend: Limits and Fixes

You can use Google Sheets as an app backend, and for a small internal tool it is a perfectly sensible choice. The catch is the request quota: Google's documentation lists 300 read requests per minute per project and 60 per minute per user per project, and an app that reads the sheet on every page load will hit those numbers sooner than you expect.

Here is what the limits actually mean for an app, and the small change that makes them mostly irrelevant.

Limits when you use Google Sheets as an app backend

The Google Sheets API usage limits page gives these figures:

A few other details from the same page matter for design:

• There is no daily request limit, as long as you stay within the per-minute quotas.

• Google recommends keeping payloads to 2 MB at most.

• A request that takes more than 180 seconds to process returns a timeout error.

• Going over quota returns an HTTP 429 response, and quota refills every minute.

• A batch request counts as one API request, including its subrequests.

• The page also says that exceeding quota is planned to incur charges for Google Cloud billing accounts later in 2026. Check the current page before you rely on the free behaviour.

The page does not tell you how your app's traffic maps onto "user". If every visitor's request goes through one shared credential, plan around the smaller 60 per minute figure. That is a conservative reading, not something the page states.

What that means for traffic

Say each page load reads the sheet twice, once for the list and once for a settings tab. At 60 reads per minute you get 30 page loads per minute before the app starts failing, which is one every two seconds. That sounds fine until five people open the app after a team message, all within a few seconds, and the sixth gets an error.

Reads are the easy part to fix, because most sheet data does not change every second.

The 30-second cache

Keep a copy of the data in memory and only go back to the sheet when the copy is old. With a 30-second lifetime, the same app makes at most 2 reads per minute for that tab, no matter how many people visit. That takes you from a ceiling of about 30 page loads a minute to a ceiling set by your server, not by Google.

type Entry<T> = { at: number; value: T };
const cache = new Map<string, Entry<unknown>>();

export async function cachedRead<T>(
  key: string,
  loader: () => Promise<T>,
  ttlMs = 30_000
): Promise<T> {
  const hit = cache.get(key) as Entry<T> | undefined;
  if (hit && Date.now() - hit.at < ttlMs) return hit.value;
  const value = await loader();
  cache.set(key, { at: Date.now(), value });
  return value;
}

Two refinements worth asking your AI tool for. First, use a batch read to fetch several tabs in one call, since a batch counts as a single request. Second, when a write succeeds, clear the cached key so the next read sees it, otherwise people save a change and then see the old value.

Test the limit before your users find it

Do not wait for a real rush to learn where the ceiling is. Ask your AI tool for a small script that calls your own app's list page 100 times in one minute, once with the cache switched off and once with it on. With no cache you should see failures start around the 60th call if you share one credential. With the cache on, the sheet should receive only a couple of reads in total. If the numbers do not match, either the cache key is wrong or something else, such as a background refresh, is also reading the sheet.

Handling the 429 properly

Google's guidance for quota errors is truncated exponential backoff: wait roughly 2 to the power of the retry number in seconds plus a random fraction of a second, up to a maximum wait of 32 or 64 seconds. Because quota refills every minute, a patient retry usually succeeds. Tell your AI tool to add this to every Sheets call and to return a friendly "try again in a moment" message instead of a stack trace if it finally gives up. Rate limiting on your own side is covered in adding rate limiting to an AI-built app.

Where Sheets stops being the right backend

The quotas are rarely the first thing that goes wrong. These are the design signals that it is time to move:

• Two people writing at once. A spreadsheet has no transactions. Two near-simultaneous writes to the same row can overwrite each other, and you will only find out from a confused user.

• You need to search or filter large tables. Sheets returns ranges, it does not run queries.

• Row-level privacy. Everyone with access to the sheet sees every row. If customers should only see their own, you need a real database.

• Payload creep. Once a single read approaches the 2 MB recommendation, loads get slow for every user.

When you hit one of these, the move is well understood. See migrating an AI-built app to a new database for the steps, and do you need a backend for your app for the broader question. If you are still deciding whether the sheet should become an app at all, turning a spreadsheet into an app with AI walks through that first conversion. The overall process sits under how to build an app with AI.

Frequently asked questions

Is Google Sheets a good database for a small app?

For a handful of users and low write volume, yes. It is easy to inspect and edit by hand. It lacks transactions, per-row permissions and real queries, so it stops fitting as the app grows.

What is the Google Sheets API rate limit?

Google lists 300 read and 300 write requests per minute per project, and 60 of each per minute per user per project. Exceeding them returns a 429 error.

How do I stop the Sheets API 429 error?

Cache reads for a short time, batch related reads into one request, and retry failed calls with exponential backoff. Those three changes remove most quota errors.

Can multiple users edit the same Google Sheet from my app?

Technically yes, but concurrent writes can overwrite each other because there are no transactions. Keep writes to separate rows, or move the data to a database before several people edit at once.