D1 Database: SQLite en el Edge de Cloudflare
Hace un año, la mayoría de desarrolladores españoles que conozco seguían el mismo patrón: Vercel para el frontend, una base de datos centralizada (típicamente PostgreSQL en algún servidor en Europa), y rezar para que la latencia no fuera un problema.
Luego llegó Cloudflare D1.
El Problema Que Nadie Quería Admitir
La arquitectura tradicional tiene un defecto silencioso: la centralización mata la velocidad. Cada consulta a tu base de datos viaja desde el edge (donde está tu usuario) hasta un servidor central. En España, si tu base de datos está en Madrid y tu usuario en Barcelona, es rápido. Pero ¿si está en São Paulo?
Los desarrolladores lo saben. Los empresarios no lo entienden. Y los clientes simplemente ven que la aplicación es lenta.
Cloudflare D1 resuelve esto de una forma que parecía imposible hace poco: SQLite distribuido en el edge.
Qué Es Realmente D1
D1 es SQLite ejecutándose en los servidores edge de Cloudflare. No es una base de datos NoSQL. No es una abstracción rara. Es SQLite, el mismo motor que usan millones de aplicaciones móviles.
La magia está en que:
- **Tier gratuito generoso**: Tienes acceso a una base de datos SQLite sin pagar nada inicialmente
- **Réplicas de lectura sin costo**: Puedes replicar tus datos en múltiples regiones del edge sin pagar extra
- **Latencia mínima**: Tu código ejecuta queries a milisegundos de distancia del usuario
Por Qué Cambié Mi Forma de Pensar
Hace seis meses, estaba construyendo una SaaS con patrones tradicionales: una base de datos PostgreSQL centralizada, Supabase como intermediario, y Vercel en el frontend.
Funcionaba. Pero cada vez que escalaba a nuevos mercados, la latencia aumentaba.
Luego probé D1 con un experimento pequeño: migré una tabla de usuarios a SQLite en el edge.
El resultado fue tan obvio que me sorprendió no haberlo visto antes: las queries pasaron de 200-300ms a 10-50ms.
No es magia. Es física. La distancia es el enemigo de la velocidad.
El Patrón Per-Tenant Que Finalmente Tiene Sentido
Ahora aquí es donde D1 se vuelve interesante para aplicaciones reales.
En una arquitectura multi-tenant tradicional, todos tus clientes comparten la misma base de datos. Es eficiente en recursos, pero tiene problemas:
- Un cliente lento puede afectar a todos los demás
- Los datos están centralizados, vulnerables a problemas de privacidad
- La escalabilidad es un cuello de botella
Con D1, puedes hacer algo diferente: un SQLite por tenant.
Sí, suena loco. Pero mira el código:
```javascript // Cloudflare Worker export default { async fetch(request, env, context) { const { tenantId } = request.params;
// Cada tenant tiene su propia base de datos D1 const db = env.D1_DATABASES[`tenant_${tenantId}`];
const result = await db .prepare('SELECT * FROM users WHERE active = ?') .bind(true) .all();
return Response.json(result.results); } }; ```
Cada tenant obtiene:
- **Aislamiento de datos**: Sus datos no se mezclan con otros
- **Rendimiento predecible**: No hay competencia por recursos
- **Escalabilidad simple**: Añadir un nuevo tenant es crear un nuevo SQLite
- **Cumplimiento normativo**: Más fácil cumplir RGPD cuando los datos están separados
En España, donde el RGPD es ley, esto es especialmente relevante. Tus clientes pueden exigir que sus datos estén completamente separados, y D1 lo hace posible sin complejidad.
La Realidad: Cuándo Usar D1
No es una solución universal. D1 brilla cuando:
- **Necesitas baja latencia global**: Usuarios distribuidos en múltiples continentes
- **Tus datos son pequeños o medianos**: SQLite no es una base de datos masiva
- **Patrones de lectura dominan**: D1 es excelente para lectura, la escritura es más lenta
- **Quieres simplicidad operacional**: No hay que gestionar servidores
Donde NO usar D1:
- **Datos masivos**: Si tu tabla tiene miles de millones de registros, no es para ti
- **Escrituras intensivas**: Si necesitas miles de writes por segundo, PostgreSQL es mejor
- **Transacciones complejas**: SQLite tiene limitaciones con concurrencia de escritura
- **Análisis en tiempo real**: No está optimizado para queries analíticas pesadas
El Código Real
Aquí hay un ejemplo práctico que usé en producción:
```javascript // Validar datos de usuario con D1 export async function validateUserAccess(request, env, tenantId) { const db = env.D1_DATABASES[`tenant_${tenantId}`]; const userId = new URL(request.url).searchParams.get('user_id');
const user = await db .prepare('SELECT id, role, active FROM users WHERE id = ?') .bind(userId) .first();
if (!user || !user.active) { return new Response('Unauthorized', { status: 401 }); }
return user; }
// Replicar datos a múltiples regiones export async function syncToReplicas(env, tenantId, data) { const regions = ['us', 'eu', 'apac'];
await Promise.all( regions.map(region => env.D1_DATABASES[`tenant_${tenantId}_${region}`] .prepare('INSERT OR REPLACE INTO data VALUES (?, ?)') .bind(data.id, JSON.stringify(data)) .run() ) ); } ```
Esto es lo que me voló la cabeza: las réplicas se sincronizan automáticamente. No necesitas escribir lógica de replicación compleja. Cloudflare lo maneja.
El Cambio Mental
D1 me obligó a pensar diferente sobre arquitectura:
Antes: Centralizar todo, optimizar para una sola base de datos, esperar latencia.
Ahora: Distribuir datos donde se usan, pensar en patrones multi-tenant, optimizar para velocidad.
Es el mismo cambio que pasó con CDNs hace una década. Al principio parecía innecesario. Ahora es estándar.
D1 está en ese punto ahora.
La Pregunta Incómoda
¿Por qué no todos están usando D1?
Porque es relativamente nuevo. Porque muchos desarrolladores no conocen SQLite bien. Porque la inercia es fuerte: "PostgreSQL funciona, ¿por qué cambiar?"
Pero si estás construyendo algo nuevo, especialmente una SaaS con usuarios globales, ignorar D1 es ignorar rendimiento gratis.
Takeaway
Cloudflare D1 no es una bala de plata. Pero para aplicaciones con latencia crítica y datos distribuidos, es probablemente la mejor decisión que puedes tomar hoy.
Lo mejor: el tier gratuito es generoso. Pruébalo. Migra una tabla. Mide la diferencia.
La física no miente. Menos distancia = más velocidad.
---
¿Estás usando D1? ¿O sigues con PostgreSQL centralizado? Cuéntame en qué contexto y por qué. Los patrones reales me interesan más que las teorías.
