D1 o Hyperdrive: el criterio de elección

Todo el nivel converge en una decisión que tarde o temprano hay que tomar delante de un proyecto real, y que se plantea mal casi siempre. La pregunta ingenua es cuál de las dos es mejor, y no tiene respuesta porque no compiten en el mismo eje: D1 es una base de datos y Hyperdrive es una capa de aceleración sobre la base que ya tienes. La pregunta madura, la que sí se responde en dos minutos y casi nunca deja dudas, no mira a las herramientas sino a tu punto de partida: ¿tienes ya una base relacional en la que confías, o estás empezando de cero?

Dos respuestas a la misma pregunta

La pregunta que ambas responden es idéntica: cómo hago que mis datos relacionales estén cerca de un compute que se ejecuta en trescientas ubicaciones. Es la pregunta que gobierna toda la arquitectura en el edge, porque de nada sirve ejecutar el código a veinte milisegundos del usuario si cada petición tiene que peregrinar ciento cincuenta milisegundos hasta una fila. Las respuestas son opuestas en filosofía.

Antes de entrar en cada una, conviene fijar el marco: no estamos comparando dos motores por su rendimiento, sino dos estrategias por su encaje. El rendimiento de ambas, bien aplicadas, es excelente; lo que las distingue es a qué situación responden y qué te piden a cambio. Por eso ninguna comparativa de cifras resuelve esta decisión, y sí lo hace una descripción honesta de tu punto de partida.

D1 responde moviendo los datos. Es una base nueva, SQLite gestionada y sin servidor, nativa de la plataforma, con réplicas de lectura que la plataforma coloca cerca de tus usuarios. No hay instancia que aprovisionar, ni cadena de conexión, ni pool que agotar, porque su conectividad desde un Worker es inmediata por diseño: no existe el saludo de siete viajes que castiga a una base tradicional. De hecho, Hyperdrive no admite D1 como origen precisamente por eso —no habría nada que acelerar—.

Hyperdrive responde acercando el camino. Tus datos no se mueven ni un metro: siguen en tu Postgres de Neon, tu MySQL gestionado o la instancia que administras. Lo que cambia es que el trayecto desde el edge deja de ser prohibitivo, gracias al pool de conexiones junto al origen y a la caché de lecturas en el borde.

Esa diferencia de filosofía explica también por qué la comparación se plantea mal tan a menudo. Ponerlas una al lado de la otra en una tabla de características sugiere que son alternativas intercambiables, cuando en realidad responden a preguntas distintas del proyecto: D1 responde a dónde van a vivir mis datos, y Hyperdrive responde a cómo llego a los datos que ya viven en algún sitio. Solo cuando la primera pregunta sigue abierta —es decir, cuando empiezas de cero— compiten de verdad por el mismo hueco.

El criterio: de dónde vienes

En la práctica, la decisión se resuelve con una sola pregunta y tres señales de apoyo. La pregunta es si ya tienes una base relacional en producción. Si la respuesta es sí, la recomendación por defecto es Hyperdrive, y hace falta un motivo fuerte para no seguirla: migrar un esquema vivo, con sus migraciones, sus índices afinados y años de consultas escritas, es un proyecto en sí mismo cuyo riesgo rara vez compensa la ganancia.

Que sea una recomendación por defecto y no una regla absoluta importa. Significa que la carga de la prueba recae en quien propone migrar, no en quien propone conservar, y que ese alguien debe poder nombrar la ganancia concreta que justifica el riesgo. A veces existe —una base modesta, un esquema simple, un origen que cuesta más de lo que aporta— y entonces migrar a D1 es una decisión excelente. Lo que no vale como argumento es la incomodidad estética de tener un servidor de base de datos en un mundo sin servidores.

Las tres señales que refuerzan Hyperdrive incluso en proyectos nuevos son igual de nítidas. La primera es el volumen: si hablas de bases del orden de un terabyte o más, D1 no es el molde, porque su techo por base es de diez gigabytes y su modelo pide muchas bases pequeñas en vez de una grande. La segunda son las dependencias del motor: extensiones como las de geoespacial o vectores, tipos propios, funciones almacenadas, un dialecto de Postgres que tu código da por hecho. La tercera es el utillaje: tu ORM, tus migraciones, tu cliente gráfico, tus paneles de observación, y el conocimiento acumulado de un equipo que sabe operar Postgres.

Hay una cuarta señal menos citada y que en la práctica decide muchos casos: el perfil de escritura. D1 procesa las consultas de una en una sobre su primaria, así que su caudal de escritura es el inverso de la duración media de cada sentencia; la replicación de lectura reparte las lecturas, pero toda escritura sigue embudada. Si tu carga escribe de forma constante y masiva —telemetría, eventos, un libro mayor con miles de asientos por segundo—, ese embudo es tu techo desde el primer día, y un motor con escritura concurrente real es lo que tu problema estaba pidiendo aunque empieces de cero.

flowchart TD
Q{ya tienes una base relacional en produccion}
Q -->|si| H[Hyperdrive la acelera desde el edge]
Q -->|no| N{como es la carga}
N -->|lectura intensiva y global| D[D1 base serverless nativa]
N -->|base enorme o extensiones o escritura masiva| H
style D fill:#a6e3a1,color:#11111b
style H fill:#89b4fa,color:#11111b

El camino de D1 se abre cuando empiezas de cero y tu carga tiene la forma que le sienta bien: muchas más lecturas que escrituras, usuarios repartidos por el mundo, y un modelo de datos que admite partirse por entidad —una base por inquilino, por usuario, por proyecto—. Ahí D1 no solo es viable: es superior, porque elimina el origen entero de la ecuación y con él toda la operación que arrastra.

Conviene desactivar de paso el argumento que más veces empuja a migrar sin motivo: la idea de que mantener Postgres es quedarse en el pasado y que adoptar la base nativa es modernizarse. Un esquema afinado durante años no es deuda técnica, es conocimiento cristalizado sobre tu dominio —qué se consulta junto, qué se indexa, qué invariantes hay que sostener— y ese conocimiento no viaja con los datos cuando exportas tablas. Migrar tiene un coste que casi nunca se estima bien porque la parte cara no es mover filas sino reconstruir la confianza: volver a validar cada consulta, cada índice, cada caso raro que alguien resolvió hace tres años y nadie documentó.

Y hay una asimetría de riesgo que remata el razonamiento. Adoptar Hyperdrive sobre una base existente es reversible en minutos: si no te convence, apuntas el driver a la cadena de conexión original y todo sigue igual, porque nunca movió un byte. Migrar a otro motor no es reversible en el mismo sentido, porque una vez que las escrituras van al destino nuevo, volver atrás es otra migración con sus propios riesgos. Ante dos opciones defendibles, la que se deshace barata merece el beneficio de la duda.

Una tabla así ayuda a ordenar, pero engaña si se lee como un marcador: no gana quien acumule más casillas favorables, porque las filas no pesan lo mismo en tu caso concreto. Para un equipo que depende de una extensión geoespacial, una sola fila decide la partida y las demás son decoración. La utilidad de la tabla no es sumar, es localizar cuál de esas dimensiones es innegociable en tu proyecto; en cuanto la identificas, la decisión ya está tomada.

Lo que cada una te cobra

Comparar precios de listado lleva a conclusiones equivocadas, porque los dos caminos cobran cosas distintas y uno de ellos cobra fuera de la factura de Cloudflare. Antes de mirar ninguna cifra conviene fijar qué se está comparando: en un caso, el precio total de tener datos relacionales; en el otro, solo el precio de llegar hasta ellos más rápido.

D1 factura por filas leídas y escritas más el almacenamiento. Esa unidad tiene una virtud pedagógica notable: alinea el coste con el buen modelado, porque un índice que evita un escaneo completo no solo acelera la consulta, también la abarata. Y elimina por completo el gasto de tener una máquina encendida esperando tráfico. Pensar en cuántas filas toca cada consulta deja de ser una cuestión de rendimiento y se convierte también en una de presupuesto, lo que tiende a producir esquemas mejores por pura presión económica.

Esa forma de facturar tiene también su cara incómoda, y merece decirse: una consulta mal indexada que recorre un millón de filas para devolver diez no solo va despacio, sino que se lleva un millón de filas facturadas cada vez que se ejecuta. En un motor tradicional ese despilfarro se disuelve en el coste fijo de la instancia y puede pasar desapercibido durante años; aquí aparece en la factura del mes siguiente. Es una retroalimentación honesta, aunque poco piadosa con quien no mide.

Hyperdrive, por su parte, no cobra transferencia de salida, no cobra cómputo adicional y está disponible incluso en el plan gratuito de Workers. Es tentador leer eso como que sale gratis, y ahí está el error: tu base de datos sigue existiendo y sigue costando. Pagas la instancia, su almacenamiento, sus copias, su alta disponibilidad y el tiempo del equipo que la mantiene, la parchea y la vigila. Hyperdrive es barato porque la parte cara de esta arquitectura no es él.

Esa asimetría es la que hace que la comparación honesta no sea entre dos líneas de una factura sino entre dos modelos operativos completos. Con D1 no hay nadie de guardia por una instancia de base de datos, porque no hay instancia. Con Hyperdrive sí lo hay, y a cambio conservas un control, una madurez y un ecosistema que ninguna base joven puede igualar todavía.

Conviene además contar el coste que no aparece en ninguna factura: el tiempo y la atención del equipo. Una instancia de base de datos exige actualizaciones de versión, gestión de copias y pruebas de restauración, vigilancia de espacio y de conexiones, planificación de capacidad y alguien localizable cuando algo se rompe de madrugada. Nada de eso es difícil por separado; todo junto es un trabajo continuo que rara vez se contabiliza al comparar precios de listado, y que en equipos pequeños suele ser el factor decisivo, muy por delante de cualquier diferencia en la tarifa.

Hay además una diferencia de forma en la curva de coste que importa más que el precio absoluto. Un origen tradicional cobra por capacidad reservada: pagas la instancia esté saturada o vacía, y el gasto sube a saltos cuando toca cambiar de tamaño. Una base serverless cobra por uso: el gasto sigue al tráfico de forma continua y tiende a cero cuando no hay nadie. Para una carga estable y alta, la capacidad reservada suele salir a cuenta; para una carga irregular, estacional o todavía sin validar, pagar solo por lo que ocurre cambia por completo la viabilidad de un proyecto en sus primeros meses.

Conviven mejor de lo que parece

Plantear la elección como excluyente para todo el proyecto es el último error que conviene desactivar. La pregunta correcta no se hace una vez, para toda la aplicación y para siempre, sino una vez por cada conjunto de datos, y nada obliga a que todas las respuestas coincidan. Un mismo Worker puede declarar los dos bindings, y hay arquitecturas donde eso es lo más sensato.

{
  "d1_databases": [{ "binding": "DB", "database_id": "id-de-tu-d1" }],
  "hyperdrive": [{ "binding": "HYPERDRIVE", "id": "id-de-tu-config" }]
}

Desde el punto de vista del código, esa coexistencia no añade ninguna ceremonia: son dos propiedades más en env, cada una con su API, y el manejador elige la que corresponde según el dato que va a tocar. La complejidad, si aparece, no está en la plataforma sino en el dominio, y es la de siempre cuando la verdad vive en dos sitios.

Ese reparto tiene además una virtud organizativa que se aprecia con el tiempo: permite que el sistema heredado envejezca en paz mientras lo nuevo nace ya con la forma correcta. No hay que congelar la evolución del producto esperando a una migración que quizá nunca llegue, ni hay que arrastrar el modelo antiguo a cada funcionalidad futura solo porque toda la verdad vivía en un mismo sitio.

El reparto natural sigue la forma de cada dato. La masa relacional central y voluminosa —el sistema heredado, la contabilidad, el catálogo maestro— se queda en Postgres y se consume por Hyperdrive. Los datos que nacen con la aplicación nueva y se dejan partir por entidad —preferencias por usuario, estado por inquilino, registros de una funcionalidad reciente— viven en D1, cerca de quien los lee y sin origen que operar. Y por debajo siguen KV para la lectura global barata, R2 para los ficheros y Durable Objects para la coordinación con estado.

Visto así, la pregunta de este nivel deja de ser una disyuntiva entre dos productos y se revela como un caso particular de la disciplina que atraviesa todo el bloque de almacenamiento: cada pieza vende una combinación distinta de garantías —consistencia, capacidad de consulta, alcance geográfico, coste operativo— y elegir bien consiste en leer la forma de cada dato y colocarlo donde esas garantías coinciden con lo que de verdad necesita. Que un mismo proyecto use cuatro almacenes no es dispersión: es precisión.

Esa convivencia también describe el camino más frecuente de una migración prudente: primero se acelera lo existente con Hyperdrive, sin tocar nada y sin riesgo; después, si aparece un dominio nuevo con la forma adecuada, se construye directamente en D1 en lugar de engordar el monolito relacional. Nadie tiene que decidir hoy el destino final de todos sus datos.

El coste de esa convivencia no es cero y conviene nombrarlo para no idealizarla: dos almacenes significan dos modelos de consistencia, dos juegos de migraciones y la imposibilidad de resolver con un JOIN una relación que cruce la frontera. Por eso el reparto solo funciona si la frontera coincide con una costura real del dominio, donde las consultas casi nunca necesitan cruzar. Cuando esa costura no existe y se inventa por conveniencia de infraestructura, acabas cosiendo en el Worker lo que un motor relacional resolvía solo, y habrás pagado la complejidad de dos sistemas sin la ventaja de ninguno.