convex-performance-audit

Run `npx convex insights --details` to find functions with high bytes read or documents read, then trace every `ctx.db.get` and `ctx.db.query` in the affected path. Replace scan-plus-filter patterns with `withIndex` queries and consider digest tables for hot list pages.

OCC conflicts come from write contention on hot documents or broad read sets. Narrow reads with indexes, shard hot counters across multiple documents, and move non-critical bookkeeping to scheduled functions via `ctx.scheduler.runAfter`.

The Convex `.filter()` method runs after the database scan, so you still pay for every document read, identical to filtering in JavaScript. Only `.withIndex()` and `.withSearchIndex()` push predicates to the storage layer and reduce documents scanned.

Use point-in-time reads for high-read, low-freshness flows like reports, aggregate snapshots, and low-churn listings where explicit refresh is acceptable. Keep reactive `useQuery` subscriptions for collaborative editing, live dashboards, and presence-heavy views.

Queries and mutations get 1 second of user-code execution, 16 MiB read and written per transaction, and 32,000 documents scanned. Actions get 10 minutes. Break large mutations into cursor-based self-scheduling batches to stay within these budgets.

Avoid digest tables, document splitting, and migration-heavy rollouts when tables are small, traffic is modest, or signals are weak. A simple scan on a small table is often acceptable, and structural work should follow a measured signal or a clearly unbounded hot path.