Every mobile app needs to remember something across restarts — a login token, a user's draft, a cache of the last-viewed screen's data, a genuinely structured dataset like a local library of downloaded articles — and the three realistic options for that, AsyncStorage, MMKV, and SQLite, are not interchangeable. Reaching for whichever one a tutorial happened to use, without weighing what the actual data looks like and how often the app reads and writes it, is how a team ends up with a settings screen that takes a visible moment to load because the app is storing a large, frequently-read JSON blob in an API built for small, infrequent reads.
This lesson is about matching the storage mechanism to the actual access pattern: AsyncStorage's simple async key-value API for small amounts of infrequently-accessed data, MMKV's synchronous, JSI-backed key-value store for data read constantly on a hot path, and SQLite's relational engine for anything genuinely structured, queryable, or transactional. Picking correctly here is a decision that is expensive to unwind later, because it usually means a real data migration once an app already has users with real, persisted data on their devices.
Analogy🏏Cricket
🏏 Think of it like cricket: A team's operations staff do not store every category of information the same way — the current live scorecard sits on a whiteboard right in the dugout, glanced at constantly and updated instantly with no ceremony; a player's detailed medical history sits in a properly structured, searchable filing system the physio can query by date, condition, or player; and a quick note like 'remind captain about the pitch report' goes on a sticky note, accessed rarely and discarded once acted on. Using the dugout whiteboard for the full medical history would be absurd — nobody could search it, and it would be wiped by tomorrow's match anyway; using a structured filing system for a sticky note would be needless overhead for something read once and thrown away. Just as the team matches each kind of information to the storage method suited to how it's actually accessed, an app should match each kind of persisted data to AsyncStorage, MMKV, or SQLite based on how it's actually accessed, not by default habit. Just as the whiteboard's whole value is being glanced at instantly with zero friction, MMKV's whole value is being read synchronously on a hot path with no wait. The insight is that a storage choice is not a stylistic preference — it is a claim about how the data will actually be accessed, and the wrong claim eventually shows up as a real, felt performance problem or a genuinely awkward data model.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.