La elección entre MySQL y PostgreSQL no debería depender solo de la RAM, pero en ambos casos conviene planificar el memory budget antes de producción. Un error habitual es asignar casi toda la memoria a la base de datos y olvidar el sistema operativo, los web workers, las conexiones y los procesos de mantenimiento.
Empecemos con un presupuesto limpio de 8 GB
Los 8 GB completos no pertenecen a la database. Primero reserva headroom para el OS y los system services, después cuenta los application processes y solo entonces dimensiona cache, buffers y connection-related memory.
MySQL - el buffer pool importa, pero no está solo
El InnoDB buffer pool suele ser uno de los principales consumidores de memoria. Su tamaño depende de si MySQL vive en un VPS dedicado o comparte la VM con el web stack. Subir `max_connections` no crea capacidad adicional.
PostgreSQL - shared_buffers es solo una parte
Hay que considerar `shared_buffers`, connection count, operation memory y el page cache del sistema operativo de forma conjunta. `work_mem` requiere especial cuidado porque una query compleja puede ejecutar varias operaciones sort/hash.
Memory-planning worksheet
| Pregunta | Por qué importa |
|---|---|
| ¿DB en un VPS dedicado? | puede asignarse más RAM a la base |
| ¿Cuántas active connections? | connection overhead |
| ¿Qué tamaño tiene el dataset? | cache strategy |
| ¿Qué tipo de queries? | OLTP y analytics son diferentes |
| ¿Cuándo se ejecutan los backups? | competencia de recursos en peak |
la guía para elegir un servidor de base de datos amplía el sizing. Si utilizas Laravel, la guía de hosting para Laravel ayuda a entender la relación entre application y DB layers.
¿Qué base de datos elegir?
Si la aplicación y el equipo ya dependen de una base concreta, migrar solo porque otra se considera “más rápida” rara vez es suficiente razón. Evalúa features, tooling, query patterns y experiencia operativa.
Para control completo de database administration, VPS no administrado es flexible. Para comparar recursos revisa SERVER1 VPS. Antes de cambiar producción, prueba carga representativa y valida backup/restore.
Un DB VPS dedicado y un VPS compartido web+DB no deben ajustarse igual
Cuando la database tiene su propio VPS, una parte mayor de la RAM puede dedicarse a caching porque PHP, Node y el web server ya no compiten en la misma VM. En un servidor compartido, el mismo ajuste agresivo puede provocar swap. Por eso no conviene aplicar reglas genéricas del tipo “asigna X% de RAM a la base de datos” sin contexto.
Las connections suelen infravalorarse en memory planning
Configurar 100 connections no significa que necesites 100 queries activas constantemente. En algunas aplicaciones, connection pooling o un proxy permite atender muchas requests con menos sesiones reales de base de datos. Mide active connections, transaction duration y waiting states antes de subir límites.
Cada workload necesita métricas distintas
| Workload | Qué conviene medir especialmente |
|---|---|
| Transactional web app | latency, locks, indexes, active connections |
| WooCommerce / CMS | query count, slow queries, object cache, concurrency |
| Reporting / analytics | large scans, temporary memory, I/O, execution plans |
| Background imports | write bursts, lock time, redo/WAL growth |
La trampa del benchmark “MySQL vs PostgreSQL”
Usar la misma schema y query no siempre produce una comparación justa: optimizer, indexes, data types y patrones habituales son diferentes. Si la migración es una posibilidad real, prueba un workload representativo de producción.
Monitoring baseline antes del tuning
- CPU y disk latency;
- active/waiting connections;
- cache-hit behavior;
- distribución de slow queries;
- locks/deadlocks;
- duración de backups e impacto del mantenimiento.
La base de datos correcta no es la más popular, sino la que encaja con tus feature requirements, query patterns y el equipo que tendrá que operarla.
