DEV Community

sara_builds
sara_builds

Posted on

I Replaced My Backend with Google Sheets (And It Actually Works)

Last month I mass-deleted 2,000 lines of backend code from a side project.

Express server? Gone.
Postgres database? Gone.
Prisma ORM? Gone.
Auth middleware? Gone.

I replaced it all with... Google Sheets.

Before you mass cringe, let me explain.

The Project

I had a simple internal tool. Maybe 50 users. Basic CRUD operations. The data was stuff that non-technical people needed to edit frequently.

My "proper" backend stack:

  • Node.js + Express
  • PostgreSQL
  • Prisma ORM
  • JWT auth
  • Deployed on Railway

All this infrastructure... to serve what was essentially a spreadsheet.

Every time someone needed to update data, they'd either bug me or I'd have to build an admin panel. Which I never got around to.

The Realization

One day I watched my coworker export data to a Google Sheet, edit it there, then ask me to re-import it.

That's when it hit me: they already know how to use spreadsheets.

What if the spreadsheet WAS the database?

The Solution

I built GetSheetAPI - a service that turns any Google Sheet into a REST API.

Here's how it works:

  1. Share your Google Sheet with the service
  2. Paste the sheet URL
  3. Get API endpoints with full CRUD

That's it. 60 seconds. No config files, no schema definitions, no migrations.

The Code

Before (Express + Prisma):

// routes/users.js
const express = require('express');
const { PrismaClient } = require('@prisma/client');

const router = express.Router();
const prisma = new PrismaClient();

router.get('/', async (req, res) => {
  try {
    const users = await prisma.user.findMany({
      where: { status: 'active' },
      orderBy: { createdAt: 'desc' },
    });
    res.json(users);
  } catch (error) {
    res.status(500).json({ error: 'Failed to fetch users' });
  }
});

router.post('/', async (req, res) => {
  try {
    const user = await prisma.user.create({
      data: req.body,
    });
    res.status(201).json(user);
  } catch (error) {
    res.status(500).json({ error: 'Failed to create user' });
  }
});

// ... 50 more lines for PUT, DELETE, etc.

module.exports = router;
Enter fullscreen mode Exit fullscreen mode

After (GetSheetAPI):

// That's it. There is no backend code.
// Just fetch from the API:

const response = await fetch('https://api.getsheetapi.com/v1/abc123', {
  headers: { 'X-API-Key': 'your-api-key' }
});
const users = await response.json();
Enter fullscreen mode Exit fullscreen mode

What I Gained

1. Non-technical people can edit data directly

My coworker opens the Google Sheet, changes a value, saves. The API reflects it instantly. No admin panel needed.

2. Built-in version history

Google Sheets tracks every change. Who edited what, when. Free audit log.

3. No server to maintain

No more "is the backend down?" moments. No deployment pipeline. No SSL certificates to renew.

4. Collaboration features for free

Comments, sharing permissions, real-time editing - all stuff I'd have to build myself otherwise.

5. Shipped the migration in an afternoon

Seriously. Export old data to CSV, import to Sheet, connect API, update frontend fetch calls. Done.

The Trade-offs (Being Honest)

This isn't a silver bullet. Here's when you should NOT do this:

❌ High traffic apps
Google Sheets API has rate limits. If you're expecting thousands of requests per minute, use a real database.

❌ Complex queries
No JOINs. No aggregations. No full-text search. If your data model is relational, Sheets will hurt.

❌ Large datasets
Sheets handles ~10,000 rows comfortably. Beyond that, performance degrades.

❌ Sensitive data
It's a spreadsheet, not a vault. Don't store passwords or payment info.

❌ Apps that need transactions
No ACID compliance. No rollbacks. If data integrity is critical, use Postgres.

When It Works Perfectly

✅ MVPs and prototypes (validate before you build infrastructure)
✅ Internal tools (the audience is small and trusted)
✅ Content that changes frequently (non-devs can update it)
✅ Portfolio sites (pull project data from a sheet)
✅ Simple CRUD apps (todo lists, inventory trackers, CRMs)

Performance

Let's be real: it's not as fast as a dedicated database.

  • Google Sheets API latency: ~200-500ms
  • Postgres query: ~5-50ms

For a prototype where you're validating an idea? Nobody notices.

For a production app serving millions? Use a real database.

The Migration Path

Here's the beautiful part: when you outgrow Sheets, your data is already in a portable format.

  1. Export to CSV
  2. Import to Postgres/MySQL/whatever
  3. Update your API calls

Clean migration. No vendor lock-in nightmare.

Try It Yourself

If you want to experiment with this approach:

  1. Create a Google Sheet with your data
  2. Head to getsheetapi.com
  3. Connect your sheet
  4. Start making API calls

Free tier: 1 sheet, 100 requests/day. Enough to prototype.

Conclusion

Is Google Sheets a "real" database? No.

Should you use it for your startup's production app? Probably not.

But for that side project you've been procrastinating on because "setting up the backend is too much work"?

Maybe a spreadsheet is all you need.


What do you think? Have you used unconventional solutions for simple problems? I'd love to hear about it in the comments.

Top comments (0)