Next.js + PostgreSQL + AWS: el stack que usamos para plataformas empresariales internas, y por qué

No llegamos a Next.js, PostgreSQL y AWS persiguiendo lo que está de moda, llegamos porque encaja de forma consistente con la forma de las plataformas empresariales internas: una mezcla de paneles autenticados, datos relacionales estructurados y puntos de integración con otros sistemas que una empresa ya opera. Este es el razonamiento real por capa, y dónde elegiríamos deliberadamente otra cosa en su lugar.

Next.js se gana su lugar más por la flexibilidad de renderizado que por React en sí mismo. Las plataformas internas rara vez son un solo tipo de página; a menudo hay una parte de cara al público (una página de login, quizás un punto de entrada de marketing) junto a paneles autenticados con datos por usuario. El renderizado por ruta de Next.js, estático donde el contenido no cambia por solicitud, renderizado en servidor o en cliente donde sí cambia, permite que una sola aplicación maneje ambos sin forzar una decisión arquitectónica de todo o nada.

PostgreSQL es el valor por defecto por la misma razón que lo ha sido durante dos décadas: los datos empresariales internos suelen ser genuinamente relacionales, los clientes se relacionan con pedidos que se relacionan con líneas de pedido que se relacionan con productos, y una base de datos relacional madura con fuertes garantías de consistencia encaja con esa forma mejor que recurrir por defecto a algo sin esquema. Su madurez también importa en lo operativo: prácticas bien entendidas de respaldo, migración y ajuste de rendimiento que no exigen apostar por herramientas todavía en desarrollo de una base de datos más nueva.

AWS se gana su lugar por dos cosas: control de infraestructura y amplitud de servicios. Una plataforma que empieza simple, una app web, una base de datos, a veces necesita crecer hacia el procesamiento de tareas en segundo plano, almacenamiento de archivos, tareas programadas, o infraestructura que un PaaS más simple no ofrece. Elegir infraestructura que pueda crecer hacia esas necesidades sin una migración de plataforma evita un costoso proyecto de re-plataformización más adelante, incluso cuando la versión temprana del sistema es genuinamente simple.

TypeScript en todo el stack, no solo en el frontend, es lo que realmente hace que esta combinación se mantenga sólida en la práctica. Los tipos compartidos entre el frontend de Next.js, la capa de API y el modelo de datos reducen toda una categoría de errores, el frontend y el backend en desacuerdo sobre la forma de un campo, que cuesta tiempo real de depuración en un stack de lenguajes mixtos.

Este no es un stack al que recurramos por defecto sin importar el proyecto. Un pequeño script interno que corre una vez a la semana no necesita un framework web completo. Un sitio de contenido en gran parte estático no necesita una base de datos relacional ni toda la amplitud de servicios de AWS; un hosting más simple hace ese trabajo con menos sobrecarga operativa. El stack encaja con plataformas internas de complejidad real y creciente, no con cualquier proyecto que resulte necesitar una interfaz web.

Dónde elegiríamos distinto: un equipo ya profundamente fluido en Vue recurre a Nuxt en lugar de Next.js por las mismas razones de fondo, no porque Next.js sea objetivamente mejor. Un proyecto con datos genuinamente simples y en forma de documento (no relacionales) podría encajar mejor con otra base de datos. Y un proyecto con restricciones de presupuesto ajustadas y necesidades de infraestructura modestas podría no necesitar en absoluto la amplitud de AWS. El stack sigue la forma real del proyecto, no al revés.

Lo que realmente estamos optimizando con esta combinación es una plataforma que pueda empezar simple y crecer sin una reescritura: flexibilidad de renderizado que escala desde una página de marketing hasta un panel complejo, un modelo de datos que se sostiene a medida que las relaciones se vuelven más complejas, e infraestructura con margen para lo que la plataforma necesite después. Ese es el argumento a favor de Next.js, PostgreSQL y AWS, no que sea inherentemente correcto, sino que ha funcionado proyecto tras proyecto porque la forma de "plataforma empresarial interna" se repite.