El modelo de costes de DynamoDB: por qué el SQL puede ocultar la factura

Ejecutar SQL real contra DynamoDB es potente: obtienes JOINs, GROUP BY y cláusulas WHERE arbitrarias sobre una base de datos que de forma nativa no ofrece ninguna de ellas. Pero SQL se diseñó para un motor con un planificador de consultas e índices secundarios en cada columna, y DynamoDB no tiene ninguno de los dos. Un SELECT perfectamente legal puede compilarse en un Scan de tabla completa que lee —y te factura— cada elemento de la tabla.

Este es el doble filo de la abstracción de SQL: hace que los patrones de acceso caros parezcan gratuitos. Esta guía explica el modelo de costes que hay debajo, para que la comodidad nunca se convierta en una factura sorpresa, y muestra cómo DynoTable expone el coste antes de que ejecutes la consulta.

¿Por qué el SQL sobre DynamoDB cuesta más de lo que parece?

Una base de datos relacional puede responder WHERE status = 'active' de forma eficiente porque construye un índice para cualquier columna que le pidas. DynamoDB no. Responde de forma eficiente sobre exactamente una cosa: la clave de partición (opcionalmente acotada por una clave de ordenación o un índice secundario global). Cualquier otra cosa es un Scan.

• Una igualdad de clave de partición es una Query. DynamoDB salta directamente a los elementos bajo esa clave y lee solo esos. Acotado y barato.
• Cualquier otra cosa es un Scan + Filter. DynamoDB lee cada elemento de la tabla, y luego aplica tu WHERE como una FilterExpression —después de la lectura. Se te factura por todo lo que escaneó, no por el puñado de filas devueltas.

Ese último punto es la trampa. Una cláusula WHERE parece que reduce el trabajo. En un atributo que no es clave, solo reduce la salida: el coste de lectura ya se ha gastado.

Query frente a Scan: las matemáticas de RCU

DynamoDB factura las lecturas en unidades de capacidad de lectura (RCU):

• 1 RCU = una lectura fuertemente consistente de un elemento de hasta 4 KB. Las lecturas eventualmente consistentes cuestan la mitad de una unidad. Las lecturas se redondean hacia arriba por cada 4 KB.
• Una Query lee solo los elementos bajo una clave de partición: el coste escala con los elementos coincidentes, no con la tabla.
• Un Scan lee toda la tabla, de 4 KB en 4 KB. Una tabla de 1 GB son aproximadamente 262,000 RCU eventualmente consistentes para una sola pasada completa — cada pasada, cada vez.

Una FilterExpression no reduce ese número. El filtrado ocurre después de la lectura, así que un Scan filtrado cuesta exactamente lo mismo que uno sin filtrar. Calcula los números reales para tus datos con la calculadora de tamaño de elemento y la calculadora de precios.

¿Qué construcciones de SQL se convierten silenciosamente en Scans?

• WHERE sin una igualdad de clave de partición → un Scan completo con un filtro posterior a la lectura.
• JOIN → no hay join del lado del servidor en DynamoDB. Cada tabla unida se obtiene por separado y se ensambla en el cliente — un patrón de acceso N+1, una petición por cada fila unida.
• COUNT, SUM, GROUP BY, agregados → no existe agregación del lado del servidor, así que se lee cada elemento coincidente. Sobre un Scan, eso significa leer la tabla entera.
• ORDER BY o DISTINCT en un atributo que no es clave → la ordenación y la eliminación de duplicados ocurren en el cliente sobre lo que se haya escaneado.

Ninguna de estas es incorrecta de ejecutar — a veces un Scan es exactamente lo que quieres. La cuestión es saber cuándo estás ejecutando uno.

¿Cómo mantengo el SQL honesto en cuanto al coste?

• Diseña las claves en torno a tus patrones de acceso. La consulta más barata es la que tu esquema de claves ya responde. Planifícalo con la herramienta de diseño de tabla única y la guía de query frente a scan.
• Pon una igualdad de clave de partición en el WHERE para obtener una Query en vez de un Scan.
• Añade un GSI para un segundo patrón de acceso en lugar de escanear y filtrar.
• Lee el coste antes de ejecutar. El Workbench de DynoTable compila tu SQL a la operación real de DynamoDB y muestra el plan —Scan frente a Query, qué índice usa, la condición de clave frente al filtro posterior al Scan, y un coste estimado de RCU— y luego marca los Scans completos y los joins N+1 en línea. Es el EXPLAIN que DynamoDB nunca lanzó. Consulta también por qué los scans son lentos y caros y capacidad bajo demanda frente a aprovisionada.

¿El SQL de DynoTable empeora el problema del coste?

No — porque hace el coste visible. La crítica al SQL-sobre-DynamoDB es justa: una abstracción que oculta los scans te deja pegarte un tiro en el pie. La respuesta de DynoTable no es eliminar el SQL, sino poner una radiografía de coste detrás. Cada consulta en el Workbench previsualiza su forma real de DynamoDB antes de ejecutarse, así que conservas la ergonomía de SQL y la honestidad sobre las RCU y el diseño de claves que el modelo nativo te da.

¿Necesito el agente de IA para algo de esto?

No — el visor de tablas, el SQL Workbench y la vista previa del coste funcionan por completo sin él. El agente de IA es una de las funciones estrella de DynoTable — un agente de programación nativo de DynamoDB que escribe consultas conscientes del esquema, transforma datos y más — y está ahí siempre que lo quieras. Se ejecuta en tu propio AWS Bedrock, así que pagas a AWS directamente a precio de coste (sin recargo), y tus datos nunca salen de tu cuenta. Actívalo cuando ayude; el cliente principal está completo de todas formas.

¿Es portable mi trabajo?

Sí. DynoTable habla estándares, no un jardín amurallado: SQL estándar, credenciales de AWS y SSO estándar, exportación a CSV/JSON, exportación del esquema inferido a TypeScript, JSON-Schema o Zod, y un servidor MCP para que tus propias herramientas y agentes puedan conectarse. Tus consultas, configuraciones y esquemas se exportan limpiamente — nada queda bloqueado.

Pruébalo

Descarga DynoTable y abre el SQL Workbench contra tu propia tabla — la vista previa del coste te muestra lo que cuesta realmente cada consulta antes de que la ejecutes.