One Screen, 241 DynamoDB Requests: How Nested GraphQL Queries Fan Out on AppSync

A feed of 20 posts, each with its author and 10 comments with their authors, is one GraphQL query and 241 DynamoDB requests when each relationship resolver fetches per parent. The arithmetic by page size and nesting depth, what it costs per million screen views, and four ways to cut it, from batching to a single Postgres join.

GraphQL resolves each field with its own resolver. For a relationship on a list, that resolver runs once per item unless it batches. With DynamoDB behind it there are no joins, so each run is its own request. One query from the browser becomes hundreds of database requests on the server.

What it costs

AppSync bills $4.00 per million queries and mutations. DynamoDB bills the requests behind them: with small items, each of the 241 requests reads half a request unit at most, about 120 units per screen, or $15 per million screen views at $0.125 per million reads. Together, about $19 per million views of one screen. That is rarely the bill that hurts. The latency of three sequential rounds of requests, and throttling when the comment-author fan-out hits one popular user's partition, are.

Four ways to cut it

1. Ask for less: a selection set without comment authors removes 200 of the 241 requests. The cheapest fix is often in the client.

2. Denormalize what every screen shows: store the author's name and avatar on the comment, and update it when a profile changes.

3. Batch: a Lambda resolver with batching collects the 200 author lookups into two BatchGetItem calls.

4. Move relational data to Postgres: one query with two joins returns the whole screen, and the GraphQL or REST layer above it stays.