Elegir base de datos para Next.js: cuatro plataformas

Los cuatro nombres del título no son cuatro marcas de lo mismo. Debajo de cada uno hay una decisión distinta sobre dónde viven los datos y qué se sitúa delante, y esas decisiones llegan a su código.

Esto es lo que vende cada una en realidad, y dónde se transparenta.

Neon: Postgres con el almacenamiento separado del cómputo

Lo distintivo no es el precio serverless. Es que la capa de almacenamiento está separada del cómputo, lo que convierte una rama de base de datos en una operación de copia en escritura en lugar de un volcado y una restauración.

Qué compra eso. Una rama por pull request, a escala de datos de producción, en segundos. Migraciones probadas contra recuentos de filas reales en CI en vez de contra una tabla sembrada con cuarenta. Para un equipo al que alguna vez una migración se le comportó distinto en producción, esta es la funcionalidad por la que merece pagar.

A qué estar atento. El cómputo se suspende al quedar inactivo, lo cual es un ahorro si su tráfico tiene de verdad periodos de silencio y un arranque en frío si no. Y cualquier cosa que consulte la base de datos con un temporizador la mantendrá despierta, así que el ahorro es fácil de perder sin darse cuenta.

El driver HTTP es el otro motivo por el que aparece en conversaciones sobre Next.js: quita el pooling de conexiones como problema para caminos de lectura simples, con las salvedades que trae una consulta de un solo disparo.

Supabase: Postgres más lo que lo rodea

Supabase es un Postgres real con autenticación, almacenamiento de objetos, suscripciones en tiempo real y una API generada automáticamente encima. La comparación solo va en parte de la base de datos.

Qué compra eso. Si de todas formas necesita autenticación y almacenamiento de ficheros, que compartan un modelo de identidad con sus datos es un ahorro genuino, y la seguridad a nivel de fila significa que una regla de autorización puede vivir en la base de datos en lugar de reimplementarse en cada ruta que toca la tabla.

A qué estar atento. RLS es potente y es un segundo sitio donde vive la autorización. Una política sutilmente equivocada falla en abierto, y no se ve en el código de su aplicación. Adopte lo que adopte, hágalo a propósito: o la base de datos es dueña del control de acceso o lo es la aplicación, y tener las dos cosas es como acaban contradiciéndose.

Si la usa solo como host de Postgres, compárela como tal. Casi todo su valor está en las partes que de otro modo construiría.

PlanetScale: MySQL, fragmentado por debajo

Vitess bajo el capó, la tecnología que permitió a grandes despliegues de MySQL escalar horizontalmente. La funcionalidad visible es un flujo de trabajo de esquema: ramas y deploy requests, con cambios de esquema aplicados sin bloquear.

Qué compra eso. Cambios de esquema sin bloqueo en tablas muy grandes, que es un problema real y difícil resuelto como corresponde. Y un flujo de revisión para el esquema que se parece al que ya usa para el código.

A qué estar atento. El modelo de fragmentación es la razón por la que el soporte de claves foráneas ha sido un objetivo móvil: la integridad referencial entre shards es genuinamente cara, y lo soportado ha cambiado con el tiempo. Compruebe el comportamiento actual antes de apoyarse en ello. Una clave foránea aceptada y no impuesta es peor que una rechazada, porque su aplicación cree algo que la base de datos no está haciendo.

Además es MySQL, así que si su esquema quiere jsonb, índices parciales o extensiones, es la lista equivocada.

Turso: SQLite, distribuido

SQLite como servicio, replicado a ubicaciones cercanas a sus usuarios, hablado sobre HTTP.

Qué compra eso. Latencia de lectura muy baja desde cualquier sitio, porque la lectura es local en lugar de cruzar un océano. Y la simplicidad operativa de SQLite con la historia de durabilidad que de otro modo tendría que construir.

A qué estar atento. Las escrituras van a un primario, así que una escritura no es local y el perfil de latencia es asimétrico. Y es SQLite: tipificación laxa, un conjunto de funciones distinto y un modelo de concurrencia construido alrededor de un escritor. Para datos dominados por lectura con un camino de escritura pequeño es excelente. Para una aplicación transaccional con escrituras disputadas es la forma equivocada.

Cómo elegir sin una hoja de cálculo

Conteste tres preguntas y la lista se estrecha sola.

¿Su esquema quiere funcionalidades de Postgres? JSON que va a consultar, índices parciales, restricciones CHECK, extensiones, PostGIS. Si la respuesta es sí, dos de las cuatro quedan fuera de inmediato, y con eso está tomada la mayor parte de la decisión.

¿Su tráfico es irregular o estable? Genuinamente irregular - una campaña, un producto de temporada, una herramienta B2B que nadie toca los fines de semana - es para lo que existe el precio por consumo. El tráfico estable en una instancia fija es casi siempre más barato y es la respuesta correcta y poco de moda para muchas aplicaciones.

¿Está comprando una base de datos o un backend? Si auth, almacenamiento y tiempo real están en su lista igualmente, una plataforma que los incluya es un trato distinto y mejor que una base de datos más tres servicios. Si no lo están, está comparando hosts de Postgres.

La parte que no es la base de datos

Elija lo que elija, el trabajo específico de Next.js es el mismo: un cliente por ámbito de módulo, el endpoint con pooling para las peticiones y el directo para las migraciones, y una decisión sobre dónde viven las consultas. Eso cuesta una tarde y determina si la plataforma se porta bien.

Elegir el proveedor perfecto y construir un cliente dentro de un route handler le da un error de límite de conexiones sobre una base de datos muy bien construida.