convex-performance-audit

Run npx convex insights --details to identify hot functions, then replace scan-and-filter patterns with withIndex queries so storage does the filtering. For hot list pages, consider digest tables that read smaller document shapes instead of full source rows.

OCC conflicts come from write contention on hot documents or broad read sets. Narrow reads with indexed queries, split hot documents like counters into shards, skip no-op writes, and move non-critical bookkeeping to scheduled functions.

No, the Convex .filter() method has the same performance as filtering in JavaScript and does not reduce documents scanned. Only .withIndex() and .withSearchIndex() actually push filtering to storage.

Every useQuery and usePaginatedQuery creates a live subscription that re-runs when its read set changes. Reduce cost by batching related data into fewer queries, using skip for unready args, isolating frequently-updated fields, and removing Date.now() from queries.

Queries and mutations get 1 second of user-code execution time, 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 budgets.

Avoid digest tables, document splitting, or migration-heavy rollouts when scale is small, traffic is modest, or signals are weak. A simple scan on a small table is often acceptable in Convex, so only restructure with a measured signal or known hot path.