Does DynamoDB support GraphQL?

Yes, through AWS AppSync. AppSync is AWS's managed GraphQL service, and DynamoDB is one of its native data sources: resolvers map each GraphQL query or mutation to a DynamoDB operation such as GetItem, Query, or PutItem. DynamoDB itself has no GraphQL endpoint — the GraphQL layer runs in front of it.

How the pairing works

In AppSync you register a DynamoDB table as a data source, then attach a resolver to each field of your GraphQL schema. The resolver's request handler translates the incoming GraphQL arguments into a DynamoDB call, and its response handler shapes the item(s) DynamoDB returns back into the GraphQL response. AWS lists AppSync first among DynamoDB's serverless integrations for exactly this pattern.

Why it's a common stack

Both halves are serverless: AppSync scales the API layer while DynamoDB scales storage and throughput, with no servers on either side. Real-time GraphQL subscriptions pair naturally with DynamoDB's single-digit-millisecond writes.

What one nested field costs

A resolver per field means a DynamoDB request per field. posts { author { name } } resolves the list once, then resolves author once per post, and each of those is billed separately.

Measured with ReturnConsumedCapacity against a table holding 25 posts in one item collection and 25 author items, each about 920 bytes:

Query, the 25 posts                        ConsumedCapacity 3.0
25 GetItem calls, one author each          ConsumedCapacity 12.5
1 BatchGetItem, the same 25 author keys    ConsumedCapacity 12.5

The nested field costs over four times the query that produced the list. Batching does not change that: BatchGetItem (an AppSync resolver operation in its own right, capped at 100 keys and 16 MB per call) collapses 25 round trips into one, but it still reads 25 items and bills 25 reads. It buys latency, not capacity.

At ten of those GraphQL queries per second that is $50.92 a month of read request units in us-east-1 on-demand, $41.06 of it the author field alone — the pricing calculator runs the same arithmetic on your own numbers.

Which is why the fix is in the key design and not in the resolver. Project what the nested field returns into the parent item or into a GSI, so the list query already carries it and the child resolver has nothing to fetch.

The alternative: bring your own server

Nothing requires AppSync — any GraphQL server (Apollo, Yoga, and others) can resolve fields by calling DynamoDB through the AWS SDK, exactly as it would call any other backend. The trade-off is that you operate the GraphQL layer yourself.

Go deeper

GraphQL resolvers still hit the same access-pattern rules — the data modeling guide explains how to design keys that serve your queries, the expression builder generates the underlying condition syntax, and DynoTable lets you inspect what your resolvers actually wrote.

References

Last verified 2026-07-13 against the official AWS documentation linked above.

Capacity figures measured 2026-07-28 against DynamoDB Local 3.3.0 via @aws-sdk/client-dynamodb 3.1095.0 on Node 24.18.0; the ConsumedCapacity values above are the engine's own. Costs computed from the us-east-1 on-demand request-unit price in our synced AWS pricing table.