Rendimiento bajo demanda de DynamoDB: medido
¿Cuánto rendimiento tiene una tabla DynamoDB bajo demanda recién creada?
Una tabla recién creada sirve unas 4,130 escrituras por segundo — AWS documenta 4,000 — y al menos 12,700 lecturas con consistencia eventual por segundo. Medimos ambas cifras el 2026-08-27 contra una tabla creada minutos antes: las escrituras se clavaron en 4,130 ±2/s en toda carga por encima de la línea base que le ofrecimos, y las lecturas nunca sufrieron throttling antes de que nuestro propio generador de carga se quedara sin margen.
Esas dos cifras, y todo lo demás en esta página, salen de contar solicitudes reales contra el servicio en vivo — no de repetir la documentación. El método, los datos en bruto y los tres intentos fallidos están contados en la historia del benchmark; esta página es la referencia donde viven las cifras.
El techo de escritura en una tabla nueva
La carga ofrecida subió en rampa por ventanas de 30 segundos contra una tabla que nunca había visto tráfico. Cada solicitud llevaba un Item de ~1 KB con una clave uniformemente aleatoria — sin ninguna de por medio:
| Ofrecido (escrituras/s) | Conseguido | Solicitudes con throttle |
|---|---|---|
| 1,000 | 1,000 | 0 |
| 2,000 | 2,000 | 0 |
| 3,000 | 3,000 | 0 |
| 4,000 | 4,000 | 0 |
| 5,000 | 4,132 | 25,992 |
| 6,000 | 4,131 | 55,966 |
| 8,000 | 4,134 | 115,922 |
La línea base documentada de 4,000 escrituras/s se cumple, con cerca de un 3% de margen por encima. El techo es notablemente plano: 4,132, 4,131, 4,134 conseguidas por segundo a 5,000, 6,000 y 8,000 ofrecidas. La latencia no se degrada al cruzarlo: la latencia p50 de escritura se mantuvo en 4–5 ms dentro de la región en todas las ventanas. El servicio no se ralentiza; rechaza.
Lo que devuelve realmente el throttle
El primer rechazo llegó entre 0.9 y 3.8 segundos dentro de cada ventana por encima de la línea base (cuanto más alta la tasa ofrecida, antes llegaba). Textual:
ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.htmlDos cosas a tener en cuenta. Es un HTTP 400, no un 5xx — una política de reintentos o una alerta que solo vigila los 5xx se perderá por completo el throttling bajo demanda (los SDK sí lo reintentan por defecto; consulta ). Y la pista sobre la clave caliente es una sugerencia por defecto, no un diagnóstico — nuestras claves eran uniformemente aleatorias, así que a pequeña escala el primer sospechoso de este mensaje es el techo a nivel de tabla, no tu esquema de claves. Las cuatro causas distintas de throttling tienen su propia guía.
El techo de lectura
Las lecturas corrieron contra una segunda tabla nueva sembrada con 1,000 Items,
como GetItems (~1 KB, 0.5
unidades de lectura cada uno):
| Ofrecido (lecturas/s) | Conseguido | Solicitudes con throttle |
|---|---|---|
| 4,000 | 4,000 | 0 |
| 8,000 | 7,941 | 0 |
| 12,000 | 11,119 | 0 |
| 16,000 | 12,762 | 0 |
Cero throttles en cada tasa. La línea base documentada de 12,000 lecturas/s se cumple, y no pudimos encontrar su borde real: a 16,000/s ofrecidas, cinco de nuestros ocho runners se saturaron en el cliente, así que 12,762/s es donde topó nuestra flota — no donde topó DynamoDB. Las lecturas respondieron a 2–4 ms de p50 dentro de la región.
Cómo crece el techo bajo carga sostenida
AWS documenta que la capacidad bajo demanda crece para admitir hasta el doble del pico anterior, y que superar el doble del pico anterior en 30 minutos puede provocar throttling. Mantuvimos 8,000 escrituras/s de carga ofrecida contra una tabla durante 34 minutos seguidos (cuatro tramos de 8 minutos con menos de un minuto de pausa entre ellos) y vimos moverse el techo, minuto a minuto:
| Tramo | Empezó | Escrituras/s conseguidas, minuto a minuto |
|---|---|---|
| 1 | 06:06 UTC | 4,019 → 4,001 → 4,001 → 3,999 → 3,998 → 4,000 → 4,000 → 4,000 |
| 2 | 06:15 UTC | 5,046 → 5,000 → 4,996 → 4,990 → 4,991 → 4,998 → 4,992 → 4,993 |
| 3 | 06:24 UTC | 5,046 → 4,973 → 4,991 → 4,981 → 4,983 → 4,989 → 4,993 → 5,978 |
| 4 | 06:32 UTC | 7,006 → 6,991 → 6,979 → 6,996 → 6,991 → 6,988 → 7,002 → 6,990 |
Leyendo la línea de tiempo:
- El primer techo es pegajoso. Durante los 8 minutos enteros del primer tramo, la tabla se mantuvo en su línea base de ~4,000/s — la sobredemanda sostenida no lo movió dentro de esa ventana.
- El crecimiento llega en escalones de ~1,000/s, no en rampa. El techo saltó a ~5,000/s hacia el minuto 9, a ~6,000/s hacia el minuto 26, y a ~7,000/s un minuto después, y se mantuvo plano en 7,000/s hasta el final. Cada escalón aparece de golpe entre un minuto y el siguiente. Dos de los tres escalones cayeron cerca de los límites entre tramos, así que las pausas de menos de un minuto podrían interactuar con el mecanismo de crecimiento — reportamos el momento tal como se observó.
- Media hora de demanda sostenida no duplicó el techo. Tras 34 minutos a 8,000/s ofrecidas, la tabla servía 7,000/s — 1.75× su techo inicial, todavía por debajo tanto de la tasa ofrecida como de una duplicación limpia. Las solicitudes con throttle cayeron tramo tras tramo (1.9M → 0.5M) a medida que crecía la capacidad.
Si el tráfico del día de lanzamiento va a superar las ~4,000 escrituras/s en una tabla nueva, precaliéntala: dirige carga sintética antes del evento, o fija de forma explícita el rendimiento máximo bajo demanda de la tabla y deja que AWS aprovisione para él. La guía de bajo demanda frente a aprovisionado cubre cuándo gana cada modo, y auto scaling es la contrapartida en modo aprovisionado de lo que aquí viste ocurrir de forma automática.
Dos cifras que nos sorprendieron
- El tiempo de creación hasta
ACTIVEvaría 3×. Una tabla bajo demanda nueva alcanzóACTIVEen 7.4 segundos en una ejecución y en 22 segundos en otras dos, misma región, mismo esquema. Presupuesta para el caso lento en cualquier diseño de una-tabla-por-inquilino o una-tabla-por-prueba. - Todo el benchmark costó $0.97. 672,116 escrituras facturadas y 1.08 millones de lecturas. La ejecución de 34 minutos de crecimiento sostenido costó $12.67 más. Medir el servicio tú mismo sale más barato que una sola decisión de capacidad equivocada — y puedes calcular el precio de una carga de trabajo así con antelación con la calculadora de precios de DynamoDB.
Alcance y método, con honestidad
Todo lo anterior es una tabla por fase, un día, una región (us-east-1), Items de ~1 KB, claves uniformemente aleatorias. Los límites por partición (3,000 unidades de lectura / 1,000 unidades de escritura por segundo) están por debajo del comportamiento a nivel de tabla medido aquí y tienen sus propios modos de fallo. Las cuotas a nivel de cuenta y los límites duros del servicio están en la referencia de límites de DynamoDB, medidos de la misma forma. Y si trabajas con DynamoDB a diario, DynoTable es nuestro cliente de escritorio para ello — hecho por el mismo equipo, con la misma costumbre de comprobar las afirmaciones contra el servicio en vivo antes de repetirlas.