Llamar a D1 una “base de datos en el borde” crea una expectativa que la arquitectura no cumple completamente. La imagen mental es la de SQLite ejecutándose en los 300 centros de datos de Cloudflare simultáneamente, con sus consultas respondiendo desde el punto geográficamente más cercano al usuario. La realidad es más restringida: hay una región primaria donde se realizan todas las escrituras y réplicas de lectura repartidas por la red que reciben estas escrituras con un retraso de hasta 60 segundos. Si su banco principal está en América del Norte y escribe desde un trabajador que se ejecuta en São Paulo, esa escritura viaja de 80 a 150 milisegundos de ida y vuelta antes de ser confirmada. Quickstart no menciona esto.
La verdadera arquitectura de D1
D1 utiliza SQLite como motor de base de datos, el mismo SQLite que se ejecuta en navegadores, dispositivos móviles y aplicaciones de escritorio. Además de este motor, Cloudflare creó una capa de replicación: una instancia principal recibe todas las escrituras y propaga los cambios para leer las réplicas distribuidas en la red global.
Cuando creas un banco D1, eliges (o dejas que Cloudflare elija automáticamente) tu región principal. Esta elección determina dónde aterrizan los escritos. Una lectura realizada por un Worker que se ejecuta en São Paulo puede ser atendida por una réplica cercana, con una latencia adicional de 5 a 20 milisegundos sobre el tiempo de ejecución del Worker. Una escritura realizada por el mismo trabajador va a la región principal y, si esta región es us-east-1, el viaje de ida y vuelta es de 80 a 150 ms solo de red antes de recibir la confirmación.
El tiempo de propagación de la réplica es relevante en producción: una escritura en la primaria puede tardar hasta 60 segundos en aparecer en todas las réplicas. Durante este intervalo, un trabajador que lee desde una réplica obsoleta ve datos previos a la escritura. Este comportamiento se denomina coherencia final: la réplica convergerá al estado correcto, pero no de inmediato.
El problema de coherencia que encontrarás en producción.
El patrón que rompe con la eventual coherencia es la escritura seguida inmediatamente por la lectura. Crea un usuario, lo redirige a la página de perfil y la consulta que carga el perfil llega a una réplica que aún no ha recibido el INSERT. El resultado es un perfil vacío, un error 404 o un estado inconsistente que el usuario ve y no comprende.
Este problema existe en cualquier base de datos con replicación, pero con D1 aparece sin previo aviso porque la abstracción vinculante oculta qué réplica se está consultando. Cloudflare creó la API Sessions exactamente para este caso: dentro de la misma sesión D1, una escritura garantiza que la lectura posterior verá los datos escritos, independientemente de qué réplica atienda la consulta.
La API de sesiones funciona creando una sesión con env.DB.withSession(). Dentro de la devolución de llamada, todas las consultas comparten el contexto de la sesión y D1 garantiza que las lecturas posteriores a la escritura devuelvan datos actualizados. Para los flujos que combinan escritura y lectura inmediata (creación de cuentas, actualizaciones de configuración, finalización de pedidos), el uso de Sessions API es el camino directo para evitar inconsistencias visibles para el usuario.
Para flujos puramente de solo lectura, como listas y paneles, la coherencia final no es un problema: los datos pueden retrasarse unos segundos sin ningún impacto perceptible.
Precio real: cuando el nivel gratuito ya no es suficiente
El nivel gratuito de D1 ofrece 5 GB de almacenamiento, 5 millones de líneas leídas por día y 100 mil líneas escritas por día. Estos números suenan generosos en abstracto, pero el costo de lectura de D1 no se basa en las filas devueltas, sino en las filas examinadas por el motor de la base de datos.
Una consulta que escanea 100 mil filas para devolver 5 mil consume 100 mil lecturas, no 5 mil. Una aplicación con mil usuarios activos que realizan consultas de listados sin índices adecuados puede agotar 5 millones de lecturas diarias en unas pocas horas. El nivel gratuito es suficiente para desarrollo, herramientas internas de bajo volumen y creación de prototipos, no para aplicaciones con tráfico de usuarios real.
Cuando el nivel gratuito no es suficiente, el siguiente paso requiere el plan Workers Paid ($5/mes para la plataforma) más los costos variables de D1: $0,001 por millón de líneas leídas, $1 por millón de líneas escritas y $0,75 por GB-mes de almacenamiento. El costo de escritura tiene una aritmética simple: un flujo de registro que inserta 10 líneas por usuario equivale a $10 en costos de escritura por cada millón de usuarios registrados. Para las aplicaciones de rápido crecimiento, este número aparece antes de lo esperado.
El coste de las lecturas depende casi por completo de la calidad de los índices. Con índices adecuados, una consulta que devuelve 20 filas lee 20 filas. Sin índices, la misma consulta puede leer 500 mil líneas y costar 500 veces más.
Cómo planificar la región primaria antes de crear el banco
La región primaria D1 es una decisión irreversible en la creación del banco. No hay ninguna opción para mover la base de datos principal más tarde; la alternativa es exportar los datos, crear una nueva base de datos en la región deseada e importarla. Esto hace que la elección de la región sea una de las pocas decisiones de infraestructura que requiere una consideración cuidadosa antes de escribir la primera línea de código.
La regla general: la región primaria debe ser donde se origina la mayor parte de la escritura. Para un producto brasileño con usuarios brasileños, Worker probablemente se ejecute en São Paulo PoP (GRU) o similar. Cloudflare ofrece southamerica-east1 como opción de región principal D1: elegir esta región para un producto brasileño reduce la latencia de escritura de 80-150 ms a 5-20 ms.
Para comprobar qué región tiene más sentido, mida la latencia de la red del trabajador para la región candidata usando un simple fetch con marca de tiempo antes y después. El costo de una elección incorrecta de la región principal no aparece en el desarrollo; aparece cuando la aplicación está en producción y cada escritura agrega 100 ms de latencia notable para el usuario.
El límite de 2 GB por banco y 10 bancos en el plan pago también está incluido en la planificación inicial. Si la aplicación tiende a crecer más allá de los 2 GB, se debe pensar en la partición de datos entre múltiples bancos D1 antes de que lleguen los primeros datos; refactorizar esta partición más tarde, con los datos en producción, implica mucho más trabajo.
Lea también
- Cloudflare KV: Qué significa distribución global cuando necesitas escribir
- D1 en producción: rendimiento, límites y lo que no escala solo
- Migraciones en D1: cómo versionar el esquema y qué sucede cuando sale mal
- Objetos duraderos de Cloudflare: estado consistente en el borde: lo que realmente cambia
- Trabajadores de Cloudflare en producción: qué cambia después de hello world
- Cloudflare Workers vs Pages: la diferencia que importa antes de elegir