Por qué alojar su base de datos en su propio VPS
Autoalojar su base de datos en un VPS le da un control total sobre la versión del motor, los parámetros de tuning, el cifrado y la latencia de red hacia su aplicación. En lugar de sufrir los límites de conexiones y el sobrecoste de una base gestionada, usted coloca la base y la aplicación en la misma red privada: el trayecto de red sale de la ecuación, y lo que queda —la consulta, el índice, el volumen— se mide sobre su propia carga. PostgreSQL destaca en esquemas complejos, restricciones estrictas, JSONB indexable, consultas analíticas y extensiones (PostGIS, pg_trgm, búsqueda full-text). MySQL (o MariaDB) sigue siendo insuperable en simplicidad, muy bien soportado por los CMS y los frameworks PHP, con lecturas rápidas. La elección correcta depende de la naturaleza de sus datos, no de una preferencia de principio.
Lo que el autoalojamiento aporta a su base de datos
- Ningún salto por la red pública: la base en la misma red privada que la aplicación
- Control total del tuning:
shared_buffers,innodb_buffer_pool_size, conexiones máximas - Libertad de elección de la versión y del calendario de actualizaciones
- Copias de seguridad lógicas y físicas programadas según sus necesidades reales
- Replicación y lectura distribuida configuradas a su medida
- Cifrado en reposo y acceso restringido únicamente a la red interna del VPS
Requisitos para una base de datos en un VPS
Una base de datos de desarrollo o un sitio pequeño vive cómodamente con 1 vCPU y 1 GB de RAM. En producción, la regla de oro es dimensionar la RAM para que el índice de trabajo quepa en caché: apunte a entre 2 y 4 GB para PostgreSQL (shared_buffers en torno al 25% de la RAM) y a un innodb_buffer_pool_size que cubra su conjunto de datos activo en MySQL. Un disco SSD/NVMe no es negociable para las escrituras. Prevea Docker y Compose, un volumen persistente dedicado a los datos y, sobre todo: no exponga nunca a Internet el puerto de la base de datos. El acceso se hace a través de la red Docker interna o de un túnel SSH.
Desplegar PostgreSQL (o MySQL) en un VPS con Docker
Crear un volumen persistente
Defina un volumen con nombre
pgdata(omysqldata) en Compose. No almacene nunca los datos en la capa efímera del contenedor: undocker compose downno debe destruir su base de datos.Configurar el servicio y los secretos
Declare la imagen
postgres:16omysql:8, inyecte las credenciales mediante un archivo.env(nunca en claro en el compose) y vincule el puerto únicamente en local:127.0.0.1:5432:5432. La base de datos no debe ser accesible desde el exterior.Arrancar y comprobar
Ejecute
docker compose up -dy luego pruebe la conexión interna condocker compose exec db psql -U app -d maBase(omysql -u). Compruebe la codificación (UTF8/utf8mb4) desde la creación para evitar sorpresas.Aplicar el tuning
Monte un archivo de configuración personalizado para ajustar
shared_buffers,work_memymax_connections(PostgreSQL) oinnodb_buffer_pool_sizeymax_connections(MySQL) en función de la RAM real del VPS. Reinicie el servicio para aplicarlo.Implantar las copias de seguridad
Programe un dump periódico mediante cron:
pg_dumpomysqldumpcomprime y copia fuera del VPS. Pruebe la restauración: una copia de seguridad que nunca se ha restaurado no es una copia de seguridad.Asegurar el acceso de la aplicación
Haga que la aplicación y la base de datos se comuniquen únicamente a través de la red Docker interna. Para un acceso de administración remoto, use un túnel SSH en lugar de abrir el puerto. Cree un usuario de aplicación con derechos limitados, distinto del superusuario.
Desplace la tabla
| Criterio | PostgreSQL | MySQL / MariaDB |
|---|---|---|
| Modelo de datos | Rico: tipos personalizados, arrays, JSONB | Sólido, más clásico |
| Soporte de JSON | JSONB indexable y eficiente | JSON presente, indexación más limitada |
| Conformidad SQL / restricciones | Muy estricta (CHECK, tipos, transacciones DDL) | Más permisiva |
| Búsqueda full-text / geo | Nativa + PostGIS, pg_trgm | Básica, extensiones de terceros |
| Lecturas simples de alta frecuencia | Muy buenas | Excelentes, muy optimizadas |
| Replicación | Streaming, lógica | Maestro-esclavo, sencilla de implantar |
| Ecosistema CMS/PHP | Bueno | Referencia (WordPress, etc.) |
| Huella de memoria | Moderada | De ligera a moderada |
Sea cual sea el motor, no deje nunca que una aplicación web abra una conexión directa por cada consulta: en PostgreSQL, coloque PgBouncer como pooler y, en MySQL, ajuste max_connections con un pool del lado de la aplicación. Un VPS que se hunde bajo la carga casi siempre tiene un problema de conexiones sin pooling, más que una falta de potencia bruta.
