SheetsDB

    Architecture guide

    When to use Google Sheets as a database

    A public Google Sheet can work as a small, read-only content source when non-developers need to edit rows. It is not a substitute for a database when you need private data, writes, joins, transactions, or strict schemas.

    By Zainul Ariffin
    Good fit: public catalogues, event schedules, small directories, prototypes, and content that a non-developer updates in Google Sheets.

    Use a Sheet when the editing workflow matters

    Google Sheets gives a team a familiar grid, comments, revision history, and sharing controls. SheetsDB adds a read-only JSON endpoint without a Google Cloud project or service account.

    Do not put private data in a public Sheet

    SheetsDB only reads Sheets that are public or available to anyone with the link. Do not use it for passwords, personal records, private customer data, internal financial data, or anything that should require authorization to view.

    Know the technical limits

    • No writes or transactions.
    • No database joins, indexes, or query language.
    • No enforced schema.
    • Google publishing or caching can delay recent edits.
    • Request, row, and response-size limits apply.

    Move to a database when the application becomes the editor

    If users create or update records in your product, use a database. The same applies when you need permissions per record, strong consistency, relational queries, or background jobs that depend on transactions.

    A practical middle ground

    Keep editorial content in a Sheet and application state in a database. Fetch the Sheet through a server route, validate each row, and cache the result for the period your product can tolerate. See the Next.js guide for one server-side pattern.