La pregunta no es "VPS o cloud gestionado": es cuántas horas tuyas por mes vale la diferencia de precio. Un VPS de Hetzner cuesta menos que dos cafés. Vercel, Railway y PlanetScale cuestan más — y a cambio se llevan trabajos que en el VPS son tuyos: backups, parches de seguridad, failover, monitoreo, escalado. Elegir infraestructura para producción es decidir quién hace ese trabajo: vos o el proveedor.
Escribo esto porque me lo preguntan seguido, casi siempre desde el mismo lugar: un servidor privado (DonWeb, Hostinger, un VPS cualquiera) con la aplicación y la base de datos conviviendo en la misma máquina, y la duda de si "lo profesional" es migrar a la nube gestionada. La respuesta corta: la app puede vivir donde quieras; la base de datos es el punto donde no conviene improvisar. La larga es este artículo.
Cómo trabajamos nosotros: tres proveedores, tres trabajos distintos
En solu30 corremos varios SaaS en producción — reservas, punto de venta, agentes de WhatsApp — con un equipo mínimo. Nuestra arquitectura reparte cada pieza en el proveedor que mejor hace ese trabajo específico:
| Pieza | Proveedor | Por qué ahí |
|---|---|---|
| Frontend + API (Next.js) | Vercel | Deploy automático por commit, CDN global, rollback en un click, preview por branch |
| Servicios persistentes (bots, workers, colas) | Railway | Procesos long-running que Vercel no puede correr; Postgres y Redis gestionados al lado |
| Base de datos MySQL (datos de clientes) | PlanetScale | Backups automáticos, alta disponibilidad, cambios de schema sin downtime |
La lógica detrás de la división: Vercel es serverless — perfecto para páginas y APIs que responden y mueren, inútil para un bot de WhatsApp que necesita una conexión viva las 24 horas. Eso vive en Railway, que corre contenedores persistentes con la comodidad de un PaaS: conectás el repo de GitHub y cada push es un deploy, con logs, métricas y variables de entorno resueltos. Y los datos que no podemos perder viven en PlanetScale, donde el backup, la replicación y el failover son responsabilidad del proveedor, no un cron que escribimos un domingo y nadie volvió a verificar.
Ninguna de las tres piezas requiere administrar un servidor. No hay SSH, no hay apt upgrade, no hay certificado que renovar. Ese es el producto real que se compra: operación, no cómputo.
El VPS propio sigue teniendo sentido (y Hetzner es el ejemplo)
Un VPS es una máquina virtual que alquilás entera: instalás lo que quieras, corrés lo que quieras, nadie te factura por request. Hetzner es hoy la referencia en precio-rendimiento: su plan CX22 — 2 vCPU, 4 GB de RAM, 40 GB de disco y 20 TB de tráfico — cuesta €3,79 por mes. La máquina equivalente en Azure o AWS sale entre 5 y 10 veces más. Y es infraestructura seria: datacenters propios en Alemania y Finlandia, estable para producción, con años de reputación en la comunidad.
Lo que el precio no incluye es el trabajo. En un VPS, vos sos el sysadmin:
- Seguridad: parches del sistema operativo, firewall, fail2ban, rotación de claves. Un VPS expuesto sin mantenimiento es un objetivo, no un servidor.
- Deploys: configurar CI/CD, o entrar por SSH a hacer
git pull(y rezar). - Monitoreo: si el proceso muere a las 3 AM, ¿quién se entera? ¿Quién lo levanta?
- Escalado: si un día tenés 10 veces el tráfico, la máquina no crece sola.
- Backups: los snapshots del proveedor protegen contra "se murió el disco", no contra "borré la tabla equivocada hace 4 días".
Nada de esto es imposible — es trabajo. Con Docker, Coolify o CapRover, un VPS moderno se siente bastante PaaS. Pero cada una de esas capas la instalaste, la configuraste y la mantenés vos. El VPS barato es barato porque el SRE sos vos.
¿Cuándo lo elegimos nosotros? Para workers de cómputo pesado, para servicios internos sin cara al público, y para todo lo que tiene consumo constante y predecible donde el modelo por uso de un PaaS se vuelve caro. El VPS no es la opción amateur: es la opción correcta para otro tipo de problema.
La base de datos: el único punto donde no negociamos
Acá va la parte que le diría a cualquiera que hoy tiene la base de datos instalada en el mismo servidor que la aplicación: la app se reinstala en una tarde; los datos no se recuperan de ningún lado. Son la única pieza de tu sistema verdaderamente irremplazable, y por eso son la primera que conviene sacar del VPS.
La comparación honesta entre una base en tu VPS y una gestionada:
| Capacidad | DB en tu VPS | DB gestionada (PlanetScale, Railway, Neon) |
|---|---|---|
| Backups | Cron de mysqldump que escribiste vos, y que nadie prueba restaurar | Automáticos, diarios o mejores, con restore de un click |
| Recuperación a un punto en el tiempo | Solo si configuraste binlogs y sabés usarlos | Incluida o disponible como opción |
| Failover | Si el servidor cae, la DB cae con él | Réplicas y failover automático en planes de producción |
| Upgrades de versión | Los hacés vos, con downtime y riesgo | Los hace el proveedor |
| Cambios de schema | ALTER TABLE bloqueante en producción | PlanetScale los aplica sin downtime, con branching y revert |
| Métricas de queries | Instalás y mantenés tooling aparte | Panel incluido: queries lentas, índices faltantes |
| Aislamiento | App y DB compiten por CPU, RAM y disco | Recursos dedicados e independientes de la app |
El punto más subestimado es el primero. Todo el mundo "tiene backups". Casi nadie tiene restores verificados: la prueba periódica de que ese dump se puede levantar en una máquina limpia y los datos están completos. Un backup que nunca se restauró es una hipótesis, no un backup. Los proveedores gestionados convierten esa hipótesis en un botón.
¿El costo? Menos de lo que parece: PlanetScale arranca en $5/mes y un plan de producción chico (PS-10, con alta disponibilidad opcional) ronda los $30-39/mes. Railway te levanta un Postgres gestionado por $10-40/mes según tamaño. Contra eso hay que poner las horas de configurar replicación, monitorear discos, probar restores y el costo de un solo incidente grave. La base de datos gestionada es de las pocas cosas en infraestructura que se pagan solas.
MCP: la capa que un VPS artesanal no tiene
Acá aparece una diferencia nueva, de 2025-2026, que cambia la ecuación más de lo que parece. MCP (Model Context Protocol) es un estándar abierto que permite que asistentes de AI — Claude, Cursor, y otros — operen servicios externos con permisos controlados. Vercel y Railway ya publican servidores MCP oficiales; PlanetScale y Neon también se integraron al ecosistema.
En la práctica significa que un agente de AI conectado a tu infraestructura puede, con tu autorización:
- Leer los logs del deploy que acaba de fallar, diagnosticar el error y proponer el fix.
- Redeployar un servicio, crear un entorno, ajustar variables de entorno.
- Consultar métricas y estado de los servicios sin que abras un dashboard.
- Revisar queries lentas en la base y sugerir índices.
Nosotros trabajamos así todos los días: buena parte de la operación de nuestros SaaS la ejecutan agentes que hablan con Vercel y Railway por MCP. El incidente que antes era "entrar por SSH, hacer grep en los logs, adivinar" hoy es una conversación donde el agente ya miró los logs antes de responder.
¿Se puede tener esto en un VPS propio? Técnicamente sí — MCP es un protocolo abierto y podés escribir tu propio servidor que exponga tu infraestructura. Pero es otro proyecto más que construís y mantenés vos, mientras que en los proveedores gestionados viene de fábrica y lo mantienen ellos. Es la versión 2026 de la misma división de siempre: el proveedor gestionado no solo opera tus servicios — ahora también le da manos a tu AI para operarlos.
Entonces: ¿qué elegir?
No hay una respuesta única; hay una tabla de decisión:
| Tu situación | Recomendación |
|---|---|
| App web con tráfico variable, equipo chico | Vercel (frontend) + DB gestionada |
| Bots, colas, procesos 24/7 | Railway, o VPS si el consumo es alto y constante |
| Datos de clientes en producción | DB gestionada, siempre. Es la pieza innegociable |
| Cómputo pesado y predecible, presupuesto ajustado | VPS (Hetzner) con Docker + Coolify |
| Compliance o datos que deben quedarse en tu país | VPS local (DonWeb en Argentina) con backups externos verificados |
Y para el caso concreto que motivó este artículo — un servidor privado en DonWeb con la aplicación y la base de datos adentro — el camino que recomendaría no es un big bang de migración, sino tres pasos incrementales:
- Hoy mismo, sin migrar nada: backups automáticos de la base hacia afuera del servidor (otro proveedor u object storage), y una prueba de restore real. Esto convierte el riesgo catastrófico en un riesgo acotado, gratis.
- Primer movimiento: sacar la base de datos del servidor hacia un proveedor gestionado. La app puede quedarse donde está apuntando a la nueva DB. Es el 80% del beneficio con el 20% del esfuerzo.
- Después, si conviene: mover el frontend a Vercel para ganar deploys automáticos y CDN, y dejar el VPS para lo que hace bien — workers, cron jobs, servicios internos.
El orden importa: cada paso reduce riesgo por sí solo y ninguno te obliga a dar el siguiente.
Los números, todos juntos
Para un SaaS chico en producción, a precios de mitad de 2026:
| Stack | Costo mensual | Trabajo de operación |
|---|---|---|
| Todo en un VPS (Hetzner CX22) | ~€4 | Todo tuyo: seguridad, backups, deploys, monitoreo |
| VPS + DB gestionada | ~€4 + $5-39 | La mitad que más duele deja de ser tuya |
| Vercel + Railway + PlanetScale | ~$25-80 | Casi nada: commitear y mirar métricas |
La columna de la derecha es la que decide. Si tenés tiempo de sysadmin y te gusta ese trabajo, el VPS es imbatible en precio. Si tu tiempo tiene que ir al producto y a los clientes — que es nuestra situación, y la de casi cualquier equipo chico — las plataformas gestionadas cuestan menos que las horas que devuelven. Nosotros elegimos pagar esos $50 y que los backups, el failover y los deploys sean el problema de otro. Hasta ahora, no nos falló la cuenta.