Base de datos en un VPS: PostgreSQL o MySQL
Una base de datos casi nunca se queda corta de procesador: lo que la limita es la memoria y el disco. Si el conjunto de datos de trabajo cabe en la caché, las consultas van rápidas incluso en un servidor económico; si no cabe, todo depende de la velocidad del disco. Veamos cómo elegir entre PostgreSQL y MySQL, cuánta memoria dar a la base de datos, qué disco contratar y cómo no perder datos.
En la mayoría de las webs y aplicaciones, el sistema de base de datos ya viene elegido: WordPress, 1C-Bitrix y casi todos los CMS en PHP están pensados para MySQL, y muchos proyectos en Django, Rails y Go usan PostgreSQL por defecto. Si tiene libertad para elegir, cualquiera de los dos aguantará una carga típica; la diferencia está en cuál le resulta más cómodo mantener y qué admite su stack.
PostgreSQL o MySQL
- MySQL y MariaDB son el estándar para los CMS y las tiendas online en PHP. Los admite cualquier panel de control y cualquier hosting compartido, hay más guías listas para usar y migrar una web del hosting a un VPS suele reducirse a un volcado y una importación.
- PostgreSQL es la opción para aplicaciones con consultas complejas, informes e integridad de datos estricta. Ofrece más tipos de datos (JSONB, arrays, rangos) y admite extensiones como PostGIS para datos geográficos y pgvector para búsqueda vectorial.
Si el proyecto es nuevo y el motor no impone el sistema de base de datos, elija el que conozca su equipo: en un servidor con 4 a 8 GB de memoria, la diferencia de velocidad entre ambos es menor que la diferencia entre una base de datos bien configurada y otra mal configurada. Cambiar de sistema en un proyecto en marcha es caro, así que la decisión se toma una sola vez.
Cuánta memoria dar a la base de datos
Ambos sistemas guardan los datos de uso frecuente en su propia caché, y su tamaño es el ajuste más importante tras la instalación. Por defecto es pequeña, 128 MB en los dos, así que sin configurarla la base de datos apenas aprovecha un servidor con 8 GB de memoria.
- PostgreSQL: según la documentación, en un servidor dedicado a la base de datos con 1 GB de memoria o más, un valor inicial razonable para
shared_bufferses el 25% de la memoria. Asignar más del 40% difícilmente ayuda, porque PostgreSQL también se apoya en la caché de archivos del sistema operativo. - MySQL (InnoDB): según la documentación de MySQL 8.4, en servidores dedicados se suele destinar al búfer
innodb_buffer_pool_sizehasta el 80% de la memoria física.
La palabra clave en ambos casos es «dedicado». Si en el mismo VPS funcionan el servidor web, PHP-FPM, Redis y las colas, a la base de datos le queda menos: en un servidor de 4 GB que también aloja la web, lo razonable es dar al búfer de MySQL entre 1 y 1,5 GB, no 3. El resto lo necesitan los procesos de la aplicación y un margen de reserva; de lo contrario, el servidor empezará a usar swap y la base de datos irá más lenta que con una caché pequeña.
La referencia para dimensionar el servidor es el volumen de datos «calientes»: las tablas y los índices que se consultan constantemente. Si caben enteros en la caché, la mayoría de las lecturas no llegan al disco. Según el catálogo de accsly.io a noviembre de 2026, la mediana del precio de un VPS con 4 GB de memoria es de unos 22 USD (unos 20 EUR) al mes; con 8 GB, unos 41 USD (unos 36 EUR); con 16 GB, unos 74 USD (unos 66 EUR), y con 32 GB, unos 134 USD (unos 119 EUR). Los importes están convertidos de rublos al tipo del 7 de noviembre de 2026 y redondeados. Cómo elegir memoria y núcleos se explica en el artículo Cuánta memoria y cuántos núcleos necesita una web; los planes con 16 GB o más están en la página VPS con 16 GB de RAM.
Disco e IOPS
Cuando los datos no caben en memoria, y también en cada escritura, la base de datos accede al disco con operaciones pequeñas y aleatorias. Aquí no importan la capacidad ni la velocidad secuencial que anuncia el plan, sino el número de operaciones de entrada y salida por segundo (IOPS) y la latencia. NVMe supera a los SSD SATA precisamente en estas operaciones, y un disco duro no sirve en absoluto para una base de datos en producción: ofrece cientos de operaciones por segundo donde un SSD da decenas de miles.
Según el catálogo de accsly.io a noviembre de 2026, el 41% de los 29 603 planes VPS indica NVMe, y en los planes grandes la proporción es mayor: el 38% en los planes con 2 GB de memoria y el 45% en los de 32 GB. La comparación de discos está en el artículo NVMe o SSD: ¿hay diferencia para una web?, y la selección de planes, en VPS con NVMe.
Las cifras que anuncia un plan VPS son un límite superior: el disco se comparte con los vecinos del servidor físico, y muchos proveedores limitan las IOPS por máquina virtual. La velocidad real se comprueba tras la compra con la utilidad fio, con una prueba de lectura y escritura aleatorias en bloques de 4 a 16 KB, mientras todavía pueda devolver el servidor. Cómo hacerlo durante el periodo de prueba se explica en el artículo Cómo probar el ping y la velocidad de un VPS antes de pagar.
Copias de seguridad y réplicas
Una instantánea del disco en el proveedor es una copia cómoda, pero no la más fiable para una base de datos: si se toma durante una escritura, puede requerir una recuperación tras fallo, y normalmente se guarda en el mismo proveedor. Para la base de datos se hacen copias propias con las herramientas del sistema:
- Volcado lógico:
pg_dumppara PostgreSQL omysqldumppara MySQL. En las tablas InnoDB, el volcado se hace con la opción--single-transaction; así, como indica la documentación de mysqldump, resulta coherente sin bloquear las tablas. Sirve para bases de datos de hasta decenas de gigabytes; restaurar una base grande desde un volcado puede llevar horas. - Recuperación a un momento concreto: una copia completa de los archivos de la base de datos más un archivo continuo del registro de cambios. En PostgreSQL es el archivado de WAL, y en MySQL, el registro binario. Así se puede volver al minuto anterior a un
DELETEerróneo, y no a la noche anterior.
Las copias se guardan fuera del servidor de la base de datos, en un almacenamiento de objetos o en un VPS aparte en otro centro de datos, y se comprueban con restauraciones periódicas. Las reglas generales de las copias de seguridad están en el artículo Copias de seguridad de un VPS: estrategias y herramientas, y los almacenamientos para guardarlas, en el artículo Almacenamiento de archivos en un VPS: discos y almacenamiento de objetos.
Una réplica es una segunda copia de la base de datos en otro servidor que recibe los cambios casi al instante: replicación en streaming en PostgreSQL, replicación en MySQL. Permite cambiar rápidamente de servidor si falla el principal y aliviarlo enviando los informes a la réplica. Pero no sustituye a la copia de seguridad: una tabla borrada por error desaparecerá también de la réplica en fracciones de segundo.
Base de datos gestionada o propia en un VPS
Los proveedores en la nube ofrecen bases de datos gestionadas: usted recibe una dirección de conexión, y la instalación, las actualizaciones, las copias de seguridad y las réplicas corren a cargo del proveedor. Por ejemplo, en Amazon RDS las copias de seguridad automáticas se conservan hasta 35 días, con posibilidad de restaurar a un momento concreto.
- Una base de datos gestionada compensa cuando en el equipo no hay nadie dispuesto a responsabilizarse de ella, cuando se necesita alta disponibilidad con conmutación automática o cuando una parada cuesta más que el sobreprecio. Inconvenientes: la misma memoria y el mismo disco cuestan bastante más que en un VPS, parte de los ajustes y extensiones no está disponible y cambiar de proveedor es más complicado.
- Una base de datos propia en un VPS es más barata y da control total sobre la versión, los ajustes y las extensiones. A cambio, las actualizaciones, las copias de seguridad, la vigilancia del espacio en disco y la comprobación de las restauraciones son trabajo suyo. La diferencia entre ambos enfoques se analiza en el artículo Servidor en la nube o VPS.
Un término medio habitual en un proyecto pequeño es tener la base de datos en el mismo VPS que la web, con un volcado diario y el archivo del registro en un almacenamiento aparte. Cuando la base de datos crece hasta varios gigabytes de datos «calientes» o empieza a estorbar a la aplicación, se lleva a un servidor propio con NVMe y su puerto se cierra al exterior, dejando acceso solo desde las direcciones de la aplicación. Los planes para un servidor así están en las páginas VPS para PostgreSQL, VPS para MySQL y VPS para bases de datos. Conviene añadir desde el principio el espacio en disco y la latencia de las consultas a la monitorización: un disco lleno es la causa más frecuente de que una base de datos se detenga.