Guía de bases de datos para Next.js: comparativa completa de PostgreSQL, MySQL, MongoDB y servicios en la nube

El proyecto debe salir en 48 horas. Miro la opción «Add Database» en el panel de Vercel y el cursor se mueve entre Postgres, MySQL y MongoDB. Tengo diez pestañas abiertas: unos dicen que Supabase es generoso en el plan gratuito, otros que PlanetScale es rapidísimo, y otros que MongoDB es lo ideal para Next.js.

Demasiadas opciones. Todas parecen buenas y todas tienen límites. Peor aún: si eliges mal, migrar después puede costar más que reescribir código.

Si estás en esa misma encrucijada, este artículo es para ti. Te explico de forma directa las diferencias entre PostgreSQL, MySQL y MongoDB, y cómo elegir entre Vercel Postgres, Supabase, PlanetScale y MongoDB Atlas.

Sin rodeos.

Al terminar, solo tendrás que responder 3 preguntas para decidir rápido.

Primero lo básico: las diferencias entre las tres bases de datos

PostgreSQL vs MySQL vs MongoDB: más allá de relacional y NoSQL

Suele decirse que PostgreSQL y MySQL son bases relacionales y MongoDB es NoSQL. Cierto, pero esa clasificación no ayuda mucho a elegir: sigues sin saber cuál te conviene.

Voy a hablar de su «personalidad».

PostgreSQL es como una navaja suiza completa. Además de datos relacionales clásicos, maneja JSON, búsqueda de texto completo, datos geoespaciales e incluso procedimientos almacenados complejos. Casi todo lo avanzado que imagines, lo tiene. Eso implica una curva de aprendizaje algo más pronunciada: muchas funciones, muchas decisiones; al principio puede abrumar.

En rendimiento, PostgreSQL destaca en consultas complejas. Algunas pruebas muestran que en escenarios con varios JOIN puede ser ~30% más rápido que bases similares. Pero tiene coste: mal configurado, consume más recursos que MySQL.

MySQL es el compañero estable y fiable. Ligero, maduro, con documentación abundante y una comunidad enorme: casi cualquier problema tiene solución con una búsqueda. Muchos proyectos antiguos lo usan por tranquilidad.

También tiene límites. Escala de forma vertical: cuando la máquina llega al tope, solo puedes poner una más potente; no puedes añadir servidores en horizontal como MongoDB. Para tráfico moderado no pasa nada; en aplicaciones de alta concurrencia puede convertirse en cuello de botella.

MongoDB es otra historia. No guarda tablas, sino documentos en formato JSON. Eso da mucha flexibilidad: puedes añadir campos a un documento sin ALTER TABLE. Para proyectos con requisitos que cambian rápido, es un salvavidas.

Hice un CMS donde los campos personalizados de los artículos cambiaban a menudo: hoy «tiempo de lectura», mañana «recomendaciones relacionadas». Con MySQL, cada cambio implicaba ALTER TABLE y compatibilidad con datos históricos. Con MongoDB, bastaba añadir el campo en código.

Pero MongoDB no es bala de plata. ¿Consultas complejas con muchas relaciones? No las hace bien, o resultan incómodas. ¿Transacciones estrictas? Las soporta, pero no tan naturalmente como una base relacional.

Elegir base de datos no es elegir «buena» o «mala», sino «la adecuada».

¿Cuándo usar cada una? Tres criterios

Si no hay una «mejor» absoluta, ¿cómo decidir? Tres dimensiones prácticas.

Dimensión 1: complejidad de las relaciones de datos

Es el criterio central.

¿Tu proyecto tiene mucha lógica de «esto se relaciona con aquello»? Por ejemplo e-commerce: usuario → pedidos → productos → categorías → etiquetas… Escenarios con anidamiento y JOIN frecuentes: PostgreSQL o MySQL. Las relacionales nacieron para eso: claves foráneas y consistencia transaccional listas.

Si la estructura es más plana o cada registro es relativamente independiente, MongoDB simplifica mucho. Ejemplo típico: artículos y comentarios de un blog. Cada artículo puede ser un documento JSON completo; los comentarios anidados o en colección aparte con relación simple. Ahí la flexibilidad de MongoDB gana.

Dimensión 2: frecuencia de cambio de requisitos

¿El product manager cambia requisitos cada dos por tres? MongoDB puede salvarte.

He visto proyectos diseñados a la perfección en una base relacional — campos, índices, restricciones — y dos semanas después: «añadimos etiquetas de usuario», luego «multiselección», luego «jerarquía de etiquetas». Cada cambio implica migraciones y scripts hasta el cansancio.

Con MongoDB, añades campos en código y compatibilizas datos antiguos en la aplicación. Eso exige más validación en código: la base ya no te cubre tanto.

Si la lógica de negocio es estable — finanzas, ERP, reglas fijas — las restricciones de una relacional son ventaja: evitan datos incorrectos en la base y menos preocupaciones en el código.

Dimensión 3: con qué está cómodo el equipo

No lo subestimes.

No hay stack «superior», pero la familiaridad del equipo es real. Si todos vienen del SQL y fuerzas MongoDB, el aprendizaje y los errores pueden superar el propio proyecto. Y al revés.

En un equipo con perfil JavaScript, PostgreSQL nos costó en consultas complejas e índices. Al pasar a MongoDB + Mongoose, la productividad se duplicó: la API de Mongoose se parece a manipular objetos en JS, sin cambiar de mentalidad.

No significa ceder siempre a la zona de confort. Si el proyecto exige relacional, hay que aprender. Pero si ambas opciones sirven, elige la que el equipo domine.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

La batalla en la nube: Vercel Postgres, Supabase, PlanetScale y MongoDB Atlas

Comparativa de servicios: no solo el precio

Base de datos elegida, toca el mundo cloud.

Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas… todos suenan bien; el diablo está en los detalles.

Vercel Postgres: la tentación del despliegue en un clic

Si ya despliegas en Vercel, Vercel Postgres es casi la opción más cómoda. Unos clics, base lista, variables de entorno inyectadas, latencia muy baja (en benchmarks a menudo <10ms).

Pero es limitado en funciones: sin auth integrada, sin almacenamiento, sin suscripciones en tiempo real. Si solo quieres PostgreSQL puro, perfecto; si quieres «suite completa», combinas otros servicios.

Plan gratuito: 256MB de almacenamiento, suficiente para proyectos pequeños. De pago desde $20/mes; no es barato, pero la integración con Vercel puede compensarlo.

Supabase: el todoterreno del mundo open source

Supabase es de mis favoritos. No es solo PostgreSQL: trae autenticación, almacenamiento de archivos, suscripciones en tiempo real y un panel útil, Supabase Studio.

Plan gratuito generoso: 500MB de base + 1GB de almacenamiento; para MVPs y proyectos personales sobra. Conozco desarrolladores independientes con productos enteros en el tier gratuito.

En rendimiento, no alcanza a PlanetScale. Un benchmark sitúa Supabase en ~5000 QPS y PlanetScale en ~17000. En la mayoría de apps medianas la diferencia no se nota. Además usa PostgreSQL estándar, así que migrar es más sencillo.

Ojo: si el tráfico explota, el pool de conexiones puede ser cuello de botella. Ofrece Pooler para Serverless; con configurarlo basta.

PlanetScale: bestia de rendimiento, con precio

El rendimiento es fuerte: ~17000 QPS (lectura/escritura mixta), ~35000 en solo lectura, casi el triple de Supabase. En alta concurrencia se nota.

Tiene ramas de base de datos al estilo Git: pruebas cambios de esquema en una rama y fusionas al principal. Muy útil en equipos.

Pero hay pegas:

Primero, no soporta claves foráneas. Si dependes de ellas, la consistencia va en la aplicación.

Segundo, caro. En 2024 eliminó el plan gratuito; desde $34/mes. Para presupuestos ajustados pesa.

Mi consejo: si necesitas concurrencia extrema o ramas de base de datos en equipo grande, vale la pena. Si no, hay opciones más rentables.

MongoDB Atlas: flexibilidad con curva de aprendizaje

Servicio oficial de MongoDB. Plan gratuito 512MB, el doble que Vercel Postgres, similar a Supabase. Despliegue sencillo, varias regiones.

Si eliges MongoDB, Atlas es casi el default: oficial, estable, actualizado.

Pero el salto desde SQL a agregaciones (Aggregation Pipeline) cuesta. Las transacciones existen, pero no tan naturales como en relacional; en algunos casos el rendimiento baja.

Trampa oculta: coste de ancho de banda. Atlas cobra por almacenamiento y peticiones; con muchas consultas, el ancho de banda puede superar el coste de la base. Un conocido vio el 60% de la factura en bandwidth; optimizó consultas y añadió caché.

Tabla rápida de referencia:

Costes ocultos: no solo la cuota mensual

Muy importante: mucha gente cae aquí.

La cuota mensual es la punta del iceberg. Lo que duele son los costes ocultos.

Límite de conexiones: pesadilla Serverless

Next.js en Vercel u otra plataforma Serverless: cada petición puede abrir una instancia nueva. Si cada una abre una conexión a la base, cientos de concurrentes agotan el pool.

Los pools clásicos fallan en Serverless. Verás «Too many connections», «Connection pool exhausted»… no quiero otra alarma a las tres de la mañana.

La buena noticia: la mayoría de servicios lo tienen en cuenta. Supabase tiene Pooler, PlanetScale pool integrado, Vercel Postgres optimizado por ser del mismo proveedor. En MongoDB Atlas debes gestionarlo tú: librería de pool o alertas de conexiones.

Ancho de banda: asesino silencioso con muchas consultas

¿Base y app en regiones distintas? Cada consulta paga tráfico entre regiones.

Atlas es el caso más claro: cobra por peticiones y datos transferidos. Consultas frecuentes y payloads grandes hacen que el bandwidth supere el coste de la base.

Soluciones:

1. Despliega base y app en la misma región
2. Devuelve solo campos necesarios; evita SELECT *
3. Añade caché para reducir consultas repetidas

Coste de escalado: inversión a largo plazo

PlanetScale y Supabase escalan por almacenamiento y conexiones. Empiezas en tier bajo o gratuito; al crecer los datos, el precio salta de tramo.

Supabase: gratuito 500MB; Pro $25/mes con 8GB. Si llegas a 10GB, pagas extra. Parece poco, pero una factura que se duplica sin aviso duele.

PlanetScale cobra por filas: $34/mes incluye 10 mil millones de lecturas y 50 millones de escrituras; el exceso se paga por uso. En escritura intensiva, el coste sube rápido.

Coste de migración: el precio de elegir mal

El más ignorado.

Migrar no es solo copiar datos: esquema, código, pruebas… un proyecto pequeño puede llevar un par de días; uno grande, meses.

Tuve un proyecto en MongoDB por comodidad; al crecer la complejidad, las consultas dolían y migramos a PostgreSQL. Diseñar el esquema relacional llevó una semana; scripts de migración, dos semanas de depuración; despliegues en staging y producción — casi dos meses en total.

Por eso recomiendo: si dudas, elige algo mainstream y fácil de migrar. Usa un ORM (Prisma, Drizzle) como capa de abstracción; si cambias de base, menos cambios en código.

Marco de decisión: 3 preguntas

Pregunta 1: ¿Qué tipo de proyecto es?

Tras tanto detalle técnico, lo práctico: ¿qué eliges?

Un marco simple. Sin memorizar benchmarks: tres preguntas.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Primera pregunta: ¿qué tipo de proyecto es?

Eso decide el 80%.

Proyecto personal / MVP rápido

¿Presupuesto ajustado pero quieres funciones completas? → Supabase

500MB + 1GB gratis, auth y tiempo real incluidos: configuración soñada para independientes. Conozco SaaS enteros en el tier gratuito con miles de usuarios.

¿Prefieres NoSQL o esquema muy flexible? → MongoDB Atlas

512MB gratis; ideal para CMS, blogs, recolección de logs.

Startup / equipo pequeño

¿Ya en Vercel y priorizas velocidad de desarrollo? → Vercel Postgres

Solo 256MB gratis, pero integración profunda: variables automáticas, red edge — ahorra tiempo de configuración. En una startup el tiempo vale más que $20/mes.

¿Necesitas auth, archivos y más? → Supabase

No es solo base de datos: backend completo. Authentication, Storage, Edge Functions listos; ahorras semanas.

Empresa / alta concurrencia

¿Muchos usuarios y exigencia de rendimiento? → PlanetScale

~17000 QPS no es broma; las ramas de base de datos ayudan en equipos grandes. $34/mes es razonable con ingresos estables.

Ojo: PlanetScale no tiene claves foráneas; si tu lógica depende de ellas, repiensa la opción.

Sitio de contenidos / blog / medios

¿Datos flexibles y consultas simples? → MongoDB Atlas

Artículos, comentarios, etiquetas encajan natural en documentos. La búsqueda de texto en MongoDB suele ser más cómoda que en relacional.

¿Comentarios o notificaciones en tiempo real? → Supabase

Realtime con Change Data Capture sobre PostgreSQL; configuras y listo, sin montar WebSocket tú mismo.

Pregunta 2: ¿Presupuesto y escala?

El dinero importa.

Fase cero presupuesto (solo gratis)

Supabase (500MB + 1GB) o MongoDB Atlas (512MB).

Vercel Postgres gratis pero solo 256MB, poco margen. PlanetScale sin gratis: descartado.

Si necesitarás auth o subida de archivos, prioriza Supabase. Si es solo almacenamiento de datos, Atlas es más flexible.

Presupuesto pequeño (menos de $50/mes)

Supabase Pro ($25/mes) o Vercel Postgres (desde $20/mes).

Supabase Pro: 8GB de base + 100GB de almacenamiento + Auth para 50k MAU; muy rentable. Vercel Postgres cuesta un poco más, pero si todo el stack está en Vercel, el tiempo ahorrado compensa.

Atlas es por uso; en pequeña escala pueden ser pocos dólares al mes. Vigila el ancho de banda.

Presupuesto medio ($50-200/mes)

PlanetScale (desde $34/mes), Supabase Team ($599/año, ~$50/mes).

Criterio: rendimiento. Si no necesitas QPS altísimos, Supabase Team suele compensar más. En alta concurrencia, PlanetScale.

Gran escala / alta concurrencia

A este nivel, el cloud a veces deja de ser rentable. Muchas empresas usan AWS RDS, Google Cloud SQL o clusters PostgreSQL propios.

Sin DBA dedicado, seguir con PlanetScale o Supabase Enterprise también es válido: externalizas operaciones y te centras en el producto.

Pregunta 3: ¿Cuánta deuda técnica aceptas?

La última pregunta, a menudo olvidada, es clave.

Aceptas riesgo de migrar después

Empieza gratis, valida el producto. Cuando haya tracción, migras o subes de plan.

Muchos productos exitosos siguieron ese camino: MongoDB Atlas gratis hasta miles de usuarios; luego PostgreSQL por consultas más complejas; después cluster propio con pico de tráfico.

Prepárate:

1. ORM (Prisma, Drizzle) como capa de abstracción
2. Lógica de acceso a datos centralizada, no dispersa
3. Copias de seguridad periódicas por si migras

Quieres ir a lo seguro y evitar líos

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Elige lo maduro y mainstream: PostgreSQL + Supabase o PostgreSQL self-hosted.

PostgreSQL es el open source más maduro; ecosistema amplio y rutas de migración claras. Hoy Supabase, mañana AWS RDS o servidor propio con poco cambio en SQL.

MongoDB es flexible pero ecosistema más cerrado; pasar a relacional suele ser casi reescribir.

Mi experiencia

Por defecto en proyectos nuevos: Next.js + Prisma + Supabase.

Por qué:

• Plan gratuito suficiente; escalas cuando haya ingresos
• Prisma da tipos seguros y migraciones tranquilas
• Ecosistema PostgreSQL: puedes cambiar de proveedor cloud
• Auth y Storage integrados si los necesitas

En alta concurrencia o con equipo que ya opera bases de datos, PlanetScale o self-hosted.

Lista de configuración práctica

Configuración rápida

Basta de teoría; lo práctico.

Combinaciones habituales y puntos clave — sin bloques enormes de código, pero con lo que debes vigilar.

Opción 1: Vercel Postgres + Prisma

En 5 minutos puedes tenerlo corriendo.

Pasos clave:

1. En el proyecto Vercel: «Storage» → «Create Database» → Postgres
2. Variables en .env; usa process.env.POSTGRES_PRISMA_URL
3. Genera el cliente: npx prisma generate
4. Configura el pool de Prisma; en Serverless sin pool explotan las conexiones

Notas:

• Separa base de desarrollo y producción; no borres producción por error
• Commitea las migraciones de Prisma en git para el equipo

Opción 2: Supabase + Prisma

La más completa si necesitas Auth.

Pasos clave:

1. Crea proyecto en Supabase y copia la cadena de conexión
2. En variables: DATABASE_URL y DIRECT_URL (esta última para migrations)
3. Activa el modo Pooler de Supabase
4. Para Auth: @supabase/auth-helpers-nextjs integra bien con Next.js

Notas:

• Configura Row Level Security (RLS) o tendrás problemas de seguridad
• Realtime no viene activado por defecto; habilítalo en la tabla

Opción 3: MongoDB Atlas + Mongoose

Ideal para equipos con perfil JavaScript.

Pasos clave:

1. Crea cluster en Atlas y copia la URI (sustituye <password> por la real)
2. Define Schema con Mongoose; aunque MongoDB sea schemaless, conviene tipos en código
3. En la conexión: serverSelectionTimeoutMS para evitar timeout en cold start
4. En consultas usa .lean() para objetos planos y mejor rendimiento

Notas:

• Nunca subas la URI con contraseña a git; usa .env.local y .gitignore
• Crea índices manualmente o las consultas irán lentas
• Aggregation Pipeline tiene curva de aprendizaje; lee la documentación antes

Recomendaciones generales

Con cualquier opción:

1. Variables de entorno: .env.local (local) y .env.production (prod); no mezcles
2. Pool de conexiones: obligatorio en Serverless
3. Manejo de errores: try-catch en consultas; no expongas errores de base al usuario
4. Copias de seguridad: periódicas; el cloud también falla
5. Monitorización: conexiones, latencia de consultas, alertas

Conclusión

Volviendo al inicio: ¿qué base de datos para Next.js?

No hay respuesta única, pero sí un marco.

Tres preguntas:

1. Tipo de proyecto: ¿personal? ¿startup? ¿empresa?
2. Presupuesto: ¿cero? ¿pequeño (<$50)? ¿medio/grande?
3. Deuda técnica: ¿aceptas migrar después o quieres ir a lo seguro?

Si sigues indeciso, consejo conservador: Supabase + Prisma + PostgreSQL.

Por qué:

• Plan gratuito hasta que haya ingresos
• Suite completa (Database + Auth + Storage), menos tiempo de desarrollo
• Ecosistema PostgreSQL maduro, muchas rutas de migración
• Prisma aporta tipos seguros y código más fiable

Si tienes necesidades especiales — rendimiento extremo (PlanetScale), esquema flexible (MongoDB Atlas), integración profunda con Vercel (Vercel Postgres) — elige según el caso.

Última frase: elegir base de datos no es una decisión única, es un proceso. Lanza rápido, valida el producto y optimiza después. No dejes que la indecisión técnica retrase el lanzamiento.

Abre tu proyecto, responde las tres preguntas, decide en 10 minutos y empieza a codear.

Si tienes dudas, nos vemos en los comentarios.