type: architecture
status: active
timestamp: 2026-06-20
tags: [architecture, data, firestore, turso, r2, caches]

Cloud DBs are caches, not sources

Firestore, Turso, R2 are caches rebuilt from canonical JSONL git store on every deploy. If any of them dies, the next deploy reconstructs it from JSONL.

Cloud DBs are caches, not sources

Concept

Firestore (user state), Turso (warm-cache lifestream events), and R2 (media uploads, when needed) are all treated as caches over the git canonical. Their job is to make queries fast at the edge. Their job is NOT to be the source of truth. Any one of them can be dropped and rebuilt from git clone + the rebuild script.

How it works

Why this shape

A hosted DB as canonical is a single-point-of-failure with no migration story. A git-canonical with hosted-DB caches inverts that: the canonical is mirrorable everywhere, and the caches are disposable. The cost is one rebuild-cache.ts script per cache — paid once, runs on every deploy.

This also makes free-tier limits less stressful. If Firestore reads spike one day, the cache can absorb it via Turso. If Turso is saturated, the build-time JSON bake is always there. There is always another tier underneath because git is at the bottom.

Cross-refs


Edit on GitHub · Back to index