DynamoDB vs Redshift

DynamoDB y Amazon Redshift rara vez son alternativas. DynamoDB es una base de datos operativa — lecturas y escrituras de milisegundos de un solo dígito contra claves conocidas, sirviendo tráfico de aplicación en vivo. Redshift es "un servicio de almacén de datos totalmente gestionado y a escala de petabytes en la nube", construido para recorrer y agregar grandes conjuntos de datos con fines de informes y analítica. Los equipos que ejecutan ambos son el caso normal, y AWS ofrece una integración gestionada para mover datos en un sentido entre ellos.

¿Deberías usar DynamoDB o Redshift?

Usa DynamoDB para los datos en vivo de la aplicación: pedidos que se están realizando, sesiones que se están leyendo, registros recuperados por clave. Usa Redshift cuando alguien necesite hacer preguntas sobre todo el conjunto de datos — ingresos por región y mes, retención por cohortes, un panel que une varias fuentes. La pregunta "¿cuál de los dos?" suele resolverse como "DynamoDB para la ruta de escritura, Redshift para los analistas", con la integración zero-ETL en medio.

DynamoDB vs Redshift de un vistazo

Característica	DynamoDB	Redshift
Carga de trabajo	Operativa (estilo OLTP) — lecturas y escrituras por clave de alto volumen	Analítica — recorridos y agregaciones sobre grandes conjuntos de datos
Modelo de datos	Items NoSQL sin schema de hasta 400 KB; los atributos varían por Item	Tablas relacionales con columnas declaradas, claves de distribución y claves de ordenación
Lenguaje de consulta	API nativa (`GetItem`, `Query`, `Scan`, …) más PartiQL	SQL completo, con todo el instrumental de BI y SQL que eso implica
Joins y agregados	Sin joins del lado del servidor; la agregación no es una operación del servidor	Joins, funciones de ventana, `GROUP BY` y el resto del SQL analítico
Patrón de acceso	Diseñado en torno a claves conocidas; los Scans son la excepción cara	Diseñado para recorrer — leer muchas filas es el caso normal
Latencia	Milisegundos de un solo dígito por solicitud	De segundos a minutos por consulta analítica, sobre muchos más datos
Escalado	Serverless; particiones gestionadas por AWS	Grupos de trabajo serverless o clústeres aprovisionados; capacidad dimensionada a la carga de consultas
Frescura	Lectura de tus propias escrituras bajo demanda	Tan fresca como lo que la cargue — la integración zero-ETL trae las actualizaciones cada 15-30 minutos
Modelo de precios	Por solicitud o capacidad aprovisionada, más almacenamiento	Capacidad de cómputo más almacenamiento; los almacenes serverless inactivos no facturan cómputo

Cuándo DynamoDB es la mejor opción

Tráfico de aplicación en vivo. Lecturas y escrituras predecibles de milisegundos de un solo dígito contra claves conocidas, a cualquier tasa de solicitudes.
Un schema que varía por Item. Los Items heterogéneos en una misma tabla son lo normal en DynamoDB; un almacén de datos quiere columnas declaradas.
Operación serverless. Ningún clúster que dimensionar, parchear o pausar.
Rutas intensivas en escritura. DynamoDB absorbe escrituras de alto volumen como tarea principal; un almacén de datos está optimizado para carga masiva y lectura.

Cuándo Redshift es la mejor opción

Preguntas que atraviesan toda la tabla. Agregar un año de pedidos es un recorrido por naturaleza, que es exactamente el patrón de acceso que DynamoDB te pide evitar y para el que Redshift está diseñado.
Joins entre muchas fuentes. Los almacenes de datos hacen joins. DynamoDB no tiene joins del lado del servidor.
Herramientas de BI. Redshift habla SQL sobre JDBC/ODBC, así que encaja en los paneles existentes y en "las mismas herramientas basadas en SQL y aplicaciones de inteligencia empresarial que ya usas hoy".
Análisis que no debe perturbar producción. Ejecutar la analítica contra una copia replicada mantiene la carga fuera de la tabla que sirve a tus usuarios.

Usarlos juntos

El patrón estándar es unidireccional: DynamoDB sirve a la aplicación, una copia aterriza en Redshift y los analistas trabajan sobre la copia. AWS admite dos rutas — el antiguo comando COPY, que carga directamente "desde Amazon S3 o Amazon DynamoDB a Amazon Redshift", y la integración zero-ETL gestionada, que mantiene la copia al día por sí sola.

Qué hace realmente la integración zero-ETL

"Zero-ETL" sugiere una vista en vivo. No lo es, y los detalles importan antes de que diseñes un panel a su alrededor.

Es una tubería de replicación con temporizador. AWS es preciso: "Al activarla, la integración exporta la tabla completa de DynamoDB para poblar la base de datos de Amazon Redshift". Después, "la integración zero-ETL replica de forma incremental las actualizaciones de DynamoDB a Amazon Redshift cada 15-30 minutos usando exportaciones incrementales de DynamoDB". Es decir, los datos en Redshift pueden tener hasta media hora de retraso. Eso está bien para informes diarios y está mal para cualquier cosa en la que un usuario deba ver reflejada su última acción.

La recuperación a un punto en el tiempo es obligatoria — y ahora la razón es evidente. El prerrequisito se enuncia con claridad: "Una integración zero-ETL entre Amazon DynamoDB y Amazon Redshift requiere que tu tabla de DynamoDB de origen tenga habilitada la recuperación a un punto en el tiempo (PITR)". AWS documenta el requisito en un sitio y el mecanismo en otro, y no los conecta, pero la política basada en recursos que debes adjuntar lo delata — concede a redshift.amazonaws.com la acción dynamodb:ExportTableToPointInTime. La integración está construida sobre la maquinaria de exportación a S3 de DynamoDB, y esa maquinaria lee de la copia de seguridad continua. Sin PITR no hay exportación, y sin exportación no hay integración.

Eso tiene una consecuencia presupuestaria con la que la gente se topa tarde: habilitar PITR en una tabla grande es un cargo recurrente sobre el tamaño de la tabla, asumido por la tubería de analítica y no por la recuperación. Presupuesta la integración como "Redshift más PITR", no como Redshift a secas — la calculadora de precios de DynamoDB gratuita dimensionará la parte de almacenamiento antes de que te comprometas.

Dos restricciones que bloquean tablas existentes. Ambas son limitaciones documentadas, y ambas son incómodas de arreglar a posteriori:

"La tabla de DynamoDB y el clúster de Amazon Redshift tienen que estar en la misma región". Un almacén de datos que consolide varias regiones no puede traerlas todas por esta vía.
"La tabla de DynamoDB de origen debe estar cifrada con una clave de AWS KMS propiedad de Amazon o gestionada por el cliente. El cifrado gestionado por Amazon no está admitido para la tabla de DynamoDB de origen". Las tablas creadas con cifrado gestionado por AWS necesitan cambiar su configuración de cifrado antes de poder crear una integración.

Dónde te muerde la forma de tus datos. Los Items de DynamoDB son heterogéneos por diseño; las tablas de un almacén de datos tienen columnas. Un diseño de tabla única que sostiene varios tipos de entidad bajo una misma convención de clave de partición no se convierte en un esquema en estrella limpio por el hecho de replicarse. Cuenta con trabajo de modelado en Redshift después de que aterricen los datos — la integración elimina la tubería, no el diseño del schema.

Cuándo todavía no necesitas un almacén de datos

No toda agregación es un problema de analítica. Buena parte de los "deberíamos meter esto en Redshift" empieza como una única pregunta — cuántos Items hay en este estado, cuál es el total de este cliente, qué claves de partición dominan — hecha de vez en cuando, por una persona de ingeniería, contra una tabla.

El SQL Workbench de DynoTable responde a esa clase de pregunta directamente contra DynamoDB, bajo demanda: SQL de verdad con COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING y DISTINCT, más INNER/LEFT JOIN. El posicionamiento es deliberadamente estrecho — SQL dentro de las reglas de patrones de acceso de DynamoDB. Es un único SELECT; no hay CTE, ni UNION, ni funciones de ventana, ni subconsultas escalares; el objetivo de un join debe ser una clave de partición o la clave de partición de un GSI. Los resultados llegan en streaming con un distintivo de parcial y se vuelven exactos cuando la consulta se ejecuta hasta el final, y leer los datos sigue costando las lecturas que cuesta.

Eso no sustituye a un almacén de datos, y los límites de arriba son la frontera honesta. Pero es una respuesta más rápida que una tubería de replicación, un cargo de PITR y un diseño de schema — y te dice si la pregunta merecía un almacén de datos antes de que construyas uno. Ejecutar consultas en el Workbench es una función de pago; el editor y el autocompletado son gratuitos. DynoTable es una aplicación comercial de código cerrado; esta página describe lo que hace, no cómo está construida.

FAQ

¿Puede Redshift reemplazar a DynamoDB?

No, no para tráfico de aplicación. Redshift es un almacén de datos construido para recorrer y agregar; no está diseñado para servir búsquedas por clave de alto volumen con latencia de milisegundos de un solo dígito. Los dos se ejecutan uno junto al otro, con DynamoDB sirviendo a la aplicación y una copia replicada en Redshift sirviendo a la analítica.

¿Cómo de frescos están los datos de DynamoDB en Redshift?

Con la integración zero-ETL, con hasta unos 30 minutos de retraso. AWS documenta que, tras la exportación completa inicial, "replica de forma incremental las actualizaciones de DynamoDB a Amazon Redshift cada 15-30 minutos usando exportaciones incrementales de DynamoDB". Trátalo como informes casi en tiempo real, no como una vista en vivo.

¿Por qué la integración zero-ETL requiere PITR?

Porque está construida sobre la exportación a un punto en el tiempo de DynamoDB. La política basada en recursos que necesita la integración concede a Amazon Redshift la acción dynamodb:ExportTableToPointInTime, y esa exportación lee de la copia de seguridad continua que mantiene PITR. Habilitar PITR es, por tanto, un coste real y permanente de la integración.

Relacionado

Aprende cuándo usar DynamoDB y por qué los Scans son caros.
Compara DynamoDB y PostgreSQL para la cuestión relacional operativa.
Modela los patrones de acceso desde el principio con el diseño de tabla única.
Dimensiona la parte de almacenamiento y capacidad con la calculadora de precios de DynamoDB gratuita.
Descarga DynoTable para consultar y agregar tus tablas de DynamoDB directamente.

Referencias

Verificado por última vez el 2026-08-02 contra la AWS Redshift Management Guide y la DynamoDB Developer Guide oficiales.