La factura de un proyecto pequeño casi nunca se decide el día que llega abultada. Se decidió meses antes, en una tarde, cuando alguien eligió dónde alojarlo y siguió el primer tutorial que apareció.
Las tres opciones que se reparten hoy casi todo el mercado resuelven el mismo problema con repartos de trabajo muy distintos. La diferencia real entre ellas no es técnica ni de precio de lista: es cuánta operación te quedas y cuánta le pasas a otro.
VPS: alquilas una máquina y todo lo que ocurre dentro es tuyo, desde el sistema operativo hasta el servidor web.
PaaS: entregas el código y la plataforma se encarga de construirlo, ejecutarlo y mantenerlo en marcha.
Serverless: entregas funciones sueltas que se ejecutan cuando algo las invoca, y no hay nada encendido entre invocación e invocación.
Lo que de verdad estás comprando
Un servidor no es un gasto de infraestructura, es un gasto de atención. Alguien tiene que aplicar actualizaciones de seguridad, renovar certificados, vigilar que el disco no se llene y levantar el servicio a las tres de la mañana cuando se cae.
Ese trabajo existe siempre. Las tres opciones se diferencian en quién lo hace y cuánto cuesta que lo haga otro. Cuando el equipo es de una o dos personas, esa cuenta pesa más que la diferencia mensual entre planes, porque el tiempo que se va en operar no se va en construir.
Por eso la comparación honesta no es cuál es más barato por mes, sino cuál es más barato sumando lo que pagas y lo que dejas de hacer.
Dónde cambia el precio sin que lo veas
Los tres modelos cobran de forma distinta, y ahí está la mayoría de las sorpresas.
El VPS cobra una cifra fija: pagas lo mismo con diez usuarios que con diez mil, hasta que la máquina se queda corta y hay que saltar al plan siguiente. Es el modelo más predecible y el que peor absorbe un pico inesperado.
El PaaS cobra por instancia encendida, casi siempre con un escalón gratuito o barato al principio que se vuelve caro cuando el proyecto crece. La sorpresa típica llega al sumar los extras: la base de datos gestionada, el almacenamiento y los entornos de prueba suelen costar más que la aplicación en sí.
Serverless cobra por ejecución y por tiempo de cómputo. Con tráfico bajo es casi gratis, y esa es su ventaja real. El riesgo es que el costo depende de cuántas veces se invoque, y un error en bucle, un proceso que se llama a sí mismo o un pico de tráfico automatizado producen una factura que nadie autorizó.
En cualquiera de los tres, configura un aviso de gasto antes de desplegar nada. En serverless además un tope de ejecuciones concurrentes.
No es una medida de ahorro, es una alarma de incendios: convierte una factura sorpresa en un mensaje a tiempo.
El arranque en frío y a quién le importa de verdad
Serverless apaga lo que no se usa, y esa es exactamente la razón de que sea barato. La contrapartida es que la primera petición después de un rato de inactividad tiene que esperar a que el entorno se levante.
Ese retraso se ha discutido mucho más de lo que suele importar. Para una API que recibe tráfico constante, casi no se nota porque el entorno rara vez se enfría. Para un panel interno que se usa tres veces al día, cada uso empieza con una espera visible. Y para un proceso en segundo plano, da igual por completo.
La pregunta útil, entonces, no es cuántos milisegundos tarda, sino si hay alguien esperando delante de la pantalla cuando ocurre.
Cómo se comparan, punto por punto
| VPS | PaaS | Serverless | |
|---|---|---|---|
| Qué entregas | Una máquina vacía | El repositorio | Funciones sueltas |
| Quién parchea el sistema | Tú | La plataforma | No aplica |
| Cómo se cobra | Fijo por mes | Por instancia encendida | Por ejecución |
| Costo con tráfico casi nulo | El mismo de siempre | Bajo o gratis | Casi cero |
| Costo con tráfico alto sostenido | El más bajo | Medio | El más alto |
| Ante un pico inesperado | Se satura | Escala con costo | Escala solo |
| Procesos largos | Sin límite | Sin límite | Limitados por tiempo |
| Esfuerzo de operación | Alto y continuo | Bajo | Bajo, pero se reparte |
| Costo de salir | Días | Semanas | Meses |
Vale la pena detenerse en la última fila, porque es la que menos se mira al elegir. Un VPS ejecuta lo mismo en cualquier proveedor, así que mudarse es mover archivos. Serverless, en cambio, ata el código a la forma de invocar, a los permisos y a los servicios propios de esa nube, y esa atadura crece con cada función que se añade.
Los dos cruces son lo interesante del gráfico. Antes del primero, serverless es imbatible porque casi no se usa. Después del segundo, el precio fijo del VPS gana justamente por ser fijo. En medio queda la franja donde vive la mayoría de los proyectos, y donde la respuesta depende de cuánta operación quieras asumir.
Qué elegir según la etapa
La respuesta cambia menos con el tamaño del proyecto que con la fase en que está.
- Proyecto que todavía busca usuarios. PaaS. Lo que se optimiza aquí es el tiempo hasta tener algo en marcha, y pagar unos euros de más por no operar servidores es un buen negocio mientras no se sepa si el proyecto sobrevive.
- Tráfico bajo, irregular o por rachas. Serverless, siempre que no haya procesos largos. Un formulario de contacto, un webhook que llega de vez en cuando o una tarea nocturna no justifican una máquina encendida las veinticuatro horas.
- Tráfico constante y previsible. VPS. A partir de cierto volumen sostenido es claramente lo más barato, y la operación deja de ser un problema cuando el sistema ya no cambia todos los días.
- Cargas que no encajan en una función. VPS o contenedores gestionados. Procesar vídeo, mantener conexiones abiertas o cualquier tarea de varios minutos choca con los límites de tiempo de serverless.
Estas categorías se mezclan con naturalidad, y esa suele ser la mejor respuesta. La aplicación principal en PaaS y tres tareas puntuales en serverless es una combinación común y sensata. Lo que casi nunca sale bien es lo contrario: reconstruir toda una aplicación como funciones sueltas porque el modelo parecía moderno.
Cuando el proyecto no encaja en una sola casilla
La tabla anterior presenta tres opciones como si hubiera que elegir una, y en la práctica casi ningún proyecto vive entero en una sola.
Un sitio con una parte pública que recibe visitas constantes, un panel de administración que usan tres personas y un par de tareas que corren de madrugada tiene tres perfiles de carga distintos. Forzarlos al mismo modelo significa pagar de más en dos de los tres, o quedarse corto en uno.
El reparto que mejor funciona en proyectos pequeños suele ser el mismo: la aplicación principal en un sitio estable, y fuera de ella solo lo que tiene un motivo claro para salir.
- Lo que se ejecuta de vez en cuando y no hace esperar a nadie: una limpieza nocturna, un informe semanal, un webhook que llega pocas veces al día. Encaja en serverless casi sin discusión, porque el resto del tiempo no cuesta nada y el arranque en frío no lo sufre ningún usuario.
- Lo que consume recursos de otro orden: convertir imágenes, generar documentos pesados. Sacarlo evita dimensionar toda la aplicación para un pico que ocurre dos veces al día.
- Todo lo demás se queda junto. Repartirlo añade puntos de fallo y complica el diagnóstico sin ahorrar nada apreciable.
La regla práctica es que cada pieza que se separa debe tener un motivo que quepa en una frase. Si no lo tiene, pertenece al bloque principal.
El costo que no sale en ninguna comparativa
Las tablas de precios comparan lo que factura el proveedor. El gasto que decide si la elección fue buena rara vez aparece ahí.
Una máquina propia obliga a alguien a atender actualizaciones, certificados, espacio en disco y caídas. En una empresa con equipo de sistemas eso ya está cubierto y no cambia la ecuación. En un proyecto de una persona son horas que compiten directamente con construir el producto, y suelen llegar en el peor momento, porque los servidores no fallan en horario de oficina.
Conviene ponerle un número aproximado antes de decidir. Si administrar el VPS consume entre dos y cuatro horas al mes entre mantenimiento e incidentes, esas horas pesan más que la diferencia de precio con un PaaS en casi cualquier proyecto que todavía esté creciendo.
El cálculo se invierte cuando el sistema se estabiliza. Una aplicación que cambia poco y tiene tráfico previsible exige poca atención, y entonces el VPS recupera la ventaja que su precio fijo siempre tuvo.
Y hay un tercer costo, el más fácil de ignorar: el de no entender dónde se ejecuta tu propio sistema. Si la infraestructura la configuró una herramienta a partir de un prompt y nadie del equipo sabe qué hay encendido ni por qué, el día del incidente no se empieza a diagnosticar, se empieza a investigar. Esa diferencia se mide en horas de caída.
El error que aparece al preguntarle a una IA
Cuando esta decisión se le plantea a un modelo sin contexto, la respuesta tiende a la arquitectura más elaborada de las tres, porque es la que más abunda en la documentación reciente: funciones, colas, almacenamiento de objetos y una base de datos gestionada.
El problema no es que esté mal, es que responde a una pregunta que no hiciste. Nadie preguntó cuánta gente va a operar eso, ni si el proyecto tiene tráfico, ni cuánto se puede pagar al mes.
Añadir esos tres datos al prompt cambia la respuesta por completo. Decir somos una persona, tráfico bajo, presupuesto de veinte euros al mes, sin experiencia administrando servidores descarta solo la mitad de las opciones y hace innecesaria la conversación sobre la otra mitad.
Cómo decidir sin quedarte atrapado
Hay una asimetría que conviene tener presente. Empezar en PaaS y mudarse a un VPS cuando el tráfico lo justifique es un trabajo de días, porque el código no asume nada de la plataforma. Empezar repartido en funciones y volver atrás es bastante más caro, porque para entonces la lógica está troceada según la forma de invocar de un proveedor concreto.
Ante la duda, la opción reversible es la que mantiene el proyecto como una aplicación normal que podría ejecutarse en cualquier sitio. Eso no impide usar serverless donde encaja de verdad: lo que evita es que la decisión se vuelva irreversible sin que nadie la haya tomado a conciencia.
Y conviene revisarla una vez al año con la factura delante. Los proyectos cambian de fase y el modelo que era correcto al empezar deja de serlo cuando el tráfico se estabiliza.