Cloudflare ha publicado cómo escala el plano de control de D1 para soportar millones de bases de datos. El motivo es un cambio de patrón: según el post (13 de octubre de 2026), las plataformas de desarrollo asistido por IA crean muchas bases pequeñas, una por usuario, aplicación o entorno de preview, en lugar de uno o dos clústeres grandes. A 8 de octubre, las bases vivas habían crecido 15 veces en un año y 65 en dos.
Qué cambia
Cada base de datos D1 está respaldada por un Durable Object con SQLite. Cloudflare separa las operaciones en tres planos:
- Plano de datos: las consultas. Tienen que ser rápidas y resolverse siempre en el edge.
- Plano de control: la API HTTP y los flujos internos. Puede depender de componentes centrales en una sola región.
- Plano asíncrono: analítica y facturación, eventualmente consistente.
El ID de cada base y su metadato se guardan en Postgres (el "creation checkpoint") y el mapeo se replica en Workers KV, que se usa como almacén duradero y no solo como caché. En la ruta caliente, el Edge API Worker busca el mapeo en KV, solo en un fallo cae a réplicas de Postgres vía Hyperdrive y reenvía la consulta al Durable Object a través de un Eyeball Worker. Con bindings de Worker, ni siquiera hace falta la búsqueda.
Algunos detalles que me parecen valiosos:
- La creación se envuelve en un bucle de reintentos y cada intento usa un ID nuevo, para que dos Durable Objects nunca reclamen la misma base.
- Cada Durable Object envía un heartbeat al plano de control cada 30 segundos más un jitter por base. Sirve para reconciliar: los huérfanos se marcan como borrados y KV se corrige con el tiempo.
- Los límites de almacenamiento (5 GB por cuenta en el plan gratuito, 1 TB en Workers Paid) no se calculan con un escaneo: los deltas se guardan en una tabla y un job que corre cada segundo los agrega, para evitar contención de bloqueos en cuentas grandes.
- Los límites de filas del plan gratuito se calculan con eventos de uso en ClickHouse; al superarse, se pone una clave en Quicksilver con expiración a fin de día y los Durable Objects rechazan consultas en el edge.
Por qué importa en producción
Aunque no uses D1, el post es una lista de decisiones de arquitectura multi-tenant que cualquier SRE se encuentra tarde o temprano:
- Reintentos idempotentes: reintentar con identificadores nuevos evita estados duplicados.
- KV como almacén duradero: si fuera solo caché, una purga completa con un millón de bases podría provocar un fallo metaestable.
- Claves de caché: incluir el ID de base en la clave de Hyperdrive hundiría la tasa de aciertos; con claves por cuenta, casi todos los heartbeats aciertan.
- Transacciones cortas: no mantener una transacción de Postgres abierta mientras se inicializa un Durable Object, porque la conexión quedaría abierta a través de continentes.
- Agregación incremental en lugar de escaneos durante la petición.
Qué haría yo
- Revisar en mis propios servicios multi-tenant qué está en la ruta caliente y depende de una sola región; sacarlo o cachearlo con claves de grano grueso.
- Comprobar si mis cachés son realmente prescindibles: ¿qué pasa si las vacío de golpe?
- Diseñar los flujos de creación como idempotentes, con reconciliación periódica en lugar de confiar en que todo termine bien.
- Hacer pruebas de carga con un volumen superior al crecimiento esperado, como recomienda Cloudflare.
Fuentes
- Cloudflare, "Under the hood, off the hot path: How D1 scales to millions of databases" (13/10/2026): https://blog.cloudflare.com/d1-control-plane/