¿DynamoDB admite GraphQL?

Sí, a través de AWS AppSync. AppSync es el servicio de GraphQL gestionado de AWS, y DynamoDB es uno de sus orígenes de datos nativos: los resolvers mapean cada consulta o mutación de GraphQL a una operación de DynamoDB como GetItem, Query o PutItem. DynamoDB en sí no tiene ningún endpoint de GraphQL — la capa de GraphQL se ejecuta delante.

Cómo funciona la combinación

En AppSync registras una tabla de DynamoDB como origen de datos y luego asocias un resolver a cada campo de tu esquema de GraphQL. El handler de petición del resolver traduce los argumentos de GraphQL entrantes en una llamada a DynamoDB, y su handler de respuesta da forma al elemento o elementos que devuelve DynamoDB para la respuesta de GraphQL. AWS lista AppSync el primero entre las integraciones serverless de DynamoDB precisamente por este patrón.

Por qué es un stack habitual

Las dos mitades son serverless: AppSync escala la capa de API mientras DynamoDB escala el almacenamiento y el rendimiento, sin servidores por ninguna de las dos partes. Las suscripciones de GraphQL en tiempo real encajan de forma natural con las escrituras de milisegundos de un solo dígito de DynamoDB.

Lo que cuesta un campo anidado

Un resolver por campo significa una petición a DynamoDB por campo. posts { author { name } } resuelve la lista una vez y luego resuelve author una vez por post, y cada una de esas se factura por separado.

Medido con ReturnConsumedCapacity contra una tabla con 25 posts en una colección de elementos y 25 elementos de autor, de unos 920 bytes cada uno:

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

El campo anidado cuesta más de cuatro veces lo que la consulta que produjo la lista. Agrupar no cambia eso: BatchGetItem (una operación de resolver de AppSync por derecho propio, con un tope de 100 claves y 16 MB por llamada) reduce 25 viajes de ida y vuelta a uno, pero sigue leyendo 25 elementos y facturando 25 lecturas. Compra latencia, no capacidad.

A diez de esas consultas de GraphQL por segundo, eso son 50,92 $ al mes en unidades de petición de lectura en us-east-1 bajo demanda, de los cuales 41,06 $ son solo del campo author — la calculadora de precios hace la misma aritmética con tus propias cifras.

Y por eso la solución está en el diseño de las claves y no en el resolver. Proyecta lo que devuelve el campo anidado dentro del elemento padre o dentro de un GSI, para que la consulta de la lista ya lo lleve y al resolver hijo no le quede nada que buscar.

La alternativa: pon tu propio servidor

Nada obliga a usar AppSync — cualquier servidor de GraphQL (Apollo, Yoga y otros) puede resolver campos llamando a DynamoDB mediante el SDK de AWS, exactamente igual que llamaría a cualquier otro backend. El compromiso es que la capa de GraphQL la operas tú.

Profundiza

Los resolvers de GraphQL siguen sujetos a las mismas reglas de patrones de acceso — la guía de modelado de datos explica cómo diseñar claves que sirvan a tus consultas, el constructor de expresiones genera la sintaxis de condición subyacente, y DynoTable te deja inspeccionar lo que tus resolvers escribieron realmente.

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

Cifras de capacidad medidas el 2026-07-28 contra DynamoDB Local 3.3.0 mediante @aws-sdk/client-dynamodb 3.1095.0 sobre Node 24.18.0; los valores de ConsumedCapacity de arriba son los del propio motor. Costes calculados a partir del precio bajo demanda por unidad de petición en us-east-1 de nuestra tabla de precios de AWS sincronizada.