DynamoDB vs ElastiCache

DynamoDB y Amazon ElastiCache almacenan datos en AWS y de ambos se dice que son rápidos, pero responden a preguntas distintas. DynamoDB es una base de datos de registro totalmente gestionada y serverless: las escrituras se persisten en disco y se replican entre zonas de disponibilidad. ElastiCache es, en palabras de la propia AWS, "un servicio web que facilita configurar, gestionar y escalar un almacén de datos en memoria distribuido o un entorno de caché en la nube". Para la mayoría de los sistemas la comparación útil no es DynamoDB o ElastiCache — es qué caché, si es que hace falta alguna, debe ir delante de DynamoDB.

¿Deberías usar DynamoDB o ElastiCache?

Usa DynamoDB para los datos que no te puedes permitir perder: Items duraderos leídos y escritos por clave a cualquier escala. Usa ElastiCache como capa en memoria — caché, estado de sesión, limitación de tasa, tablas de clasificación, pub/sub — donde las lecturas de microsegundos importan más que las garantías de durabilidad. Si añades una caché específicamente para acelerar DynamoDB, la decisión real es ElastiCache frente a DAX, la caché propia de DynamoDB; esa comparación está más abajo.

DynamoDB vs ElastiCache de un vistazo

Característica	DynamoDB	ElastiCache
Rol	Base de datos de registro duradera	Almacén de datos en memoria o caché gestionado
Motores	Un único motor gestionado (el propio DynamoDB)	Valkey, Memcached y Redis OSS
Modelo de datos	NoSQL clave-valor y documento; Items tipados de hasta 400 KB	Depende del motor — cadenas, hashes, listas, conjuntos, conjuntos ordenados y streams en Valkey/Redis OSS; clave-valor plano en Memcached
Durabilidad	Cada escritura persistida en disco y replicada entre zonas de disponibilidad	En memoria por defecto; los clústeres Valkey basados en nodos pueden habilitar la durabilidad mediante un registro transaccional distribuido Multi-AZ
Consistencia	Consistencia eventual por defecto; lecturas fuertemente consistentes disponibles por solicitud	Fuertemente consistente en un nodo primario para sus propias claves; las lecturas de réplica pueden retrasarse
Acceso	API nativa (`GetItem`, `Query`, `Scan`, …) más PartiQL	Comandos del motor sobre un endpoint de caché; sin lenguaje de consulta entre claves
Modelo de capacidad	Almacenamiento en disco; escala con el volumen de datos	Limitado por la memoria aprovisionada — la versión serverless la escala por ti, los clústeres basados en nodos los dimensionas tú
Modelo operativo	Serverless; nada que aprovisionar ni parchear	Caché serverless o clúster basado en nodos; AWS gestiona el aprovisionamiento, la monitorización, el reemplazo de nodos y el parcheo
Uso típico	Registros que deben sobrevivir	Capas cache-aside, almacenes de sesiones, límites de tasa, colas y pub/sub

Cuándo DynamoDB es la mejor opción

Los datos deben sobrevivir. DynamoDB persiste y replica cada escritura por defecto. Una caché de ElastiCache es en memoria primero; la durabilidad es algo que habilitas en clústeres Valkey basados en nodos, no la postura por defecto.
Tu conjunto de trabajo supera la memoria. El coste de DynamoDB sigue al almacenamiento. La capacidad de ElastiCache está limitada por la RAM que aprovisiones o por la memoria a la que escale la caché serverless.
Necesitas lecturas fuertemente consistentes. DynamoDB las ofrece por solicitud. Una caché delante de una base de datos es, por construcción, eventualmente consistente con ella.
Quieres el plano de control de AWS. La recuperación a un punto en el tiempo, las copias de seguridad, Streams, IAM y los desencadenadores de Lambda son configuración sobre una tabla de DynamoDB.

Cuándo ElastiCache es la mejor opción

Necesitas lecturas de microsegundos. Los datos en RAM responden más rápido que el almacenamiento duradero, sea cual sea la base de datos que haya detrás.
Necesitas estructuras de datos ricas en memoria. Los conjuntos ordenados, los contadores, los streams y el pub/sub son de primera clase en Valkey y Redis OSS, y modelarlos en un almacén duradero da trabajo.
Los datos son realmente efímeros. Las sesiones, las ventanas de limitación de tasa y los resultados recalculables encajan con el ciclo de vida de una caché.
Estás cacheando algo más que DynamoDB. ElastiCache se sitúa delante de cualquier cosa — RDS, Aurora, una API, un índice de búsqueda. DAX solo acelera DynamoDB.

Usarlos juntos

La forma habitual en producción es tener ambos: DynamoDB guarda los registros duraderos y una capa en memoria absorbe las lecturas calientes. ElastiCache hace esto como un nivel cache-aside genérico para el que tú escribes el código — tu aplicación consulta la caché, recurre a DynamoDB y rellena la caché cuando falla. DynamoDB también ofrece su propia alternativa, DAX, que hace esto sin el código de cache-aside.

ElastiCache o DAX delante de DynamoDB

Esta es la decisión que la mayoría de los equipos está tomando en realidad, y la documentación de AWS la responde con más precisión que las páginas de marketing.

DAX es de instalación directa; ElastiCache es un cambio de código. DAX es "compatible con la API de DynamoDB. Por tanto, requiere solo cambios funcionales mínimos para usarlo con una aplicación existente". Reduce las lecturas de consistencia eventual "en un orden de magnitud, de milisegundos de un solo dígito a microsegundos". Con ElastiCache escribes y mantienes tú la lógica de cache-aside, incluida la invalidación.

Cuatro razones documentadas por las que DAX puede no encajar. AWS enumera los casos en los que DAX no es idóneo, y cada uno se corresponde con una carga de trabajo real:

Lecturas fuertemente consistentes. DAX sirve datos de consistencia eventual. Si una ruta de lectura necesita ConsistentRead, DAX no es una opción para ella.
Cargas de trabajo intensivas en escritura. "Un alto volumen de escrituras conlleva una mayor replicación entre los nodos DAX de un clúster", lo que eleva el uso de recursos y el riesgo de disponibilidad.
Tasas bajas de lecturas repetidas. "DAX rinde mejor cuando las tasas de acierto de caché superan el 90 %". Por debajo de eso, los fallos de caché te cuestan recursos sin comprarte mucha latencia.
Soporte de lenguajes. "DAX admite aplicaciones escritas en Go, Java, Node.js, Python y .NET, usando clientes proporcionados por AWS". Si tu servicio está en Rust, Ruby, PHP o Elixir, DAX te queda prácticamente cerrado y ElastiCache — accesible desde cualquier cliente de Valkey, Redis OSS o Memcached — es la opción práctica. Esta única línea decide la cuestión más a menudo que cualquier benchmark de latencia, y es fácil pasarla por alto.

DAX además "solo está disponible para la plataforma EC2-VPC".

La trampa de DAX que conviene conocer antes de modelar. AWS documenta una limitación que choca con una costumbre habitual al modelar en DynamoDB:

Los clústeres DAX mantienen metadatos sobre los nombres de atributo de los Items que almacenan. Esos metadatos se conservan indefinidamente (incluso después de que el Item haya caducado o haya sido expulsado de la caché). Las aplicaciones que usan un número ilimitado de nombres de atributo pueden, con el tiempo, provocar el agotamiento de la memoria del clúster DAX. Esta limitación se aplica solo a los nombres de atributo de nivel superior, no a los nombres de atributo anidados.

Léelo contra la forma en que la gente construye Items dispersos o heterogéneos. Un Item cuyos valores son marcas de tiempo y UUID no da problemas. Un Item que usa una marca de tiempo, un ID de sesión o un ID de inquilino como nombre de atributo de nivel superior — una forma que aparece cuando se aplana un mapa sobre el Item para mantenerlo consultable — hace crecer los metadatos de DAX para siempre. La caché no recupera ese espacio cuando el Item es expulsado.

La mitigación es de modelado, no de configuración: mantén los identificadores en los valores de los atributos y anida las claves variables un nivel por debajo, dentro de un mapa, donde la limitación explícitamente no se aplica. ElastiCache no tiene una restricción equivalente, porque no hace ningún seguimiento del schema de tus Items.

La durabilidad ya no es una línea divisoria limpia. La afirmación habitual de que ElastiCache no puede ser duradero está desactualizada. AWS documenta que "en los clústeres Valkey basados en nodos, puedes habilitar la durabilidad para persistir tus datos en un registro transaccional distribuido Multi-AZ", y que "con la durabilidad habilitada, tus datos están protegidos incluso si fallan todos los nodos de caché". Eso no convierte a ElastiCache en un sistema de registro — pero sí significa que "la caché lo pierde todo al reiniciarse" no es un argumento que puedas dar sin comprobar antes el motor y el tipo de clúster.

Trabajar con DynamoDB

Sea cual sea la caché que pongas delante, DynoTable es un cliente de escritorio nativo para explorar, editar y consultar las tablas de DynamoDB que hay debajo, en macOS, Windows y Linux. Lee tu cadena de credenciales estándar de AWS, así que no hay nada que migrar. Su cuadrícula decodifica claves compuestas como USER#123 y marca los atributos TTL, lo que hace sencillo ver qué formas de Item — y qué nombres de atributo de nivel superior — tendría que guardar una caché situada delante de la tabla.

Para construir las condiciones de clave y los filtros que necesita tu código de poblado de caché, el DynamoDB Expression Builder gratuito genera salida SDK, CLI y PartiQL lista para pegar sin instalación. DynoTable es una aplicación comercial de código cerrado; esta página describe lo que hace, no cómo está construida.

FAQ

¿Puede ElastiCache reemplazar a DynamoDB?

No como sistema de registro. ElastiCache es un almacén en memoria; incluso con la durabilidad habilitada en un clúster Valkey basado en nodos está diseñado como nivel de caché, no como la base de datos donde viven tus datos. DynamoDB persiste y replica cada escritura entre zonas de disponibilidad por defecto.

¿Es mejor DAX o ElastiCache para DynamoDB?

DAX si tu aplicación está escrita en Go, Java, Node.js, Python o .NET, tus lecturas son de consistencia eventual y tu tasa de acierto de caché superará el 90 % — es compatible con la API, así que apenas cambias código. ElastiCache si necesitas otro lenguaje, necesitas cachear algo más que DynamoDB o quieres estructuras de datos en memoria que DAX no ofrece.

¿ElastiCache pierde datos cuando se reinicia un nodo?

Por defecto es en memoria, así que trátalo como volátil. AWS documenta ahora una durabilidad opcional para clústeres Valkey basados en nodos, que persiste en un registro transaccional distribuido Multi-AZ para que los datos sobrevivan incluso si fallan todos los nodos de caché. Que tu caché sea volátil depende del motor y del tipo de clúster que hayas elegido.

Relacionado

Aprende cuándo usar DynamoDB y cómo el TTL de DynamoDB expira los Items de tipo caché.
Compara DynamoDB y Redis para la cuestión almacén-frente-a-caché en términos generales.
Modela patrones de acceso duraderos con el diseño de tabla única.
Descarga DynoTable para explorar, consultar y editar tus tablas de DynamoDB.

Referencias

Verificado por última vez el 2026-08-02 contra la AWS ElastiCache User Guide y la DynamoDB Developer Guide oficiales. Valkey, Redis OSS y Memcached son marcas comerciales de sus respectivos propietarios; se mencionan aquí solo a efectos de identificación.