Default storage tech per use case

Personal, Python-first, local-first projects. Applies when starting a storage/caching need without an explicit request to analyze alternatives — pick from this table, don't re-litigate from scratch each session. Deviating is fine when a category genuinely doesn't fit or scale requirements outgrow the default (see each category's "Escalate to" line) — the point is to stop a fresh session/model from silently picking something different for no reason, not to forbid judgment calls.

Selection criteria for every entry below: MIT/Apache-2.0/BSD-style permissive license only; popular and actively maintained (verified via real GitHub/PyPI activity, not vibes); testable fully inside a plain pytest run — in-memory or tmp_path-scoped, no Docker/cloud account/CI services; low-boilerplate API a coding agent can use correctly without much ceremony or indirection. Picks favor the best-fit tool per concern over minimizing the number of technologies in a project — don't force a consolidation the categories below don't call for.

Cash in the testability criterion: don't mock these. The whole point of picking a store the suite can start and stop is that tests run the real one, so a double here throws away what the choice bought. python-conventions, "Don't double anything the suite can run for real", states the rule and the boundary.