Eleven tables, no indices: 119.1 ms per read, and a tracing pipeline that accepted nothing

The mechanism here is unglamorous. Room's relation fetches on the analyzer path had nothing to seek on, so each verdict recomputation full scanned `set_logs`, the largest table in the schema and the one sitting on the hot path ^[5]. Compute-on-read is not what made that slow. What made it slow is that the cost of a single read scaled with everything the lifter had ever logged, so a fresh install looked healthy while a long-tenured user paid the whole bill ^[6].

The arithmetic on the fix: 112.3 ms removed from one session read ^[16], leaving the new figure at 5.7 percent of the old ^[17]. Divide the two published numbers and you get 17.5x rather than the 17.4x in the writeup ^[18], which is what one decimal place of rounding buys and not worth arguing about. The number the post does not give is the one I would want next: which query stayed where it was ^[4]. That is the point where indexing stops being the answer and caching starts looking attractive again. The migration covered seven tables against eleven entities in the schema ^[7][13], so four entities came out of it with no new index ^[19].

Then the trap, in the author's own framing. Room builds a fresh install from the `@Entity` annotations and an upgrade from the migration's raw SQL, two independent descriptions of the same schema with no framework check between them ^[8]. The index that makes this read path affordable now exists in two places, in two syntaxes, kept in step by hand. Drift does not throw an error. It means the user who installed today and the user who upgraded today are running different databases, and only one of them is fast.

The ordering of the observability half is what most readers will get backwards. All four read-path defects were found by reading code on 2026-07-25, before Sentry existed in the project at all ^[9][15]. The tool arrived afterwards and turned up three different bugs, one of which was its own ingest: five spans sent, zero accepted, five rejected as invalid ^[10]. Ship the index work, open the dashboard to confirm the timing moved, and you are reading an empty chart as if it were agreement. The Cloudflare Worker had already failed in the same shape, with a top-level `console.error` and a generic 500 that records nothing in production ^[12]. Two channels, both trusted, neither checked at the far end.