Why can computing hasNextPage make a GraphQL connection field slow, and how do you avoid it?

## The failure, concretely A 4-person platform team runs a museum collection graph. Two connection fields matter: a gallery's objects, paged 24 at a time, and a catalogue-wide search connection over the same objects. Staging carries a seeded slice of 9,412 objects; production holds 1,284,663 catalogued objects across 214 galleries. The connection resolver does two things per request. It runs a keyset page read — everything after the client's cursor, in the total order, bounded by the page size — and then, to fill `hasNextPage`, it runs a second statement with the same predicate that counts the matches. In staging both return inside 40 ms and nobody notices. In production the search connection's p99 climbs to 8.3 seconds and the field begins timing out against the request budget, but only for broad filters: "oil on canvas, acquired before 1965" matches 214,880 rows, and the count walks all of them. The page read is flat at 25 rows whatever the filter. **The bounded query was never the problem; the unbounded one was, and only production had enough rows to reveal it.** ## Why a count is the wrong shape for this question `hasNextPage` asks *is there at least one more element after this position*. A count answers *how many elements match in total*, which is strictly more information and strictly more work — a global aggregate paying for a local yes-or-no. The cost of the correct question does not grow with the collection; the cost of the count does. ## Limit plus one Ask for one row more than you intend to return. If it comes back, something follows the page. ```pseudocode function artworksPage(filter, first, afterCursor): rows = store.query( where = filter, after = afterCursor, orderBy = totalOrder, # same order the cursors were minted in limit = first + 1) # one more than the client asked for hasNext = rows.length > first if hasNext: rows = rows.slice(0, first) # DROP the probe row before anything else edges = rows.map(r -> { node: r, cursor: cursorFor(r) }) return { edges: edges, pageInfo: { hasNextPage: hasNext, hasPreviousPage: afterCursor == null ? false : store.existsBefore(filter, afterCursor), startCursor: edges.isEmpty() ? null : edges.first().cursor, endCursor: edges.isEmpty() ? null : edges.last().cursor } } ``` One extra row per page is a rounding error beside the page itself. A count is not. ## Three bugs this trick invites 1. **Not trimming at all.** The client asked for 24 and receives 25 edges. Any page-size cap the schema advertises is now off by one, and a client that renders fixed-size pages shows a stray item. 2. **Trimming the edges but taking `endCursor` from the untrimmed rows.** This is the expensive one because it is silent. The client receives 24 objects, sends back a cursor pointing at the 25th, and its next page begins after an object it never saw. One object is lost per page; crawling 1,284,663 objects in pages of 24 means roughly 53,527 pages and roughly that many missing objects, discovered weeks later by whoever reconciles the export. 3. **Fetching the probe row differently.** If the extra row is read with a relaxed filter or a different sort than the page, `hasNextPage` can be true when the genuine next page would come back empty, and the client makes a pointless round trip that returns nothing. ## Why staging never caught it Not a code difference — a data-shape difference. On 9,412 rows every plan is a cheap scan and every count returns instantly, so the two statements look identical in cost. Two signals separate them once you look at production: **per-field timing** that attributes latency to the connection field rather than to the operation as a whole, and the storage layer's statement log showing **two statements per connection field where the design called for one**. The durable fix for the blind spot is a lower environment whose row counts and selectivity resemble production, or at minimum running the count's plan against production statistics before shipping it. ## When you cannot over-fetch Sometimes the source returns exactly what you asked for and no more — a remote service that pages one way with its own opaque token. Note carefully what the convention allows here. The best-effort escape hatch covers only the boolean in the direction you are **not** travelling. On a forward page, `hasNextPage` is the exact one, so "I could not tell, so I said false" is not compliant. You need the source's own more-results flag or next-page token, or you page one item deeper than you display. Guessing false there is how a client stops crawling at an arbitrary point and reports a partial catalogue as complete. ## A note on scope If the schema also exposes a count of the whole result set, that is a separate field with its own separate cost and its own separate decision. It is not what fills these two booleans, and reaching for it to answer `hasNextPage` is what created the incident in the first place.