Hosting compartido vs VPS vs dedicado: cuál necesita tu empresa

Qué es exactamente cada tipo de alojamiento

Los tres modelos alojan sitios web, pero reparten el mismo hardware de formas distintas. Estas son las definiciones que usaremos durante todo el artículo:

Hosting compartido: un servidor físico ejecuta cientos de sitios web a la vez. Cada cuenta recibe un espacio en disco y un límite de recursos (CPU, RAM, procesos simultáneos), pero el sistema operativo, el servidor web y las actualizaciones de seguridad los administra el proveedor. Tú entras por un panel de control —normalmente cPanel— y gestionas dominios, correos y bases de datos sin tocar la línea de comandos.

VPS (Virtual Private Server, servidor privado virtual): un servidor físico se divide mediante virtualización en varias máquinas independientes. Cada VPS tiene su propio sistema operativo, su propia dirección IP y una porción garantizada de CPU, RAM y disco que ningún otro cliente puede consumir. Recibes acceso root (el usuario con permisos totales del sistema) e instalas lo que quieras. También asumes su mantenimiento.

Servidor dedicado: una máquina física completa asignada a un solo cliente. No hay vecinos ni capa de virtualización entre tu software y el hardware. Todo el procesador, toda la memoria y todos los discos son tuyos, junto con toda la responsabilidad de administrarlos.

Una analogía útil: el hosting compartido es un departamento en un edificio con administrador; el VPS es una casa en un condominio, donde el terreno es tuyo pero compartes la infraestructura del conjunto; el dedicado es un lote entero a tu nombre. Ninguno es mejor en abstracto. Depende de cuánta gente vive ahí y de si quieres ocuparte del jardín.

La diferencia entre hosting, VPS y dedicado, en una tabla

Esta es la comparación directa de los tres modelos, con los valores reales de los planes de Terranode:

Un detalle que la tabla deja claro y que conviene subrayar: la columna que más cambia entre modelos no es la de precio, es la de quién administra el sistema. Ese es el costo oculto de subir de escalón.

Cuándo el hosting compartido es la opción correcta

El hosting compartido es la elección correcta para la mayoría de sitios web de empresas pequeñas y medianas, y decir lo contrario sería venderte algo que no necesitas. Si tu sitio es un WordPress corporativo, un blog, un portafolio, una landing page o una tienda con menos de 300 pedidos al mes, un plan compartido bien construido te va a servir mejor que un VPS: cuesta menos, no requiere administración y el proveedor aplica los parches de seguridad por ti.

Un ejemplo concreto: un estudio contable de 8 empleados con un sitio informativo, un blog que publica dos artículos al mes y seis cuentas de correo recibe quizá 40 visitas diarias. Ese sitio consume una fracción mínima de un servidor. Ponerlo en un VPS de $20 mensuales no lo hace más rápido; lo hace más caro y añade un servidor Linux que alguien debe mantener actualizado. Con un plan compartido de $40 al año, el estudio paga menos de lo que cuesta un almuerzo al mes y no tiene que preocuparse por parches del kernel.

La calidad de un hosting compartido depende de tres cosas técnicas concretas, no del marketing:

• CloudLinux: una capa que encierra cada cuenta en un contenedor con límites propios de CPU, RAM y procesos. Sin ella, un solo sitio mal programado puede consumir todo el servidor y ralentizar a los demás vecinos. Con ella, ese sitio se ralentiza a sí mismo y nadie más lo nota.
• LiteSpeed: un servidor web que reemplaza a Apache y que, con su módulo de caché para WordPress, sirve páginas ya generadas sin volver a ejecutar PHP en cada visita.
• Discos NVMe: almacenamiento de estado sólido conectado directo al bus PCIe, con tiempos de acceso muy por debajo de los discos SATA tradicionales. En un sitio con base de datos —cualquier WordPress lo es— el disco suele ser el cuello de botella real.

En nuestros planes de hosting esos tres componentes vienen de serie, junto con cPanel y certificados SSL gratuitos.

Cuándo conviene dar el salto a un VPS

Se pasa a un VPS por límites, no por prestigio. Hay cuatro razones legítimas para migrar, y ninguna de ellas es "quiero algo más profesional":

1. 1 Chocas contra los límites de recursos del plan compartido. La señal típica es el error HTTP 508 (Resource Limit Is Reached) o una lentitud que aparece siempre a la misma hora, cuando tu tráfico sube. Si tu tienda recibe 500 visitas al día y 40 pedidos, y el checkout se arrastra los viernes por la tarde, ya no es un problema de optimización: es un problema de techo.
2. 2 Necesitas software que el hosting compartido no permite. Node.js con una versión específica, Docker, Redis como caché de objetos, un worker de colas corriendo permanentemente, Python con dependencias compiladas, o un servicio propio escuchando en un puerto no estándar. Nada de eso cabe en un panel compartido, por buenos que sean sus recursos.
3. 3 Corres una aplicación a medida, no un CMS. Un sistema de facturación en Laravel, un ERP interno, una API que alimenta tu app móvil. Estas aplicaciones necesitan tareas programadas, permisos de archivos particulares y a menudo despliegue por Git.
4. 4 Necesitas aislamiento por política interna o por un cliente. Algunos contratos exigen que los datos no compartan sistema operativo con terceros. Un VPS resuelve ese requisito; un plan compartido no.

El punto de partida en nuestros VPS es de $2,99 mensuales por 1 GB de RAM y la escala llega hasta $155 mensuales por 64 GB. Ese rango cubre desde un entorno de pruebas hasta una aplicación de producción con varias decenas de miles de usuarios. Un consejo práctico: empieza pequeño. Un VPS se redimensiona en minutos, y es mucho más barato subir de plan cuando hace falta que pagar durante un año una capacidad que nunca usaste.

Cuándo se justifica realmente un servidor dedicado

Un servidor dedicado se justifica cuando la carga es sostenida, no cuando es alta en picos. Esa distinción ahorra mucho dinero. Un pico de tráfico —una campaña, una salida en prensa, un Black Friday— se absorbe mejor ampliando un VPS temporalmente. Una carga sostenida —una base de datos de 200 GB consultada todo el día, un servidor de video, un sistema con miles de sesiones concurrentes de lunes a domingo— es lo que amortiza una máquina física completa.

Los tres escenarios donde un dedicado es la respuesta correcta:

• Bases de datos grandes con escritura intensiva. MySQL o PostgreSQL con decenas de gigabytes de datos calientes rinden mejor cuando toda la RAM física es suya y no hay capa de virtualización entre el motor y el disco NVMe.
• Cumplimiento normativo o contractual estricto. Cuando un contrato exige hardware no compartido de forma explícita, no hay VPS que valga: hace falta la máquina.
• Uso continuo de CPU. Renderizado, procesamiento de video, transcodificación, análisis de datos, entrenamiento de modelos. Los VPS están diseñados asumiendo que ningún cliente usa el 100 % de su CPU todo el tiempo; si tu carga sí lo hace, el dedicado es más honesto y más económico por unidad de cómputo.

Nuestros servidores dedicados parten de $120 mensuales. Antes de contratar uno, vale la pena revisar el gasto real: si tu VPS actual usa menos del 60 % de su CPU en promedio semanal, el dedicado no va a resolver ningún problema que no se resuelva optimizando consultas a la base de datos.

Cinco señales medibles de que tu plan actual se quedó corto

No hay que adivinar el momento de migrar: hay indicadores que se pueden mirar hoy mismo en tu panel de control o en Google Search Console.

1. 1 Errores 508 o 503 en los logs. Significan que la cuenta agotó su límite de recursos o que el servidor rechazó la petición. Uno aislado no es nada; varios por semana son un techo.
2. 2 LCP por encima de 2,5 segundos. El Largest Contentful Paint mide cuánto tarda en dibujarse el elemento visible más grande de la página. Google establece 2,5 segundos como el umbral de una buena experiencia, medido en el percentil 75 de las visitas (Core Web Vitals explicadas). Si tu sitio está en 4 segundos y ya optimizaste imágenes y caché, el servidor es el siguiente sospechoso.
3. 3 La lentitud tiene horario. Si el sitio va bien a las 3 de la mañana y mal a las 11 de la mañana, el problema es de capacidad, no de código.
4. 4 Necesitaste rechazar una integración. Si alguna vez respondiste "no se puede instalar eso en nuestro hosting", ya sabes qué te falta.
5. 5 El backup ya no cabe. Cuando la copia de seguridad completa supera el espacio del plan, normalmente el sitio también superó el plan.

Lo que cambiar de plan no va a arreglar

Esta es la parte que casi ningún proveedor pone por escrito, y es la más útil: migrar a un servidor más grande no arregla un sitio mal hecho. Si tu WordPress tiene 45 plugins activos, imágenes de 4 MB sin comprimir y una plantilla que carga seis fuentes distintas, ese sitio va a ir lento en un plan compartido, en un VPS de 16 GB y en un dedicado de $400 mensuales. Solo cambia cuánto pagas por la lentitud.

Antes de subir de escalón, verifica estas cuatro cosas, porque son gratis y suelen resolver el 70 % de los casos que llegan a soporte como "necesito un servidor más potente":

• Caché de página activa. Un WordPress sin caché ejecuta PHP y consulta la base de datos en cada visita, incluso para una página que no cambió en tres meses.
• Imágenes en formato WebP y con tamaño real. Una foto de portada no necesita 3.000 píxeles de ancho para mostrarse en un contenedor de 800.
• Plugins desactivados y eliminados. Cada plugin activo añade consultas y scripts. Los que no usas no deberían estar instalados.
• Base de datos limpia. Revisiones de entradas, transients caducados y tablas huérfanas de plugins desinstalados pesan más de lo que parece.

Si después de eso el sitio sigue al límite, entonces sí: el problema es el plan, y migrar tiene sentido.

Cómo migrar sin que se caiga el sitio ni se pierda el correo

Una migración bien hecha es invisible para los visitantes. El orden importa y siempre es el mismo:

1. 1 Copiar antes de apuntar. Se replica el sitio completo, la base de datos y las cuentas de correo en el servidor nuevo, mientras el viejo sigue atendiendo el tráfico con normalidad.
2. 2 Probar con el archivo hosts. Se edita el archivo hosts del computador para que solo tu máquina resuelva el dominio hacia la IP nueva. Así navegas el sitio migrado con su dominio real mientras el resto del mundo sigue viendo el original.
3. 3 Bajar el TTL del DNS con 24 horas de anticipación. El TTL (Time To Live) es el tiempo que los servidores DNS del mundo guardan en caché la dirección de tu dominio. Bajarlo a 300 segundos antes del cambio hace que la propagación tarde minutos en lugar de horas.
4. 4 Cambiar los registros DNS y mantener el servidor viejo activo 72 horas. Durante la propagación, algunos visitantes llegan al servidor antiguo. Si lo apagas de inmediato, esos visitantes ven un error; si lo dejas encendido, no notan nada. Los correos que lleguen al servidor viejo se reenvían al nuevo.

En Terranode la migración la hace el equipo técnico sin costo, tanto desde otro proveedor como entre planes propios, y se coordina en el horario que menos afecte a tu operación.

Qué mirar del proveedor, más allá del tipo de plan

El tipo de alojamiento importa menos que la infraestructura donde corre. Un VPS sobre hardware revendido y saturado rinde peor que un hosting compartido sobre infraestructura propia bien dimensionada. Cuatro preguntas que conviene hacer antes de contratar cualquiera de los tres modelos:

• ¿La infraestructura es propia o es reventa? Un revendedor no puede resolver un problema de hardware ni de red: solo abre un ticket a su proveedor y espera, igual que tú. Terranode opera infraestructura propia en Guayaquil y en cuatro ubicaciones de Estados Unidos —Houston, Ashburn, Los Ángeles y Chicago—, lo que permite elegir la más cercana a tu público.
• ¿Cuál es la capacidad de red y hay límite de transferencia? Nuestros puertos son de 10 Gbps sin límite de transferencia, de modo que un mes de tráfico alto no genera un cargo extra ni un corte de servicio.
• ¿Hay mitigación de DDoS y de qué capacidad? Un ataque de denegación de servicio distribuido satura tu conexión con tráfico falso hasta dejar el sitio inaccesible. La mitigación filtra ese tráfico antes de que llegue al servidor. La nuestra absorbe hasta 160 Gbps.
• ¿En qué idioma y con qué horario responde el soporte? Cuando un servidor de producción falla un domingo a las 2 de la mañana, la diferencia entre un chat en español disponible 24/7 y un formulario en inglés con respuesta en 48 horas es la diferencia entre una hora de caída y un fin de semana perdido.