KV vs D1 vs Durable Objects en Cloudflare: cuál elegir para cada tipo de estado
20 Jul, 2026 • 7 min de lectura
Cloudflare ofrece tres formas muy distintas de guardar estado desde un Worker — KV, D1 y Durable Objects — y elegir la equivocada no falla de forma obvia: funciona en desarrollo, funciona con poco tráfico, y empieza a dar problemas de consistencia o coste justo cuando la aplicación crece. Esta guía compara las tres opciones por sus características reales, no solo por su nombre de marketing.
Si buscas específicamente el caso de un Durable Object que “olvida” su estado tras un rato de inactividad, ya cubrimos ese incidente concreto (con logs reales y la solución paso a paso) en Cloudflare Durable Objects: el bug silencioso que borra tus sesiones. Este artículo se centra en la decisión de arquitectura: cuál de las tres herramientas usar para cada tipo de dato.
Contenidos
Por qué no hay una respuesta única
Las tres opciones resuelven el mismo problema de fondo — persistir datos accesibles desde Workers desplegados en el edge de Cloudflare — pero con modelos de consistencia y patrones de acceso radicalmente distintos. Elegir mal no es catastrófico de inmediato: KV usado para coordinación en tiempo real “funciona” hasta que dos escrituras casi simultáneas pisan sus datos entre sí porque la propagación global tarda; D1 usado como sustituto de Durable Objects “funciona” hasta que necesitas serializar el acceso a una entidad concreta ante peticiones concurrentes.
Tabla comparativa
| Workers KV | D1 | Durable Objects | |
|---|---|---|---|
| Modelo | Clave-valor, eventualmente consistente | Base de datos SQL (SQLite), consistente | Estado + lógica colocados juntos, fuertemente consistente por instancia |
| Latencia de escritura | Alta propagación global — hasta 60 segundos para verse reflejada en todos los puntos del edge | Baja, centralizada en la base de datos | Muy baja, local a la instancia que procesa la petición |
| Ideal para | Datos de lectura muy frecuente, escritura poco frecuente (configuración, feature flags, caché de contenido) | Datos relacionales, consultas complejas, transacciones | Estado por-entidad con lógica asociada: sesiones, salas de chat/websocket, contadores exactos, coordinación en tiempo real |
| Consistencia | Eventual — una escritura puede tardar en propagarse globalmente | Fuerte, dentro de la misma base de datos | Fuerte, por instancia (serializado — un DO procesa una petición a la vez, sin condiciones de carrera internas) |
| Coordinación entre clientes concurrentes | No apta (sin locks) | Apta vía transacciones SQL | Apta de forma nativa — es su caso de uso principal |
| Coste típico | Muy bajo, orientado a lecturas masivas | Por fila/consulta | Por duración de instancia activa + operaciones de storage |
Cuándo usar KV
Datos que se leen muchísimo más de lo que se escriben, y donde no te importa que una actualización tarde unos segundos (hasta un minuto en el peor caso) en propagarse globalmente por todos los puntos de presencia de Cloudflare: configuración de la aplicación, feature flags, caché de contenido, assets estáticos o metadatos servidos desde el edge más cercano al usuario. El punto fuerte de KV es la lectura ultrarrápida y masivamente distribuida — el punto débil es cualquier escenario donde necesites que una escritura sea visible de inmediato en todo el mundo.
Cuándo usar D1
Cuando necesitas consultas relacionales reales — joins, agregaciones, filtros complejos — sobre datos que no requieren coordinación en tiempo real entre múltiples clientes simultáneos. Piensa en D1 como “tu base de datos SQL tradicional, pero en el edge”: es la opción natural para el histórico de pedidos de una tienda, el catálogo de productos, o cualquier dato que consultarías con SQL en un backend convencional. No es sustituto de Durable Objects para coordinación de estado en vivo — D1 no está diseñado para resolver condiciones de carrera entre peticiones concurrentes sobre el mismo registro con la misma naturalidad que un Durable Object.
Cuándo usar Durable Objects
Cuando necesitas que múltiples peticiones concurrentes sobre la misma entidad se procesen de forma serializada y consistente: una sala de websocket donde el orden de los mensajes importa, un contador que no puede tener condiciones de carrera (por ejemplo, control de inventario en tiempo real, o un sistema de reservas), o sesiones de usuario donde el estado debe ser la fuente única de verdad sin depender de sincronización eventual entre nodos del edge.
La contrapartida, como cubrimos en detalle en el artículo del bug de eviction enlazado más arriba, es que hay que diseñar sabiendo que la memoria en caliente de un Durable Object es efímera: solo lo que escribes explícitamente en state.storage sobrevive a un desalojo por inactividad. Si tu equipo no está familiarizado con este matiz, cuenta con una curva de aprendizaje algo mayor que con KV o D1.
Patrón habitual: combinar los tres
En aplicaciones reales de cierto tamaño, no es raro usar las tres herramientas a la vez, cada una para lo que mejor resuelve:
- KV para configuración global y feature flags que leen todos los Workers, sin necesidad de coordinación.
- D1 para el histórico de datos relacionales — pedidos, usuarios, catálogo — con consultas SQL normales.
- Durable Objects para el estado en vivo de cada sesión activa o sala de coordinación en tiempo real, con escritura periódica a D1 para persistir el resultado final una vez la sesión o el proceso termina.
Un ejemplo concreto: una plataforma de e-commerce podría usar KV para servir la configuración de la tienda (colores, textos, feature flags) con latencia mínima en cualquier punto del mundo; D1 para el catálogo de productos y el histórico de pedidos con consultas relacionales normales; y un Durable Object por carrito de compra activo, para garantizar que dos peticiones simultáneas sobre el mismo carrito (por ejemplo, dos pestañas del mismo usuario) no generen una condición de carrera al actualizar el stock reservado.
Errores comunes al elegir
- Usar KV para algo que necesita consistencia inmediata — típicamente un contador de stock o de plazas disponibles, donde la propagación eventual de KV puede hacer que se vendan más unidades de las que realmente hay disponibles.
- Usar D1 para coordinación en tiempo real entre clientes — funciona a bajo tráfico, pero D1 no está pensado para resolver condiciones de carrera de alta frecuencia sobre el mismo registro con la misma naturalidad que un DO.
- Usar Durable Objects para todo por defecto — es la herramienta más potente de las tres, pero también la de mayor complejidad operativa y coste por instancia activa; si tu caso de uso es simple lectura de configuración, KV es más barato y más simple de razonar.
Resumen
No hay una herramienta “mejor” entre KV, D1 y Durable Objects — hay una herramienta más adecuada según el tipo de consistencia que necesites: KV para lecturas masivas con tolerancia a propagación eventual, D1 para datos relacionales sin necesidad de coordinación en tiempo real, y Durable Objects para estado por-entidad que exige serialización estricta de peticiones concurrentes. La mayoría de aplicaciones Cloudflare de cierto tamaño acaban usando las tres, cada una en la capa donde mejor encaja.