Qué es Hyperdrive: acelerar tu base existente

Hyperdrive es, probablemente, la pieza peor entendida de la plataforma, y la culpa la tiene su nombre. Suena a base de datos nueva, a un motor exótico que hay que aprender y al que hay que migrar. No lo es. Hyperdrive no guarda ni un solo byte de tus datos: es un acelerador que toma tu Postgres o MySQL ya existente —esté en AWS, Neon, Supabase o tu propio servidor— y lo pone al alcance de un Worker con la latencia de una base cercana, sin migrar nada ni cambiar de motor. Interiorizar que es una capa, y no un almacén, es la primera y más importante idea de este nivel.

No es una base, es una capa

La confusión nace de meterlo en la misma frase que D1, R2 o KV, que sí son almacenes: guardan datos que antes no existían en ningún sitio. Hyperdrive no guarda nada. Tus datos siguen viviendo donde ya vivían —en tu Postgres de Neon, en tu MySQL de PlanetScale, en la instancia de RDS que administras— y Hyperdrive se sitúa en el camino entre tu Worker y esa base como una capa de conexión y caché. Si mañana lo apagas, tus datos siguen intactos en el origen; lo que pierdes es la aceleración, no la información.

Esa distinción no es un tecnicismo, es la clave de cuándo elegirlo. Hyperdrive es la respuesta a una situación concretísima: ya tienes una base relacional, con su esquema, sus migraciones, sus índices y años de consultas escritas, y ahora quieres consumirla desde Workers sin que la latencia lo arruine. No te pide reescribir a un dialecto nuevo ni exportar tus tablas: te deja tu base tal cual y cambia únicamente el camino por el que el Worker llega a ella.

// tu codigo sigue hablando Postgres normal; Hyperdrive solo cambia el camino
import postgres from "postgres";

export default {
  async fetch(request, env, ctx): Promise<Response> {
    // env.HYPERDRIVE.connectionString apunta al acelerador, no al origen directo
    const sql = postgres(env.HYPERDRIVE.connectionString);
    const filas = await sql`SELECT id, titulo FROM articulos LIMIT 10`;
    return Response.json(filas);
  },
} satisfies ExportedHandler<Env>;

Fíjate en lo que no hay en ese código: ni un SQL distinto, ni un cliente propietario, ni una API inventada. Es el driver postgres de siempre, la misma consulta que escribirías contra tu base directa. Lo único que apunta a Cloudflare es la cadena de conexión. Ese es el corazón del producto: la aceleración es invisible para tu código.

El problema que resuelve: la distancia

Para entender por qué hace falta un acelerador, hay que ver qué se rompe sin él. Un Worker se ejecuta en cientos de ubicaciones a milisegundos del usuario, pero tu Postgres vive en una sola región. Cuando ese Worker abre una conexión a la base, paga dos peajes crueles que en un backend regional clásico casi no se notaban.

El primero es el saludo. Abrir una conexión nueva a Postgres no es gratis: exige un ida y vuelta de TCP, otro par para negociar TLS y varios mensajes más de autenticación y arranque. Son cerca de siete viajes de red antes de poder lanzar la primera consulta. Desde un servidor pegado a la base eso es despreciable; desde el edge, con el origen a 150 milisegundos, cada saludo cuesta más que la consulta misma.

El segundo es el modelo efímero. Un backend tradicional abre un puñado de conexiones al arrancar y las reutiliza durante horas. Un Worker es efímero y masivamente paralelo: no hay un proceso longevo donde guardar un pool, y cientos de isolates independientes intentando conectar a la vez desbordan el límite de conexiones de la base —una tormenta de conexiones que la tumba.

flowchart LR
subgraph edge [Edge global]
  W1[Worker Tokio]
  W2[Worker Madrid]
end
W1 --> HD[Hyperdrive: pool y cache]
W2 --> HD
HD --> PG[Postgres en una region]
style HD fill:#89b4fa,color:#11111b
style PG fill:#fab387,color:#11111b

Hyperdrive se interpone justo ahí. Mantiene un pool de conexiones ya calientes cerca de tu base, de modo que tu Worker no vuelve a pagar el saludo de siete viajes: se conecta a un punto cercano de Hyperdrive, no al origen lejano. Y añade una caché de consultas que sirve las lecturas más populares sin llegar siquiera a la base. Dos palancas, un mismo objetivo: que una base regional se comporte, desde el edge, como si estuviera al lado.

Para quién es y qué no cambia

Hyperdrive brilla cuando ya tienes Postgres o MySQL y no quieres abandonarlo: una base que supera lo que D1 abarca, un esquema con extensiones y tipos de los que dependes, un equipo con años de SQL escrito, o simplemente el deseo de seguir usando tus herramientas —tu ORM, tus migraciones, tu cliente favorito— desde el edge. Habla con cualquier Postgres o MySQL, y también con las bases compatibles con el protocolo de Postgres, como CockroachDB o Timescale.

Lo que no cambia es casi todo tu stack de datos, y esa es su mayor virtud. Tu esquema es el mismo. Tus migraciones se ejecutan igual, contra el origen. Tu ORM —Drizzle, Prisma, Kysely— sigue funcionando porque por debajo usa los mismos drivers postgres o node-postgres que Hyperdrive soporta. No aprendes una API nueva ni reescribes consultas: enchufas la cadena de conexión que Hyperdrive te da y todo lo demás sigue en su sitio.