Replaced My App's Database With My Daughter's Google Drive Folder

My daughter takes a weekly music class. Every session, her teacher sends a voice clip of a bhajan over WhatsApp, plus a photo of handwritten notes. Sometimes we record her practicing it back.

I wanted a simple way to listen to her practice takes over time — not just the latest one, the history. Day-1 Nyra sounds nothing like Nyra-six-months-later, and I didn't want that gap to just disappear every time a new recording overwrote the old one.

I built that. It cost nothing, has no backend, no database, and no monthly bill. The interesting part isn't that it's free — plenty of things are free. It's how it works, because I think most developers have a feature sitting in their Google Drive they've never thought to use as infrastructure.

The trick: Drive already has versioning. You're just not using it.

Every file in Google Drive has revision history built in. Upload a new version of a file — same filename, same file ID — and Drive keeps the old one, timestamped, browsable, forever (well, for 30 days by default, more on that below).

So instead of building "save multiple takes per song" myself — a table, a foreign key, an upload endpoint, a UI for browsing old versions — I just... overwrite the same file each time. Drive does the rest. My app's "version history" feature is two API calls: files.get for the latest, revisions.list for everything older. I wrote zero versioning logic.

// Overwrite the existing file — this becomes a new revision automatically,

// and keepRevisionForever=true stops it from being purged after 30 days

await fetch(

  `https://www.googleapis.com/upload/drive/v3/files/${fileId}?uploadType=media&keepRevisionForever=true`,

  {

    method: 'PATCH',

    headers: { Authorization: `Bearer ${accessToken}` },

    body: newAudioBlob,

  }

);

The schema is the folder structure. There's no database.

Each song is a folder. Inside it:

Sankata Mochana/

  teacher-audio.m4a

  teacher-notes.jpg

  student-practice.m4a

The app lists subfolders to get the song list. It matches files by filename prefix (teacher-audio, teacher-notes, student-practice) — not exact extension, since an iPhone clip and an Android clip use different formats. No JSON file describing the structure. No database. The folder structure is the schema. Add a new folder with the right three files in it, and the app just finds it — nothing to deploy, nothing to register.

The hidden feature: file properties as metadata

I wanted to tag each song with the god it's devoted to, and filter by tapping an avatar — Instagram-story-style. My first instinct was a JSON file mapping song → deity.

Then I remembered Drive files and folders support arbitrary key-value properties — metadata that doesn't show up anywhere in the normal UI, but comes back in the same API call that already lists the folder. So tagging a song is just: properties: { god: "Ganesha" } on that folder. No extra file, no extra request, no JSON to keep in sync.

I'd bet most people using the Drive API have never touched this field.

The actual architecture

• 
  Hosting: GitHub Pages (free, static, no server)


• 
  Auth: Google Identity Services, client-side only — no backend to hold a client secret, because there isn't one


• 
  Storage: Google Drive, accessed directly from the browser via the Drive API


• 
  Database: doesn't exist. Folder names and filenames are the data model.

Total recurring cost: $0. Not "cheap" — actually zero. The only thing I'm "paying" for is Drive storage I already had.

The honest caveats

• Drive auto-purges old revisions after 30 days unless you mark them keepRevisionForever — easy to miss, and I almost did. Worth setting on every save, not as an afterthought.


• This is a client-side-only OAuth app in Google's "Testing" mode — fine for a handful of named users (my family), not something you'd point at the general public without going through app verification.


• It's read/write to my Drive, accessed through my OAuth client. This isn't a multi-tenant product — it's a personal tool that happens to use someone else's storage instead of building my own.

Why this is actually the point

The boring version of this story is "I saved money by not using a database." The real version is: in two years, I'll be able to tap a button and hear my daughter sing the same bhajan at four years old, sitting right next to whatever she sounds like by then. That's the actual feature. The architecture is just what made it possible without becoming a second job to maintain.

If you've built something similar on top of Drive's revision history or the properties field, I'd genuinely like to hear about it — this feels like a pattern more people should know exists.