Two users, tens of megabytes: reactive backends bill re-runs, not rows

A developer running a Convex chat app with exactly two users, his own dev and prod accounts, poking at it for maybe half an hour, watched the dashboard's Database Bandwidth meter report tens of megabytes a day ^[1]. The stored messages were a few hundred kilobytes at most, and both numbers were correct ^[2][3].

The reason is in the definition. In Convex, Database Bandwidth counts the bytes of documents your functions read and write per execution, and a reactive query re-executes every time any document in its result changes ^[4][5]. A `useQuery` call in React is not a fetch; it is a subscription that the server keeps watching, re-running the whole query and pushing the fresh result to every subscribed client whenever a touched document changes ^[6]. So the author's formula is bandwidth equals result size times re-run count ^[7]. A 200 KB result that re-runs 150 times has moved 30 MB while storing 200 KB ^[8]. Against a few hundred kilobytes of actual data, tens of megabytes a day is roughly a hundredfold read amplification ^[9].

The failure mode this produces is specific and boring. The message list was a plain `useQuery` returning the conversation's messages, so every arriving message re-ran it and re-shipped the entire list: message 50 lands and Convex re-reads and re-sends 1 through 50, message 51 re-sends 1 through 51 ^[10]. The marginal cost of one new message grows with the length of the conversation already there ^[11]. The author's fix is `usePaginatedQuery`, where each page is its own subscription, so a new message at the top re-runs only the newest page and the older loaded pages sit untouched ^[12][13]. His conclusion is worth taking literally: in Convex there is no separate incremental-update knob, pagination is the knob, and any reactive list that can grow should be paginated ^[14].

The second problem is the one that compounds. While streaming a model reply token by token, he saved progress by writing the accumulated text back to a document on every flush, so each write carried the whole string so far ^[15]. Writing 1 token, then 2, then 3, up to N, sums to N squared over two: double the reply length and you quadruple the bytes written ^[16][17]. A reply whose final text is a few kilobytes can write tens of kilobytes getting there, and on a reactive read path every flush also re-ships the document to every subscriber ^[18]. At 200 flushes, rewriting the buffer moves about a hundred times the bytes of appending only the new piece ^[19]. The fix is to append the delta, or stream the text over a separate channel and write the document once at the end, which is linear rather than quadratic ^[20]. The general shape, in his words: anything that rewrites a growing value inside a loop is a quadratic trap, and reactivity multiplies the damage because every rewrite is also a re-read ^[21].

What to watch in your own code is the read set of each subscription on your hottest write path, not the size of your tables. The author also flags server functions that used `.collect()` behind an index to count or check usage, which pulls every matching row into an array ^[22]; that is the same mistake wearing different clothes, a query whose read set grows without bound sitting behind a trigger that fires constantly.