¿Por qué Postgres y no una base de datos NoSQL?

Porque la mayoría de productos de negocio tienen datos relacionales (usuarios, pedidos, pagos, tenants) y Postgres lo hace excelente, con JSONB cuando hace falta flexibilidad, full-text search integrado y extensiones como pgvector para IA. Empezar con NoSQL suele ser una optimización prematura que se paga en consistencia.

¿Por qué un PaaS y no Kubernetes?

Porque Kubernetes resuelve problemas que la mayoría de proyectos no tienen todavía, a cambio de mucha complejidad operativa. Un PaaS (Railway, Render, Fly, Vercel) despliega en minutos, escala lo suficiente para el 95% de los casos y libera tiempo para el producto. Migramos a infra más compleja solo cuando los números lo justifican.

← Blog · 18 jun 2026 · Ingeniería

El stack que usamos en 2026 (y por qué)

Q: ¿Usáis siempre el mismo stack?

Tenemos elecciones por defecto, no dogmas. Next.js + Postgres + un PaaS cubre la mayoría de proyectos web/SaaS. Cuando el proyecto pide algo distinto —un bot, un pipeline de datos, un juego en Unity, tiempo real intensivo— elegimos la herramienta adecuada en lugar de forzar la de siempre.

No creemos en el stack "más moderno", sino en el stack aburrido que entrega: tecnología probada, con comunidad grande, que un equipo pequeño puede mantener sin sorpresas. Estas son nuestras elecciones por defecto para 2026 y, más importante, cuándo nos salimos de ellas. Tener defaults claros nos permite empezar rápido y reservar la energía de decisión para lo que de verdad es específico de cada proyecto.

Frontend: Next.js (React) por defecto

Para web corporativa, SaaS y MVPs usamos Next.js: SSR/SSG/ISR cuando importa el SEO, App Router para apps con sesión, y un ecosistema enorme. Cuando el proyecto es una landing simple o una herramienta interna sin necesidad de React, no forzamos Next.js: HTML + CSS + un poco de JS rinde más y carga antes. Para interfaces muy interactivas y ligeras valoramos también SvelteKit.

Backend: Node/Express o FastAPI según el caso

Node + Express/Fastify cuando el front y el back comparten lenguaje y el equipo itera rápido. Python + FastAPI cuando hay datos, IA o automatización por medio: el ecosistema científico y de scraping no tiene rival. La decisión la marca el dominio del problema, no la moda.

Datos: Postgres casi siempre

Postgres es nuestra base por defecto: relacional sólido, JSONB para lo flexible, full-text search integrado y pgvector para búsquedas semánticas de IA sin montar otra base. Añadimos Redis para caché, colas y rate limiting. Solo salimos de Postgres con una razón concreta (series temporales masivas, grafos, escala extrema), no por defecto.

Pagos, auth e integraciones: no reinventar

Pagos: Stripe (Checkout, Billing, Connect). El Customer Portal nos ahorra construir gestión de suscripción.
Auth: proveedores gestionados (Clerk, Supabase Auth) o librerías sólidas; no construimos auth desde cero salvo requisito muy específico.
Email transaccional: Resend o Postmark, con plantillas versionadas.
Observabilidad: Sentry para errores, logs estructurados y alerting básico desde el día uno.

Infraestructura: PaaS primero, complejidad después

Desplegamos en un PaaS sencillo (Railway, Render, Fly.io, Vercel) con Postgres gestionado y CI/CD en GitHub Actions. Esto cubre el 95% de los proyectos y deja todo el tiempo para el producto. Kubernetes y arquitecturas multi-región llegan solo cuando el volumen y los requisitos los justifican, no porque queden bien en un diagrama. Para clientes con VPS propio usamos Docker + Nginx + PM2 con despliegue reproducible.

Fuera del default: cuando el proyecto manda

Bots y tiempo real: Node con la librería oficial del canal (Discord.js, Telegraf), colas y workers; WebSockets/Socket.IO para overlays en directo.
Juegos: Unity para móvil/casual; nada de forzar web aquí.
Pipelines de medios/IA: Python con FFmpeg, Puppeteer y APIs de IA, orquestado por colas.
3D y experiencias: Three.js sobre Next.js cuando la marca lo pide.

La regla es simple: defaults para ir rápido, criterio para lo específico. Un stack predecible es lo que permite entregar a tiempo y mantener el software vivo después de la entrega.

Preguntas frecuentes

¿Por qué Postgres y no NoSQL?

La mayoría de productos tienen datos relacionales. Postgres lo hace excelente, con JSONB para flexibilidad y pgvector para IA. Empezar con NoSQL suele ser optimización prematura.

¿Usáis siempre el mismo stack?

Tenemos defaults, no dogmas. Cuando el proyecto pide otra cosa (bot, pipeline, juego, tiempo real), elegimos la herramienta adecuada.

¿Por qué PaaS y no Kubernetes?

K8s resuelve problemas que la mayoría de proyectos no tiene aún, con mucha complejidad operativa. Un PaaS despliega en minutos y escala para el 95% de los casos.

¿Tienes un proyecto y dudas del stack?

Elegimos contigo la tecnología adecuada al problema y entregamos con precio cerrado por hitos. Sin sobre-ingeniería.

Ver servicios Pedir presupuesto

Recursos relacionados

Cuándo conviene Next.js en web corporativa — el detalle de SSR/SSG/ISR.
Backend SaaS multi-tenant — patrones y stack para un SaaS B2B.
IA en producción — qué montamos alrededor de un LLM.

Publicado: 18 de junio de 2026 · Escrito por el estudio RoviDev.