Cómo elegir una VPS para tu servidor

Antes de mirar planes, mide lo que vas a poner encima

El error más común es empezar por la lista de planes y elegir por precio. La pregunta útil va antes: ¿qué va a hacer esta máquina y cuánta gente la va a usar a la vez? Un sitio informativo que recibe visitas sueltas a lo largo del día no tiene nada que ver con un servicio que acepta subidas de archivos o que consulta una base de datos en cada clic.

Vale con una estimación tosca. Cuenta los usuarios simultáneos en hora punta —no el total del mes—, si el trabajo es sobre todo leer o sobre todo escribir, y si hay momentos concretos que concentran la carga: un envío masivo de correos, el cierre de mes, el día de una promoción. Y si ya tienes algo funcionando, mira el consumo real de las últimas semanas antes de suponer nada; casi siempre sorprende, en un sentido o en otro. Con esas cuatro respuestas encima de la mesa, la elección deja de ser una apuesta.

Memoria: casi siempre lo primero que se queda corto

La memoria suele ser lo primero que aprieta. Reserva 1–2 GB para el sistema operativo y sus tareas de fondo, y dedica el resto al servicio. Mientras la memoria sobra, todo va fino; en cuanto falta, el sistema empieza a tirar de swap —memoria simulada sobre el disco, que es órdenes de magnitud más lenta— y el servidor entero se arrastra aunque la CPU esté ociosa. Ese es el síntoma clásico de un servidor mal dimensionado: no se calienta, se atasca.

El caso más claro es una base de datos. Si el conjunto de datos con el que trabaja cabe en memoria, las consultas vuelan porque se responden sin tocar el disco; cuando deja de caber, cada consulta pasa a leer de disco y la diferencia se nota de inmediato. Por eso conviene dar aire de sobra a lo que se cachea en memoria. Pasarse tampoco es gratis: pagar por 32 GB para usar 6 es dinero que se va cada mes sin mejorar nada.

CPU: cuenta los núcleos, pero sobre todo cómo se usan

Con la CPU importan dos cosas distintas: cuántos núcleos hay y cómo de rápido es cada uno. Muchas peticiones cortas y ligeras se reparten bien entre varios núcleos, así que ahí sumar núcleos sí ayuda. En cambio, una tarea pesada y secuencial —generar un informe grande, comprimir un volcado, un cálculo que no se puede trocear— depende de lo rápido que sea un núcleo, y añadir más no la acelera ni un poco.

Hay letra pequeña en las «vCPU»: en muchos planes son núcleos compartidos con otros inquilinos de la misma máquina física. Si un vecino se pone a consumir a tope, tu servicio nota el tirón —es lo que se llama steal time, tiempo de CPU que te tocaba y se lo lleva otro. Para cargas sensibles al retardo conviene mirar si el proveedor ofrece núcleos dedicados o garantizados, y no quedarse solo con el número a secas.

Disco: tipo, velocidad y lo que crece sin avisar

Del disco casi nadie mira el tipo, y es lo que más cambia la experiencia. Un disco de estado sólido (SSD, y mejor todavía si es NVMe) responde muchísimo mejor que uno mecánico cuando hay muchas lecturas y escrituras pequeñas —justo lo que hace una base de datos durante todo el día. Y no es solo velocidad de transferencia: son las operaciones por segundo (IOPS), que es donde un disco lento asfixia sin que el gráfico de CPU muestre nada raro.

El tamaño hay que contarlo mirando adelante, no a hoy. Suma el crecimiento de los datos, los registros (logs) que se acumulan día tras día y, sobre todo, las copias de seguridad si guardas alguna en la propia máquina. Un descuido habitual: registros sin rotar que llenan el disco hasta el 100 % y tumban el servicio —no por falta de potencia, sino porque ya no queda un byte libre donde escribir. Deja siempre un margen holgado; el disco lleno del todo es de los fallos más tontos y más evitables que existen.

Traducir todo eso en un punto de partida

Con la carga estimada y estas tres piezas en la cabeza, ya se puede aterrizar en una talla concreta. La tabla de abajo son órdenes de magnitud por tipo de proyecto: sirven para no pagar de más ni quedarse corto de salida, no como catálogo cerrado. Un proyecto real puede pedir más de una fila a la vez, o quedarse justo entre dos; tómalo como un empujón, no como una regla.

La columna de «margen» es la que más se olvida. Dejar sitio para una copia local, dimensionar para el pico en lugar de para la media, o poder subir de plan sin reinstalarlo todo: eso es lo que separa un servidor que aguanta de uno que va justo desde el primer día.

Red: ancho de banda, IP y estar cerca de quien te visita

La red se resume en unos pocos puntos que conviene comprobar antes de contratar, no después:

• Transferencia incluida. Algunos planes miden el tráfico mensual y cobran de más o estrangulan la velocidad al pasarse. Si el servicio mueve archivos o vídeo, lee ese límite con lupa.
• IP y puertos. Comprueba que puedes abrir los puertos que necesitas y, si el servicio lo pide, que la IP es propia y no compartida con desconocidos.
• Protección ante ataques. Un mínimo de mitigación anti-DDoS de serie evita que una avalancha tonta te deje fuera de juego un rato.
• Cercanía. Cuanto más lejos esté el centro de datos de quien te visita, más tarda cada petición en ir y volver. Para un público local, elegir una región cercana rebaja la latencia sin gastar un céntimo de más.

El sistema operativo, tu acceso y la letra pequeña del proveedor

Para tener control real hace falta acceso de administrador (root) sobre una distribución estable y con soporte largo. Con ese acceso se montan el cortafuegos, los servicios en segundo plano, las tareas programadas (cron) y el endurecimiento de seguridad; sin él, media configuración se queda fuera de tu alcance y dependes del proveedor para cualquier cosa.

Dos confusiones que salen caras. La primera: una instantánea (snapshot) no es una copia de seguridad. Vive en la misma infraestructura y te salva de un cambio torpe, no de que el proveedor tenga un mal día. La segunda es el escalado: mira antes de entrar si puedes subir de plan sin reinstalar y con una parada corta, porque el día que haga falta más músculo no querrás empezar de cero.

Desconfía de la letra pequeña. «Hasta X GB», recursos «compartidos» donde esperabas garantizados, o un soporte que tarda días en responder son cosas que no salen en la tabla de precios y se pagan justo cuando algo va mal.