Los puntos de referencia que comparan D1, PlanetScale y Neon tienden a medir algo incorrecto. Latencia en microsegundos, rendimiento de consultas por segundo, resultados de consultas sintéticas: ninguno de estos números responde a la pregunta que importa: cuál de estos tres bancos es el adecuado para lo que está creando ahora, considerando dónde crecerán sus datos, cuánto quiere pagar mientras no tenga tráfico y qué dialecto SQL asume su código. Hay tres arquitecturas diferentes con diferentes compensaciones, no variaciones de rendimiento del mismo producto.
D1: SQLite en el borde con cero costo para comenzar
El argumento central de D1 es la integración nativa con Cloudflare Workers. Cuando un trabajador accede a una base de datos D1 mediante enlace, no hay protocolo de enlace TCP, no hay cadena de conexión y no hay grupo de conexiones que administrar. La consulta va directamente al enlace D1 en el mismo contexto de ejecución, con una latencia inferior a un milisegundo para establecer la llamada. En una arquitectura sin servidor donde cada milisegundo de sobrecarga importa, esta integración es real y mensurable.
El nivel gratuito ofrece 5 GB de almacenamiento, 5 millones de líneas leídas por día y 100 mil líneas escritas por día, suficiente para desarrollo, herramientas internas y prototipos con poco tráfico real. En el plan pago: $0,001 por millón de líneas leídas, $1 por millón de líneas escritas, $0,75/GB-mes de almacenamiento. El desarrollo local a través de wrangler dev --local crea un archivo SQLite real en la máquina, con paridad de comportamiento con la base de datos remota.
Los límites que definen dónde D1 no es útil: 2 GB por banco, 10 bancos en el plan pago, sin extensiones SQLite personalizadas excepto sqlite-vec para búsqueda vectorial. Un banco que crece más allá de los 2 GB no tiene una ruta de expansión dentro de D1; debe dividir los datos o migrar a otro banco antes de alcanzar el límite. Para aplicaciones que previsiblemente superarán este límite, D1 es el banco adecuado para empezar y el banco equivocado para conservarlo a largo plazo.
PlanetScale: MySQL con fragmentación horizontal y ramificación de esquemas
PlanetScale se basa en Vitess, la misma base de datos infraestructura que escaló MySQL de YouTube a volúmenes que MySQL estándar no puede manejar. Este origen define lo que ofrece PlanetScale: MySQL genuino (la mayoría de los ORM funcionan sin modificaciones), fragmentación horizontal administrada por plataforma a medida que crecen los datos y el flujo de trabajo de ramificación de esquemas que distingue a PlanetScale de cualquier otra base de datos disponible en la actualidad.
La bifurcación de esquema funciona como control de versiones para el esquema: usted crea una rama de esquema, aplica los cambios, prueba y fusiona nuevamente con la rama principal. La migración se ejecuta sin bloquear tablas, a diferencia del ALTER TABLE estándar de MySQL, que bloquea las escrituras durante la ejecución. Para los equipos que luchan con las ventanas de mantenimiento para las migraciones o que necesitan revertir cambios de esquema de forma segura, esta funcionalidad resuelve un problema real.
El costo es el filtro más importante: PlanetScale finalizó el nivel gratuito en 2024. El plan Scaler comienza en $39/mes. Para proyectos paralelos y aplicaciones en etapa inicial que no generan ingresos, este piso elimina PlanetScale como opción. Para productos con ingresos consistentes y equipos que tienen experiencia en MySQL, $39/mes por lo que ofrece PlanetScale es razonable. La comparación correcta no es con D1 gratuito, sino con el costo de administrar manualmente la fragmentación de MySQL cuando el volumen crece.
Neon: PostgreSQL real con computación sin servidor
Neon ofrece PostgreSQL: no un subconjunto compatible, ni SQLite con una interfaz MySQL, sino el tiempo de ejecución real de Postgres. Esta distinción es importante cuando lo que necesita no existe en ninguna otra base de datos sin servidor: PostGIS para datos geoespaciales, pg_trgm para búsqueda de texto difuso, pg_partman para partición automática de tablas, TimescaleDB para series de tiempo, funciones de ventana complejas que SQLite realiza con limitaciones.
El modelo de computación sin servidor de Neon, que escala a cero cuando no hay consultas, lo coloca en una posición interesante para aplicaciones con tráfico esporádico: usted paga por la computación solo cuando se accede activamente a la base de datos. El plan Pro cuesta $19/mes con 10GB de almacenamiento incluidos. Para los equipos que ya tienen código PostgreSQL y necesitan una base de datos sin servidor sin migrar el dialecto SQL, Neon es el camino más directo.
La desventaja en comparación con D1 en un entorno de Cloudflare Workers: Neon utiliza un grupo de conexiones (Neon Proxy) al que se accede a través de la cadena de conexión estándar de PostgreSQL. No existe un enlace nativo como el que tiene D1. La latencia para establecer la conexión con Neon Proxy depende de la región de Neon que haya configurado y de dónde se esté ejecutando el Worker; puede ser de 10 ms u 80 ms según la topología, en comparación con submilisegundos para D1.
El costo de la migración entre los tres
Elegir una base de datos al inicio de un proyecto tiene un coste implícito que sólo aparece si la elección es incorrecta y es necesario cambiar. Los tres bancos tienen costos de migración asimétricos.
Pasar de D1 a Neon es técnicamente factible pero no trivial: wrangler d1 export genera un volcado de SQL en el dialecto SQLite, que debe convertirse a PostgreSQL antes de importar. La mayoría de las consultas son compatibles, pero los comportamientos específicos de SQLite (como la afinidad de tipos, la semántica de AUTOINCREMENT versus SERIAL, el manejo de fechas) requieren revisión caso por caso. El volumen de ajustes depende de cuánto aprovecha el código las peculiaridades de SQLite.
Pasar de PlanetScale a cualquier otra base de datos significa pasar de MySQL a SQLite (D1) o PostgreSQL (Neon): dialectos diferentes con suficientes divergencias de sintaxis como para requerir un esfuerzo real de portabilidad. Si el código utiliza transacciones con sintaxis específica de MySQL, funciones de cadena de MySQL u otras características patentadas, la migración es más costosa.
La regla que simplifica la decisión: si estás en Cloudflare Workers y tus datos caben en menos de 2 GB, D1 es el valor predeterminado correcto. Si necesita PostgreSQL desde el principio (para extensiones, compatibilidad con herramientas existentes, para consultas que SQLite no admite bien), comience con Neon en lugar de migrar más tarde. PlanetScale entra en juego cuando el escalamiento horizontal de Vitess es el requisito, no el precio de entrada. Ninguno de los tres resuelve bien las cargas de trabajo analíticas; para esto, Cloudflare Analytics Engine o una base de datos OLAP especializada es el camino más corto.
Lea también
- Enrutamiento de correo electrónico vs Improvmx vs Reenvío de correo electrónico: comparación honesta
- Trabajadores + D1 + KV + R2: componer vinculaciones en un mismo servicio
- DNS proxy versus DNS solamente: qué cambia y cuándo tiene sentido cada modo
- KV vs R2 vs Cache API: cuándo usar cada nivel de almacenamiento de Cloudflare
- Cloudflare D1: La base de datos SQLite en el borde, y por qué "borde" no significa lo que parece
- Balanceo de carga y dirección geográfica de Cloudflare: cuando DNS se convierte en una capa de tráfico inteligente