Using Google Sheets as a database: the developer debate, and where it actually lands

For the practical setup rather than the debate, see How to use Google Sheets as a database.

Why this keeps coming up

This comes up constantly on r/webdev. Someone posts a side project that uses Google Sheets as the data store, gets two camps in the replies: "that's an interesting hack" and "please never do this in production." Neither camp is entirely wrong.

The reason the debate persists is that "database" is doing a lot of work in that sentence. If you mean a durable, structured store you can query - Sheets qualifies. If you mean a transactional RDBMS with indexes and row-level locking - it does not.

The honest answer is: Sheets works as a database for a specific class of problems, breaks badly for another class, and most of the controversy comes from applying the same label to both.

What Google Sheets actually is as a data store

A spreadsheet is a grid with persistent storage, version history, and a collaborative editing UI. Google's infrastructure handles the durability. You get a familiar interface that non-technical users already know.

That is genuinely useful. The real picture though:

What it has:

• Free, zero ops - no server to provision or maintain
• Built-in version history (you can roll back edits)
• Collaborative editing with comments, conditional formatting, and live presence
• 10 million cell limit per spreadsheet (generous for most small projects)
• Google's uptime and reliability backing it

What it lacks:

• No transactions or atomicity - two writes can race and corrupt a row
• No indexes - every query scans the full sheet
• No foreign keys, no joins, no relational integrity
• No row-level locking
• Query performance degrades noticeably past ~50,000 rows
• The Sheets API has rate limits (300 read requests per minute per project, 60 write requests per minute per user)

It is not a database engine. It is a spreadsheet that you can treat like a database for certain workloads.

Where Sheets-as-database genuinely works

The r/learnprogramming thread on this usually misses the good cases because people frame it as "real database vs. Sheets." The better frame is: what does your workload look like?

Sheets works well when:

Internal tools with small datasets. An ops team tracking vendor contracts, a marketing team managing campaign budgets, an HR team with employee training records. A few hundred to a few thousand rows, edited by hand, read occasionally. No need for Postgres here.

Non-technical editors who own the data. This is the strongest case. If the people updating the data are not engineers, putting a spreadsheet UI in front of them is genuinely better UX than a custom admin panel. A content editor updating FAQ answers in a sheet they already know beats waiting on a developer to push changes.

Rapid prototyping and MVPs. You want to validate whether anyone uses a feature before building real infrastructure. Sheets gives you a working data layer in minutes. If the product takes off, migrate to a proper database then.

Waitlists and form backends. Collecting signups, survey responses, or contact form submissions into rows. Low write volume, read-heavy on the admin side. This is a classic fit.

Content management for small sites. Blog post metadata, team member listings, product catalogs with under a few thousand entries. If the site is mostly static and data changes infrequently, a sheet is a perfectly reasonable CMS backend.

Configuration data. Feature flags, pricing tiers, redirect rules, A/B test parameters - data that changes occasionally and needs a non-engineer to own it. A sheet with a REST layer beats building an admin UI.

Where it breaks down

Be honest with yourself about these before committing:

High write volume. If your app writes more than a few dozen rows per minute, you will hit rate limits and race conditions. Sheets is not designed for concurrent writes. Two users submitting a form at the same millisecond can corrupt each other's row.

Concurrent writes in general. Even at low volume, Sheets has no locking mechanism. If two processes write to the same row simultaneously, you lose one update silently. For any data where correctness matters - payments, inventory, user account state - this is disqualifying.

Relational data with joins. Sheets is a flat table. You can work around this with VLOOKUP formulas inside the sheet, but that is not the same as a proper join. If your data model has more than one or two relationships, you are fighting the tool.

Large datasets. Performance degrades past ~50,000 rows for most query patterns. The 10 million cell limit sounds large, but a sheet with 100 columns hits that at 100,000 rows. For any product expected to grow to that scale, plan the migration early.

Anything requiring audit trails with integrity guarantees. Version history in Sheets is useful but it is not an immutable audit log. It can be manually deleted, and it does not capture programmatic writes with the same fidelity.

The missing piece: Sheets has storage but no API layer

Here is the practical problem. Even if your use case is a good fit for Sheets as a data store, the Google Sheets API itself is not something you want to expose directly to a frontend or hand to a non-technical team.

It requires OAuth, returns data in a format optimized for spreadsheet operations (not JSON objects your app expects), has its own rate limit headers to handle, and needs service account setup that trips up most people the first time.

That gap is exactly what SheetsAPI solves. You connect your spreadsheet, and it generates a clean REST endpoint. The first row of each tab becomes the field names. You get filtering, sorting, pagination, and optional API key authentication - without writing any backend code.

A read looks like this:

# Fetch all rows where plan = "pro", sorted by created date descending
curl "https://sheetsapi.gkit.mreshank.com/api/spreadsheets/YOUR_KEY/Users?filter=plan:pro&sort=-created_at&limit=50"

The response is standard JSON:

{
  "data": [
    {
      "name": "Alice",
      "email": "alice@example.com",
      "plan": "pro",
      "created_at": "2026-06-28"
    },
    {
      "name": "Bob",
      "email": "bob@example.com",
      "plan": "pro",
      "created_at": "2026-06-25"
    }
  ],
  "meta": { "total": 47, "page": 1, "limit": 50 }
}

No OAuth dance, no service account JSON, no parsing values[][] arrays.

Sheets + SheetsAPI vs. the alternatives

When people on r/webdev ask "should I use Sheets as a database," they usually mean "compared to what?" Here is a direct comparison for the use cases where Sheets is a realistic option:

The cases where Sheets + SheetsAPI wins: your team already lives in Google Workspace, you need non-technical editors to own the data, and your dataset stays under ~50k rows. For anything requiring real-time sync, complex queries, or high write concurrency, Supabase or Firebase is the better call.

Airtable is the closest competitor for the "non-tech editor" use case, but it gets expensive fast and locks your data in a proprietary format. Sheets keeps your data in a format every tool can read, and it is free.

The verdict

Google Sheets is a legitimate data store for a specific, well-defined class of problems. The r/webdev threads that dismiss it entirely are wrong. So are the ones that suggest it for any production workload.

The right mental model: if the people who own your data are non-technical, if your dataset is small to medium, and if you need something running today rather than after a backend sprint - Sheets is a reasonable choice. If you need transactions, joins, or high write throughput, use a proper database.

The gap has always been the API layer. SheetsAPI closes that gap - clean REST endpoints, API key auth, filtering and pagination, no backend code required. You can be reading data from a sheet in a few minutes.

If you are evaluating whether it fits your project, the use cases page has specific patterns by workload type. The docs cover the full query syntax. And if you want to see what else GKit offers, the free tools at /tools are worth a look while you are here.

Get started free - no credit card, no service account setup.