Using Google Sheets as a database for an app
Yes for a small, read-mostly, internal app, and it is a perfectly respectable choice there. Two things end it, and neither is about storage size. The first is quota: Google documents a read limit of 300 requests per minute per project and 60 per minute per user, and going over returns an error rather than slowing down. The second matters sooner and is not fixable in code: a sheet has one permission for the whole file, so your app's credentials can read every row. Filtering per person in your application is presentation, not access control.
Last checked against Anthropic's documentation on . Claude changes often. If something here no longer matches the help centre, the help centre is right.
When a spreadsheet backend is genuinely the right call
Said first because it is often true, and because most pages answering this question are selling a database.
- Non-developers need to edit the data. This is the strongest argument and nothing else on this page beats it. A spreadsheet everybody already knows how to use is worth real technical compromise.
- It is read mostly. A menu, a price list, a schedule, a directory. Reads cache well and the write path is where the trouble lives.
- Traffic is low and predictable. An internal tool for a team of twenty is nowhere near the limits below.
- The data is not sensitive. Everyone who can reach the sheet may see all of it, and that is fine for a lot of data.
- You want it working today. No provisioning, no migration, no schema. That is a real advantage and it does not stop being real later.
The quota, which is a wall rather than a slope
Worth reading carefully, because the shape of the failure surprises people. Google frames the API this way:
The Google Sheets API is a shared service, and we apply quotas and limitations to protect the overall performance of the Google Workspace system for all users.
Usage limits, Google Sheets API
The words that matter are "shared service". The quota exists to protect everybody else's Workspace, which means it is not a limit you can buy your way past by upgrading a plan.
The documented limits are 300 read requests per minute per project and 60 per minute per user per project, with the same numbers for writes. What happens at the boundary is the part to plan around:
If your app sends 350 requests in one minute, the additional 50 requests exceed the quota and generates a 429: Too many requests HTTP status code response.
Usage limits, Google Sheets API
So it does not degrade. It returns 429 and your app breaks, and it breaks precisely when the app has become popular enough to matter. The fix is caching and batching rather than optimism: read the whole range once and cache it, batch writes instead of one call per row, and implement exponential backoff before you need it rather than after.
The permission problem, which no amount of code fixes
This is the one that should decide it for most apps, and it is structural rather than a limitation to work around.
Sharing in Sheets is per file. Your application authenticates as one identity, usually a service account, and that identity can read every row in the sheet. If your app shows each person only their own records, that filtering happens in your code, after the data has already been fetched.
For a rota or a shared reading list, completely fine. For anything with pay, health, grades, addresses or performance in it, an app that filters rows is hiding data rather than restricting access, and the distinction becomes concrete the first time a bug, an export or a misconfigured endpoint returns the unfiltered set.
A real database expresses this in the storage layer: the query returns only the rows this person may see, so a bug in the interface cannot leak what the query never fetched.
What to use instead, and what each costs
| Sheets API | Managed Postgres | Backend as a service | Homespun | |
|---|---|---|---|---|
| Non-developers can edit the raw data | Yes, and that is its best feature | No | Rarely | Through the app |
| Per-row access control in storage | No | Yes | Yes, via rules | Yes, per collection |
| Rate limits | 300 reads per minute per project | Your server's | Plan dependent | Ours, not per minute |
| Setup | None | Provision, connect, migrate | Moderate | The agent does it |
| User accounts included | No | No | Yes | Yes |
| Cost | Free with Workspace | A monthly bill | Free tier then real money | Free today, no paid plan to buy |
Homespun is where the same agent that built the thing can host it. People sign in with their email, so the app can tell who is who and every row remembers who created it; permissions are set per collection, so some people can approve and others can only submit; and the agent keeps read and write access to the collections it is allowed, so it can keep working on the data instead of handing you a page and walking away. It is free today, and there is no paid plan to buy.
If the spreadsheet is the point, keep it. Nothing in the other three columns replaces "the office manager can fix a typo without asking anybody", and that is frequently the requirement that actually matters.
Questions people ask next
Can you use Google Sheets as a database?
For a small, read-mostly, internal app, yes, and it is a reasonable choice, especially when non-developers need to edit the data directly. It stops working for two reasons: the API is quota limited to 300 read requests per minute per project and 60 per user, and a sheet has a single file-level permission, so your app's credentials can read every row regardless of what the interface shows.
What are the Google Sheets API rate limits?
Google documents 300 read requests per minute per project and 60 per minute per user per project, with the same figures for writes. Exceeding them returns a 429 Too many requests response rather than slowing down, and Google's own example is an app sending 350 requests in a minute, where the extra 50 fail. The recommended response is exponential backoff.
Is Google Sheets secure enough for app data?
It depends entirely on whether every user may see every row. Sharing is per file, so an application reading the sheet reads all of it and any per-person filtering happens in your code rather than in storage. For rotas and public lists that is fine. For personal, financial or health data, use storage that returns only the rows a person may see.
How many rows can Google Sheets handle?
Far more than most people need: Google documents up to 10 million cells or 18,278 columns for a Google Sheets spreadsheet. Size is rarely the reason a spreadsheet backend fails. The reasons are the per-minute API quota and the file-level permission model, both of which bite long before the cell limit does.
What is the best alternative to using Google Sheets as a database?
If you need non-developers editing raw data, nothing replaces it and you should keep it with caching and backoff. If you need per-row access control, a managed Postgres or a backend-as-a-service gives you that with real setup work, and an agent-operated platform such as Homespun gives you storage with per-collection permissions and sign-in already attached, at the cost of owning less of the stack.
Primary sources
Every claim about Claude on this page comes from Anthropic's own documentation, quoted rather than summarised so you can check it yourself.