Cloudflare D1 escala a 5,5 millones de bases de datos

Cloudflare D1 ya sostiene 5,5 millones de bases de datos

Cloudflare D1 superó los 5,5 millones de bases de datos creadas y multiplicó por 15 el número de bases vivas (no eliminadas) en el último año, según datos al 8 de octubre de 2026 publicados por la compañía. Para un founder que construye un producto multi-tenant, la cifra importa por una razón concreta: valida un modelo de datos que hasta hace poco se consideraba inviable, el de una base por usuario, por cliente o por entorno de preview, sin que el costo operativo se dispare.

D1 es la base de datos serverless gestionada de Cloudflare, construida sobre SQLite. Su promesa es simple: crear millones de bases y pagar solo por lo que se usa. El problema, y de eso trata el post técnico que la compañía publicó, es cómo escalar el plano de control para millones de bases sin que cada consulta termine pasando por un cuello de botella central.

Por qué el modelo de una base por cliente dejó de ser una locura

La arquitectura tradicional asume uno o dos clústeres grandes por aplicación, más una capa de connection pooling. El desarrollo asistido por IA y las plataformas de vibe coding rompieron esa premisa: cada usuario, cada aplicación generada, cada entorno de preview y cada tenant pide su propia base.

Cloudflare reporta 65x de crecimiento en bases vivas en dos años y 18x en bases activas diarias en un año. Una base cuenta como activa si ejecutó al menos una consulta durante ese día. El respaldo de plataformas grandes ya existe: Jon Abrams, de ChatGPT Sites en OpenAI, señala en el mismo post que D1 les da a sus usuarios una forma simple y escalable de agregar funciones como métricas personalizadas, tablas de clasificación y comentarios a sus dashboards, juegos y herramientas.

Traducción para tu startup: si tu producto genera un espacio de datos por cliente, ya no necesitas convencer a nadie de que el modelo escala. Lo que sí necesitas es entender el costo arquitectónico de sostenerlo.

Cómo se separa el plano de control del camino caliente

La decisión central de D1 es dividir las operaciones en tres categorías:

• Plano de datos: toda consulta a la base. Debe ser lo más rápida posible y resolverse siempre en el edge.
• Plano de control: operaciones de API que no son consultas (crear, borrar, listar bases, importar, exportar). Puede depender de componentes centrales en una sola región.
• Plano asíncrono de fondo: analítica y facturación. Tolera consistencia eventual y puede correr en cualquier lugar.

Cada base de D1 está respaldada por un Durable Object de SQLite, lo que hace barato crear millones de ellas. Las consultas pasan por el Edge API Worker y luego por el Eyeball Worker, que las reenvía al Durable Object. El detalle clave: en ese camino no hay Postgres.

El mapeo de identificadores vive en Workers KV, un almacén distribuido globalmente. Cloudflare aclara una distinción que suele confundirse: Workers KV no es solo caché, es un datastore durable. Si un ítem sale de la caché del edge, la lectura se sirve desde el almacenamiento propio de KV y no desde Postgres. En un escenario de purga catastrófica de caché, un millón de bases pidiendo su información de ruteo a la vez generaría fallas en cascada.

Solo cuando el ítem no aparece en KV se cae a Hyperdrive contra las réplicas de Postgres, y recién si Hyperdrive falla en sus dos capas de caché se consulta la base real.

¿Cómo se crea una base de datos sin bloquear el sistema?

El flujo de creación es un buen ejemplo de diseño para fallos. Cuando pides una base nueva, el sistema verifica los límites de la cuenta, genera un UUID de base y un ID único de Durable Object, inicializa el objeto, persiste la metadata en Postgres y escribe el mapeo en Workers KV.

Los pasos críticos van dentro de un loop de reintentos. Si la inicialización del Durable Object o la escritura en Postgres falla, se reintenta con IDs distintos. La razón es concreta: reutilizar el mismo UUID con un Durable Object nuevo dejaría a dos objetos creyendo que son dueños de la misma base.

La escritura en Postgres es el punto de no retorno: desde ahí la base existe, aunque la respuesta no llegue al usuario. Y cada Durable Object envía un heartbeat cada 30 segundos, con jitter por base, para sincronizar su estado. Ese heartbeat es el mecanismo de autocorrección: si un objeto quedó huérfano por un reintento fallido, en menos de medio minuto recibe la respuesta de que su base no existe y se marca como eliminado.

Cloudflare explica por qué no resolvieron todo con una transacción de Postgres: no escala, porque mantendría conexiones abiertas mientras se inicializa un Durable Object que puede estar al otro lado del mundo.

¿Cómo se aplican los límites de uso sin tumbar la base central?

D1 tiene un límite de 5 GB de almacenamiento por cuenta en el plan Free y 1 TB en Workers Paid, ampliable a pedido. Aplicar ese límite con una suma de almacenamiento por cuenta no escala: el costo de esa consulta crece linealmente con la cantidad de bases.

La solución es una tabla precalculada que se mantiene al día con deltas. Los Durable Objects publican actualizaciones de uso en una cola tipo Kafka; un trigger calcula la diferencia y la deja en una tabla de cambios; un job programado corre cada segundo y consolida los deltas por cuenta. Así se evita la contención de escritura sobre una sola fila en cuentas con millones de bases.

Un detalle fino de diseño de caché: la consulta usa solo el ID de cuenta como parámetro, no el ID de base. Eso hace que todas las bases de una cuenta compartan el mismo valor cacheado en Hyperdrive. Incluir el ID de base daría una respuesta más exacta, pero destruiría la tasa de aciertos de caché.

Para los límites diarios de filas leídas y escritas del plan gratuito, el patrón es distinto: los eventos van a ClickHouse, un componente central consulta la analítica, y el resultado se propaga a Quicksilver, el almacén distribuido interno de Cloudflare, para que cada Durable Object lo verifique en el edge.

Qué significa esto para tu startup

Tres cosas concretas que puedes llevarte.

Primero, revisa dónde está tu camino caliente. Si tu producto hace una consulta a una base central en cada request de usuario, tienes el mismo problema que D1 resolvió. El patrón es replicable: metadata de ruteo en un almacén distribuido, caché delante de la base transaccional, y la base central solo como respaldo ante un fallo de caché.

Segundo, separa facturación y límites del flujo de usuario. Los sistemas de cobro y de enforcement de cuotas son candidatos naturales a consistencia eventual. Usa una cola para amortiguar picos, precalcula agregados en lugar de hacer sumas sobre tablas grandes, y elige la herramienta correcta: Postgres para metadata transaccional, un motor analítico para las consultas de uso.

Tercero, si construyes multi-tenant, evalúa el modelo de base por tenant. D1 lo hace viable a escala de millones, pero con un tradeoff explícito: la consistencia eventual en los límites significa que una cuenta puede pasarse del tope por unos segundos antes de que se aplique el bloqueo. Si tu producto necesita enforcement exacto al instante, ese diseño no te sirve tal cual.

El contexto: la carrera por SQLite en el edge

D1 no compite en el vacío. Geeky Gadgets reporta que Turso reescribió SQLite en Rust con control de concurrencia multiversión (MVCC) y logró una mejora de 4x en escritura, con casi 200.000 escrituras por segundo en escenarios específicos. El mismo medio aclara que ese rewrite sigue siendo experimental y no está listo para producción.

También conviene dimensionar la plataforma sobre la que corre D1. Según TechTimes, el free tier de Cloudflare Workers ofrece 10 milisegundos de CPU por request y 100.000 requests diarios, mientras que el plan pago permite hasta 30 segundos de ejecución por request HTTP.

Conclusión

El post de Cloudflare es, en el fondo, un manual de arquitectura disfrazado de anuncio. La cifra de 5,5 millones de bases es el titular, pero el valor real está en los principios: sacar los componentes centrales del camino caliente, usar consistencia eventual donde el negocio la tolere y elegir el almacén correcto para cada trabajo. Para un founder hispanohablante que construye productos multi-tenant o plataformas de generación con IA, esos principios aplican igual si usas D1, otra base serverless o tu propio stack.

Fuentes

• Cloudflare blog (fuente original)
• Geeky Gadgets
• TechTimes