← knowledge.oriz.in

Layer 4 — database, sharded by data shape

architecture architecturedatabasefirestoretursojsonllayer-4

Layer 4 — database, sharded by data shape

Concept

Different kinds of data live in different free tiers, on purpose. No single quota gets exhausted because no single store carries everything. Git is the canonical store; the cloud DBs are caches; the browser holds per-user state when nothing else needs to see it.

How it works

Data shape Where Why
Public, append-only datasheet (lifestream events, blog MDX, books JSON, cards JSON) GitHub repos as JSON / JSONL / MDX, read at build time, baked into static HTML Truly free forever, version-controlled, survives every provider
User accounts, subscription state, entitlement flags Firestore Spark Auth lives here anyway; 50K reads/day covers 11+ sites + N extensions combined
Hot edge cache (last 24h of lifestream events for the live home feed) Turso libSQL — read-only token only Read-only token is browser-safe; writes happen in the cache-rebuild script
Per-user search index (journal full-text) localStorage / IndexedDB in the browser Zero cost to family infra
Public datasets (NCERT books, card catalog, finance calculator inputs) JSON in GitHub repo Read at build time; no DB hits
Image / file uploads Cloudflare R2 free (10 GB, no egress) Only when a feature requires it; defer until needed

Why this shape

A single store always has ONE quota. With one store, you either pick a tier that covers your worst case (expensive) or accept hitting the quota wall (loses data or service). Sharding by data shape means each store sees a load it can absorb at the free tier. Auth state sees only signed-in user activity. Public datasheet content sees zero runtime DB load — it's compiled at build time. The warm cache only sees the small sliver of "the last 24h" which fits inside any free tier.

Cross-refs