There’s no database behind my daughter’s archive. No table of photos, no index, no metadata store. When the app needs to know what’s in “July 2026,” it opens the July 2026 folder and looks.

That sounds lazy. I’d argue it’s the opposite — it’s the one decision that keeps the whole system simple enough for one person to maintain.

How It’s Organized

The archive is just folders on the NAS:

  • A folder per year, split into photos and videos.
  • A folder per month inside that.
  • The files themselves, named with the date the camera assigned them.

That structure carries almost all the information a database would:

  • What category is this? The folder it’s in.
  • What month is it from? The folder, and the date in the file name.
  • How many videos are in September? Count the files in the September video folder.

The folder tree is the schema. The file name is the timestamp. There’s nothing else to keep in sync.

Counting Live, Every Time

When my mother opens a year, the app shows a badge on each month: August 55, September 43, and so on. Those numbers aren’t stored anywhere. The server counts them fresh by scanning the folder each time it’s asked.

The nice consequence: the count is never wrong. There’s no cache to go stale, no index to rebuild, no “the database says 55 but the folder has 54.” Add a file, the count goes up. Delete one, it goes down. What you see is always the actual current state of the disk, because the disk is the only source of truth.

Why I Didn’t Build a Database

I could have. A real photo app would. But for this, a database would mostly add ways to be wrong:

  • Two sources of truth. With a database, the files say one thing and the table says another, and someday they disagree. Then I’m debugging a sync problem instead of watching my daughter’s videos.
  • A rebuild step. Move files around by hand — which I do — and a database needs re-indexing. Folders need nothing; they’re already the truth.
  • More to understand. This is software only I maintain. Every extra moving part is a part I have to remember at 11pm when something breaks. “It’s just folders” is a thing I can always reason about.

“Don’t build the database” was a real design decision, not a shortcut. The measure of good personal software isn’t how sophisticated it is; it’s how little of it you have to hold in your head.

Where This Would Break

I want to be honest about the limits, because “no database” isn’t free wisdom — it’s a trade that fits this problem.

  • Scale. Scanning a folder is fast for hundreds or a few thousand files. If this grew to hundreds of thousands, live counting would get slow and an index would start to earn its keep.
  • Search. Folders answer “what’s in July?” instantly. They can’t answer “show me every photo with a dog in it.” The day I want real search across content, I’ll need more than a file tree.
  • Rich metadata. Tags, faces, albums that cross months — a folder tree can’t express those. It only knows the one hierarchy I chose: year, then month.

For a family growth archive — a few thousand files, browsed by year and month, by a grandmother and a toddler — none of those limits bite. The folder tree does everything asked of it and nothing else, which is exactly why it never surprises me.

Next: the small trick that keeps the same photo from ever being imported twice — again, without a database.