Cloudflare D1 + Drizzle ORM en Next.js: guía práctica
Cómo monté una base de datos SQLite en el edge con Cloudflare D1 y Drizzle ORM para un panel de gestión en Next.js, con migraciones y binding tipado incluidos.
- #cloudflare
- #d1
- #drizzle
- #next.js
- #base-de-datos
Cuando construí un panel de gestión a medida para un cliente, necesitaba una base de datos relacional que viviera en el mismo sitio que el resto de la infraestructura: Cloudflare. Ahí entra D1, la base de datos SQLite gestionada de Cloudflare, y Drizzle ORM como capa de acceso tipada. La combinación es sorprendentemente sólida para proyectos de tamaño freelance.
Por qué D1 y no Postgres gestionado
D1 vive en el edge, junto al Worker que sirve tu Next.js. Cero latencia de red entre tu función y tu base de datos porque ambos corren en la misma infraestructura de Cloudflare. Para un panel interno de un solo usuario o una app de tamaño medio, esa cercanía pesa más que las features avanzadas de un Postgres gestionado que ni vas a usar.
Drizzle: el ORM que no se interpone
Drizzle genera SQL casi literal a partir de TypeScript. Defines el schema como objetos tipados, generas migraciones con drizzle-kit, y las aplicas con Wrangler tanto en local (SQLite simulado) como en producción. La ventaja frente a un ORM más pesado: el tipado de las queries es exacto, sin capas de abstracción que oculten lo que realmente se ejecuta contra la base de datos.
El flujo que uso
npm run db:generategenera las migraciones a partir del schema.npm run db:migrate:locallas aplica contra la D1 local (Wrangler simula SQLite en.wrangler/state).npm run cf:typesgenera los tipos del bindingDBa partir dewrangler.jsonc, para que TypeScript conozca el binding real de Cloudflare en desarrollo y producción.
El detalle que marca la diferencia: initOpenNextCloudflareForDev() en next.config.ts expone ese binding dentro de next dev, así que desarrollas contra la misma D1 local que usa Wrangler sin tener que levantar wrangler dev para el día a día.
Conclusión
D1 + Drizzle no sustituye a Postgres en todos los casos, pero para paneles internos, aplicaciones de un solo tenant o proyectos que ya viven en Cloudflare Workers, es la opción con menos piezas móviles y mejor rendimiento real por cercanía de infraestructura.
¿Construyendo algo?
Si esto te ha resonado, podemos hablar. Contactar →