Llevamos meses viendo la misma comparativa reciclada en X, en LinkedIn y en los agregadores: dos capturas de pantalla de páginas de precios, un multiplicador espectacular y un hilo de doscientas respuestas. Falta lo único que importa. Nadie define la unidad de medida.
¿Sabes qué es un usuario en una factura de hosting? Porque puede ser un registro dormido en una tabla de Postgres que no ha abierto la app desde marzo, o puede ser una sesión concurrente reproduciendo vídeo a 4 Mbps. Entre esos dos extremos, con exactamente el mismo número en el panel de administración, la diferencia de importe mensual es de dos órdenes de magnitud. Y ahí se cae la mitad de los hilos virales.
Así que hicimos lo aburrido. Montamos la misma aplicación en las dos infraestructuras: Hetzner y Vercel, definimos tres perfiles de carga medibles, y facturamos durante tres meses seguidos: de octubre a diciembre de 2025. También cronometramos las horas de operación con un timer, porque decir «el mantenimiento tiene un coste» sin ponerle un número al lado es escribir humo. Y al final medimos algo que no aparece en ninguna comparativa del sector: cuánto cuesta salir.
Qué significa «diez mil usuarios» en una factura de hosting
Diez mil registrados con 800 activos al mes generan una factura de 12 €/mes en servidor dedicado y unos 34 €/mes en plataforma gestionada. Diez mil activos mensuales con 400 sesiones concurrentes y vídeo suben a 281 €/mes y 3.640 €/mes respectivamente. Mismo número en el panel, factura 130 veces distinta.
Esa cifra, en nuestra experiencia revisando infraestructuras de producto, funciona como un ídolo. Suena a hito, suena a tracción, y no dice absolutamente nada sobre consumo de recursos. Un SaaS B2B de facturación con diez mil cuentas puede vivir cómodo en una máquina de 40 € porque sus usuarios entran cuatro veces al mes durante seis minutos. Una app de audio con la misma base tumba un plan gestionado en una tarde.
Registrados, activos y concurrentes no son intercambiables
Definimos tres magnitudes y las usamos durante todo el experimento, sin mezclarlas nunca:
- Registrados: filas en la tabla de usuarios. Cuestan almacenamiento, no cómputo.
- Activos mensuales (MAU): sesiones únicas en 30 días. Determinan el gasto de cómputo agregado.
- Concurrentes en pico: sesiones simultáneas en el peor minuto del mes. Determinan el tamaño de máquina y el techo de tráfico de salida.
Y aquí está el quid: las páginas de precios de todo el sector facturan sobre las dos últimas, mientras los fundadores presumen de la primera. Total, que la comparativa se hace mal desde la primera celda de la hoja de cálculo.
¿Por qué la plataforma gestionada sale tan caro frente al servidor dedicado? Porque paga 0,128 $ por hora de vCPU activa (unos 92,16 $/mes de cómputo continuo, precio de catálogo consultado en diciembre de 2025) frente a los 2,30 $/mes que cuesta ese mismo vCPU en un dedicado AX162-R. Son 40 veces más, y eso solo mirando CPU: sin memoria, sin tráfico, sin base de datos.
Cómo medimos: la app de prueba y los tres perfiles de carga
Usamos un producto real, no un «hola mundo»: una app Next.js 15 con App Router, autenticación propia, PostgreSQL 16, cola de trabajos en background para generar informes PDF y un bucket de object storage con 340 GB de assets. Unas 47.000 líneas de código, once endpoints con carga apreciable.
Del lado gestionado desplegamos en Vercel con plan Pro, dos asientos, add-on de Postgres y observabilidad activada. Del lado del hierro montamos el stack que ya hemos documentado en producción para otros equipos: máquina de Hetzner, despliegue con Kamal, Postgres autogestionado con réplica y Cloudflare delante. Mismo código, mismas migraciones, mismo commit.
Los tres perfiles se generaron con k6 durante 72 horas por escenario y luego se extrapolaron a mes completo con el patrón horario real de un cliente nuestro (picos a las 10:00 y a las 17:00, valle nocturno del 4% de la carga máxima):
- Perfil A — dormido: 10.000 registros, 800 MAU, 38 concurrentes en pico, 120 GB de tráfico de salida.
- Perfil B — sano: 10.000 MAU, 140 concurrentes, 900 GB de salida de datos, 1,2 M de ejecuciones de función.
- Perfil C — pesado: 10.000 MAU con vídeo, 400 concurrentes, 14 TB de egress.
Los números del servidor propio: hardware, backups y horas de operación
¿Cuánto cuesta un servidor de Hetzner para una app en producción? Entre 12 y 281 €/mes según perfil, IVA aparte. El perfil dormido cabe en un VPS de 7,05 €/mes más backups; el sano necesita un dedicado de gama media con réplica de base de datos; el pesado exige un AX162-R, y ahí el ancho de banda deja de ser el problema.
Desglosamos el perfil B, que es donde vive el 80% de los productos que auditamos. Máquina principal AX41-NVMe: 46,41 €/mes. Segunda máquina para la réplica de Postgres y los jobs: 26,60 €/mes. Storage Box de 1 TB para backups con retención de 30 días: 3,81 €/mes. Object storage para los assets: 5,94 €/mes. Cloudflare Pro delante, por WAF y caché: 18,40 €/mes. Suma de infraestructura: 101,16 €/mes, o 122,40 € con IVA español si eres autónomo facturando en España. Si tienes VIES activo y facturas intracomunitario, el recibo llega sin IVA y lo autoliquidas: neutral en caja, pero un asiento contable más cada mes.
Backups: la partida que todos presupuestan y nadie prueba
Un snapshot no es un backup, y un backup que no has restaurado nunca es una carpeta con esperanza dentro. Nosotros lo aprendimos por la vía cara: en un proyecto de 2023 teníamos pg_dump diario funcionando durante catorce meses. El día que hubo que restaurar, descubrimos que la extensión pgvector no estaba en el volcado y la restauración fallaba a los cuatro minutos. Tres horas y media de downtime, con el CTO del cliente delante nuestro mirando la terminal (aprendimos más en esas tres horas y media que en los catorce meses anteriores, aunque no es una escuela que recomendemos).
Desde entonces cronometramos también el ensayo de restauración: 40 minutos al mes, una vez al mes, sin excepciones. Va dentro de las horas de operación y no es negociable.
Las horas que costó operar el hierro
Cronómetro en mano, tres meses, perfil B. Parches de seguridad y reinicios: 1,8 h/mes. Ensayo de restauración: 0,7 h/mes. Ajustes de Postgres, índices y vacuum: 1,1 h/mes. Incidencias no planificadas (una de ellas, un disco NVMe degradado a las 3:40 de la madrugada): 2,4 h/mes de media. Actualizaciones del runtime y del pipeline de Kamal: 0,9 h/mes. Total: 6,9 h/mes.
Los números de la plataforma gestionada: funciones, egress y extras facturados
¿Cuánto cuesta Vercel al mes con 10.000 usuarios? Medimos 34 €/mes en el perfil dormido, 247 €/mes en el sano y 3.640 €/mes en el pesado, con precios de catálogo de diciembre de 2025. El salto no lo provoca el número de cuentas: lo provocan el cómputo activo y, sobre todo, el tráfico de salida.
Cuando abres la factura del perfil B, la sorpresa no está donde esperabas. Los asientos son 36,80 €. El cómputo activo, con 1,05 vCPU medias facturables, sale a 89,20 €. Hasta aquí, previsible. Después aparecen las tres partidas de las que nadie habla en las páginas de producto: 61,30 € de add-on de base de datos facturado con precios que escalan por fila almacenada, 43,10 € de tráfico de salida por encima de la cuota incluida, y 16,60 € de observabilidad porque sin ella estás depurando a ciegas (sí: pagas un extra por poder ver lo que ya te está costando dinero).
¿Cuánto ancho de banda incluye el servidor dedicado y cuánto cuesta el exceso en la plataforma gestionada? En el contrato de dedicado que usamos, la salida de datos no se factura por volumen: los 900 GB del perfil B costaron 0,00 €. En el plan gestionado, esos mismos 900 GB añadieron 43,10 € una vez agotada la cuota incluida, y en el perfil C, con 14 TB, el ancho de banda pasó a ser la partida dominante del recibo.
La cola de trabajos que tuvimos que rediseñar
Aquí cometimos el error más caro del experimento, y lo cuento porque es exactamente el error que vemos repetirse. Nuestra cola de informes PDF usaba BullMQ con workers de larga duración. En un entorno de funciones con timeout, eso no existe: hay que partir el trabajo en fragmentos, montar reintentos idempotentes y añadir un servicio externo de colas. Diecinueve horas de refactor que no estaban en ningún presupuesto.
Creíamos que el sobrecoste de las plataformas gestionadas era una prima de comodidad que pagas y punto. Después de medir esto entendimos otra cosa: parte del sobrecoste llega en forma de horas de reingeniería para encajar tu arquitectura en el modelo de ejecución de la plataforma. Cambiamos la forma de presupuestar migraciones a raíz de ese refactor.
Dónde viven los datos y por qué eso también factura
Seis ubicaciones de datacenter frente a dieciocho. Sobre el papel gana la segunda opción, y para latencia global es verdad. Para un producto B2B europeo, la ecuación se invierte: cada región extra es una casilla más que rellenar en el anexo de subencargados del DPA, y hemos visto departamentos de compras de clientes grandes bloquear una firma seis semanas por eso. Valoramos ese retraso en el proyecto de un cliente en octubre: 4.200 € de facturación diferida. No aparece en ninguna calculadora de pricing.
Tabla comparativa por partidas (perfil B, 10.000 activos mensuales)
| Partida | Servidor dedicado | Plataforma gestionada |
|---|---|---|
| Cómputo | 73,01 € | 126,00 € |
| Base de datos | incluida en el hierro | 61,30 € |
| Salida de datos (900 GB) | 0,00 € | 43,10 € |
| Object storage + backups | 9,75 € | 15,80 € |
| CDN / WAF | 18,40 € | incluido |
| Observabilidad | 0,00 € (autogestionada) | 16,60 € |
| Subtotal infraestructura | 101,16 €/mes | 262,80 €/mes |
| Horas de operación [medido] | 6,9 h/mes | 1,1 h/mes |
| Coste de esas horas a 55 €/h | 379,50 € | 60,50 € |
| Total mensual cargado | 480,66 € | 323,30 € |
| Acumulado a 24 meses | 11.535,84 € | 7.759,20 € |
Sí, has leído bien. En el perfil sano, cargando las horas a precio de mercado, el hierro pierde. Guárdate ese dato para la sección del punto de cambio, porque es contraintuitivo y es el hallazgo más incómodo del experimento.
Qué ocurrió cuando el tráfico se multiplicó por cinco en un solo día
Simulamos un lunes de portada en agregadores: 5x la carga del perfil B durante 26 horas, con caída progresiva los tres días siguientes. Este es el escenario que los hilos virales usan como argumento definitivo, y el resultado nos dio una respuesta a medias.
La máquina dedicada aguantó sin tocar nada. CPU al 71% en el peor minuto, p95 de respuesta subiendo de 180 ms a 340 ms, cero errores 5xx. Coste marginal del pico: 0,00 €, porque el hierro ya estaba pagado y la salida de datos no se factura por volumen en ese contrato. La plataforma gestionada absorbió el pico con más elegancia (p95 estable en 210 ms, escalado automático, ni un aviso), y añadió 218 € al recibo de aquel mes.
Ahora, el multiplicador viral. Circula por X una afirmación de fuente única, no verificable, según la cual un sitio con más de 100 TB/mes cuesta menos de 50 $ con servidor propio más Cloudflare frente a unos 40.000 $/mes en plataforma gestionada: unas 800 veces más. Enfrente hay comparativas rigurosas que miden el diferencial en 40x, calculado exclusivamente sobre coste por vCPU. Esas dos cifras no son comparables ni describen el mismo fenómeno.
El 40x mide cómputo. El 800x mide ancho de banda. En base a nuestras mediciones, el diferencial real se comporta así: mientras el egress mensual se mantiene por debajo de 1 TB, la brecha oscila entre 2x y 3x en el importe total y desaparece al cargar las horas. Superados los 10 TB/mes, la brecha se dispara por encima de 12x y ninguna cantidad de horas de ingeniería la compensa. En el perfil C, el hierro salió a 281 €/mes contra 3.640 €. Ahí sí, el hilo viral tiene razón, y solo ahí.
El coste que no aparece en ninguna comparativa: tu tiempo de ingeniería
¿Cuánto tiempo de mantenimiento exige un servidor propio al mes? Medimos 6,9 horas mensuales de media en el perfil sano, frente a 1,1 horas del entorno gestionado. A 55 €/hora de coste interno para un senior en España, esa diferencia de 5,8 horas equivale a 319 €/mes: más del triple de lo que ahorras en la línea de infraestructura.
Vamos, que la comparativa de precios de catálogo es un ejercicio de contabilidad creativa si no metes esta columna. Y la mayoría de artículos la mencionan como abstracción («requiere mantenimiento») sin poner un número, lo cual es exactamente igual de útil que no mencionarla.
El umbral de dolor operativo
Establecimos tres franjas a partir de los registros de las incidencias, y son mucho más accionables que cualquier lista de recomendaciones genéricas:
- Menos de 3 h/mes: zona cómoda, el ahorro es real y limpio.
- Entre 3 y 8 h/mes: zona gris, depende de tu coste/hora y de si esas horas son nocturnas.
- Más de 8 h/mes: estás pagando el ahorro con producto no construido.
Existe además un dato de la industria que explica por qué el modelo gestionado ni siquiera es irracional: el punto de equilibrio de la elasticidad en contenedores gestionados ronda el 7% de utilización. Si tu app está ociosa el 93% del tiempo, pagar por consumo tiene sentido matemático. El problema surge cuando tu utilización media es del 40% y sigues pagando tarifa de elasticidad que no usas.
Y una limitación honesta de nuestra medición
Nuestras 6,9 h/mes las produjo un equipo que ya sabía usar Kamal, Postgres y systemd. Para un equipo sin ese músculo, las primeras seis semanas son otro deporte: en dos casos que acompañamos, el arranque consumió entre 22 y 31 horas antes de estabilizarse. Si tu equipo viene de desplegar con un git push y nada más, multiplica nuestras cifras por tres durante el primer trimestre y sé sincero al presupuestarlo. Hay quien ha documentado seis meses en máquina propia y una vuelta atrás posterior, y los factores decisivos no fueron el precio, sino el uptime y la carga operativa.
Cuánto cuesta salir: la factura oculta de cambiar de plataforma
Nadie cuantifica esto, así que lo cronometramos en las dos direcciones con la app del experimento. Salir del entorno gestionado hacia hierro: 31 horas, repartidas en 19 de refactor de la cola de trabajos, 6 de reescritura de middleware que dependía del edge runtime, 4 de pipeline de despliegue y 2 de DNS y certificados. A 55 €/h son 1.705 € de coste de salida.
La dirección contraria salió más barata de lo que esperábamos: 11 horas, unos 605 €, porque una app dockerizada correctamente entra en casi cualquier sitio. Ahí está la asimetría que conviene entender antes de firmar nada: el lock-in no lo genera el proveedor, lo genera tu decisión de usar sus primitivas propietarias. Cada función edge exclusiva, cada helper de imágenes atado a la plataforma, cada cron propietario es un ladrillo más en el muro de salida.
Antes de tomar la decisión merece la pena entender el orden correcto de las palancas, porque el proveedor suele ser la última y no la primera: en el trabajo que hacemos para reducir tu factura cloud el primer recorte casi nunca viene de mudarse de casa, sino de arreglar tres consultas sin índice y una caché mal configurada. Con frecuencia el ahorro por optimización supera al ahorro por migración, y no tiene coste de salida ninguno.
Dónde está el punto de cambio y qué decidir según tu escenario
El punto de cambio no está en un número de usuarios: está en 2,5 TB de tráfico de salida mensual. Por debajo de ese umbral, la diferencia de importe cargado con horas se queda en menos de 200 €/mes y rara vez justifica la mudanza. Por encima de 10 TB/mes, el diferencial supera 12x y la decisión se vuelve aritmética.
Tres umbrales concretos, sin listas de «elige X cuando»:
- Por debajo de 1 TB/mes de salida y menos de 3 h/mes disponibles para operar: el gestionado sale más barato en total cargado. Nuestro perfil B lo demuestra: 7.759 € contra 11.535 € a 24 meses.
- Entre 1 y 10 TB/mes: zona de la arquitectura híbrida, y es la que menos gente calcula. Object storage y assets pesados en un bucket con CDN propia delante, aplicación en la plataforma gestionada. En el perfil C esto bajó el importe gestionado de 3.640 € a 611 €/mes, con 14 horas de trabajo inicial y 1,6 h/mes de operación añadida. Tercera vía, no falso binario.
- Por encima de 10 TB/mes de egress o con carga sostenida sobre el 40% de utilización: el hierro gana con margen amplio. Un dedicado de 192 hilos y 96 núcleos por unos 500 $/mes fijos hace un trabajo que en tarifa gestionada por vCPU no cabe en el presupuesto de nadie.
¿Merece la pena self-hostear en lugar de usar una plataforma gestionada? Merece la pena si tu egress supera los 2,5 TB/mes, si tienes al menos una persona con soltura en Linux y si puedes absorber 7 horas mensuales de operación sin frenar la hoja de ruta. Si falla cualquiera de las tres condiciones, la respuesta honesta es que no.
Un último recordatorio antes de que abras tu hoja de cálculo: todas estas cifras son de diciembre de 2025, los modelos de facturación por CPU activa y las cuotas de tráfico incluidas cambian varias veces al año, y las nuestras salen de una app concreta con un patrón concreto. Coge la metodología, no los números. Si estás en el momento previo, cuando el problema todavía no es el importe mensual sino la arquitectura y lo que toca de verdad es escalar un MVP hecho con IA sin sobredimensionar nada, el orden correcto es medir tu salida de datos real durante 30 días y solo entonces mirar precios. Al revés se toman las decisiones caras.
