I stopped blocking the UI on SQLite writes. I log sets in-memory first, then flush. I use a tiny write queue + one transaction. I ship a “pending” state that never lies. Context My fitness app has one job during a workout. Log a set in under 5 seconds. I started with “just write to SQLite on button tap”. Brutal. Every tap waited on IO. Then React re-rendered. Then the list jumped. Also offline-first means I can’t punt to the server. SQLite is the source of truth. But the UI can’t feel like a database client. So I split it. UI writes to memory instantly. SQLite catches up in the background. If SQLite fails, I show it. No silent drops. 1) I treat SQLite like a sink, not my UI state My first version did this: Tap “+”. Await insert. Then query. Then render. It “worked”. It also felt like a 2012 Android app. Now I keep a local in-memory log. It’s the thing the list renders. SQLite is the durable sink. I model it with a clientId . Always. That ID exists before SQLite. That’s the trick.…