Cómo optimizar PostgreSQL y MariaDB en servidores Linux: guía práctica para mejorar rendimiento

Optimizar PostgreSQL y MariaDB en servidores Linux no significa cambiar parámetros al azar. El rendimiento real se consigue midiendo consultas, revisando índices, ajustando memoria, controlando el almacenamiento, manteniendo estadísticas actualizadas y monitoreando el comportamiento del sistema antes y después de cada cambio.

PostgreSQL y MariaDB pueden funcionar muy bien con configuraciones predeterminadas en entornos pequeños, pero las aplicaciones empresariales, tiendas en línea, sistemas de facturación, ERPs, CRMs, portales web y plataformas de analítica requieren una revisión más cuidadosa. PostgreSQL documenta herramientas como EXPLAIN, VACUUM, ANALYZE, pg_stat_statements y auto_explain; MariaDB documenta el slow query log, EXPLAIN, ANALYZE TABLE, estadísticas de índices e InnoDB Buffer Pool como piezas importantes del diagnóstico.

1. Empieza por una línea base del servidor Linux

Antes de tocar PostgreSQL o MariaDB, debes saber si el cuello de botella está en CPU, memoria, disco, red, bloqueo de consultas o diseño SQL. Un servidor puede parecer “lento” por falta de índices, pero también por I/O saturado, exceso de conexiones, swap, discos lentos o consultas bloqueadas.

hostnamectl
uptime
free -h
df -h
df -i
lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINTS
ss -lntp

top

Si el servidor utiliza discos mecánicos para cargas transaccionales pesadas, si la memoria está al límite o si la base de datos comparte recursos con demasiados servicios, ningún parámetro mágico resolverá el problema.

2. Diferencia los tipos de carga

Una base de datos de ventas no se optimiza igual que un sistema de reportes. Por eso la línea base debe incluir número de conexiones, consultas por segundo, tiempo promedio, consultas más costosas, uso de disco y crecimiento de tablas.

3. Optimización en PostgreSQL

3.1. Identifica las consultas más costosas con pg_stat_statements

PostgreSQL incluye la extensión pg_stat_statements, que permite registrar estadísticas de planificación y ejecución de las consultas ejecutadas por el servidor. Es una de las herramientas más útiles para saber qué consultas consumen más tiempo total, cuáles se ejecutan muchas veces y cuáles tienen peor promedio.

sudo -u postgres psql

ALTER SYSTEM SET shared_preload_libraries = 'pg_stat_statements';

-- Salir y reiniciar PostgreSQL desde Linux
\q

sudo systemctl restart postgresql

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT
calls,
round(total_exec_time::numeric, 2) AS total_ms,
round(mean_exec_time::numeric, 2) AS promedio_ms,
rows,
left(query, 120) AS consulta
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

3.2. Usa EXPLAIN y EXPLAIN ANALYZE

EXPLAIN muestra el plan que PostgreSQL usará para ejecutar una consulta. Cuando se usa EXPLAIN ANALYZE, la consulta se ejecuta realmente y se muestran tiempos reales, filas procesadas y diferencias frente a las estimaciones. PostgreSQL recomienda usar estos planes para entender cómo el optimizador decide leer tablas, usar índices y unir datos.

EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM ventas
WHERE cliente_id = 100
  AND fecha >= CURRENT_DATE - INTERVAL '30 days';

Si el plan muestra lecturas secuenciales sobre tablas grandes, muchas filas descartadas por filtros, ordenamientos en disco o diferencias enormes entre filas estimadas y filas reales, probablemente debes revisar índices, estadísticas, diseño de consulta o configuración de memoria.

3.3. Crea índices con criterio

Un índice puede acelerar lecturas, filtros, uniones y ordenamientos, pero también consume espacio y ralentiza escrituras. Por eso no se debe indexar cada columna. La decisión debe basarse en consultas reales, cardinalidad, filtros frecuentes, claves de unión y ordenamientos habituales.

CREATE INDEX CONCURRENTLY idx_ventas_cliente_fecha
ON ventas (cliente_id, fecha DESC);

3.4. Mantén VACUUM y ANALYZE bajo control

PostgreSQL usa VACUUM para limpiar filas muertas generadas por actualizaciones y eliminaciones, y ANALYZE para actualizar estadísticas que ayudan al optimizador a elegir buenos planes. El demonio autovacuum puede emitir ANALYZE automáticamente cuando una tabla cambia lo suficiente.

SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  last_vacuum,
  last_autovacuum,
  last_analyze,
  last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

VACUUM (ANALYZE) ventas;

En tablas grandes con mucha escritura, autovacuum suele necesitar ajustes por tabla. Desactivarlo sin un plan es una mala práctica: puede causar crecimiento excesivo, estadísticas obsoletas y riesgo operativo.

3.5. Ajusta memoria sin excederte

En PostgreSQL, shared_buffers define la memoria compartida usada por el servidor para caché de datos, work_mem se usa para operaciones como ordenamientos y hash antes de escribir a disco, y maintenance_work_mem se usa en operaciones de mantenimiento como VACUUM, CREATE INDEX y ALTER TABLE. La documentación oficial advierte que estos parámetros deben entenderse dentro del consumo total de recursos del servidor.

3.6. Usa auto_explain para planes lentos

La extensión auto_explain permite registrar automáticamente planes de ejecución de consultas lentas sin ejecutar EXPLAIN manualmente. PostgreSQL la presenta como útil para encontrar consultas no optimizadas en aplicaciones grandes.

ALTER SYSTEM SET shared_preload_libraries = 'pg_stat_statements,auto_explain';
ALTER SYSTEM SET auto_explain.log_min_duration = '500ms';
ALTER SYSTEM SET auto_explain.log_analyze = on;
ALTER SYSTEM SET auto_explain.log_buffers = on;

-- Reiniciar PostgreSQL para cargar la librería si corresponde.

4. Optimización en MariaDB

4.1. Activa el slow query log

MariaDB documenta el slow query log como un registro de consultas SQL que tardan mucho tiempo en ejecutarse y advierte que puede contener información sensible si las consultas incluyen contraseñas u otros datos delicados.

sudo mariadb

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 0;

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'slow_query_log_file';

Para producción, es mejor guardar estos parámetros en el archivo de configuración correspondiente, proteger el archivo de log y rotarlo adecuadamente.

sudo nano /etc/mysql/mariadb.conf.d/60-optimization.cnf

[mariadb]
slow_query_log = 1
long_query_time = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log

4.2. Analiza consultas con EXPLAIN

MariaDB documenta EXPLAIN como una forma de mostrar información del optimizador sobre cómo procesará una consulta SELECT, UPDATE o DELETE, incluyendo orden de tablas y métodos de acceso. También indica que el resultado de EXPLAIN puede incluirse en el slow query log.

EXPLAIN
SELECT *
FROM ventas
WHERE cliente_id = 100
  AND fecha >= CURDATE() - INTERVAL 30 DAY;

Presta atención a columnas como type, key, rows y Extra. Si aparece un escaneo de demasiadas filas, si no se usa el índice esperado o si hay ordenamientos temporales innecesarios, debes revisar índices, estadísticas o la forma de la consulta.

4.3. Actualiza estadísticas con ANALYZE TABLE

MariaDB usa estadísticas de índices para orientar al optimizador. La documentación indica que ANALYZE TABLE actualiza estadísticas de distribución de claves que el optimizador utiliza para elegir el mejor plan de ejecución.

ANALYZE TABLE ventas;
ANALYZE TABLE clientes;
ANALYZE TABLE pedidos;

4.4. Ajusta InnoDB Buffer Pool

En MariaDB, el InnoDB Buffer Pool es una de las áreas de memoria más importantes para tablas InnoDB, porque almacena páginas de datos e índices. MariaDB mantiene documentación específica para su implementación, configuración y uso.

MariaDB también advierte en su documentación de memoria que muchas consultas lentas se corrigen con índices, cambios de esquema o cambios de consulta, no necesariamente ajustando buffers pequeños.

5. Ajustes comunes para PostgreSQL y MariaDB en Linux

5.1. Usa discos adecuados

Las bases de datos suelen sufrir cuando el almacenamiento no puede sostener escrituras, lecturas aleatorias o sincronizaciones frecuentes. Para producción, conviene usar SSD o NVMe, revisar latencia, IOPS, cola de disco y salud SMART. También es importante separar, cuando el presupuesto lo permita, datos, logs de transacción, backups y sistema operativo.

5.2. Evita swap excesivo

Una base de datos que usa swap de forma constante probablemente está mal dimensionada o tiene demasiadas conexiones/procesos. La memoria debe alcanzar para el motor, el sistema operativo, caché de disco, conexiones y aplicaciones que conviven en el mismo servidor.

free -h
swapon --show
vmstat 1 10

5.3. Controla las conexiones

Demasiadas conexiones simultáneas pueden consumir memoria y CPU sin mejorar el rendimiento. En aplicaciones web, suele ser mejor usar pool de conexiones: PgBouncer para PostgreSQL y pool de conexiones desde la aplicación o proxy compatible para MariaDB.

6. Consultas SQL: errores que destruyen el rendimiento

-- Evita esto si fecha tiene índice:
WHERE DATE(fecha) = '2026-07-01'

-- Mejor:
WHERE fecha >= '2026-07-01'
AND fecha <  '2026-07-02'

7. Monitoreo mínimo recomendado

PostgreSQL documenta vistas de estadísticas como pg_stat_activity, que muestra información de actividad por proceso del servidor. MariaDB ofrece Performance Schema para observar detalles internos de ejecución y rendimiento. Estas capacidades deben integrarse con herramientas como Prometheus, Grafana, Zabbix, Netdata, Wazuh o sistemas equivalentes.

8. Plan de optimización paso a paso

9. Configuraciones iniciales orientativas

Los siguientes ejemplos no deben copiarse sin evaluar RAM, carga real, versión del motor y número de conexiones. Sirven como plantilla de partida para documentar ajustes y probarlos en laboratorio.

Ejemplo PostgreSQL

ALTER SYSTEM SET shared_buffers = '4GB';
ALTER SYSTEM SET effective_cache_size = '12GB';
ALTER SYSTEM SET maintenance_work_mem = '1GB';
ALTER SYSTEM SET work_mem = '32MB';
ALTER SYSTEM SET max_connections = '100';

SELECT pg_reload_conf();

Ejemplo MariaDB

[mariadb]
innodb_buffer_pool_size = 8G
max_connections = 150
slow_query_log = 1
long_query_time = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log

10. Errores frecuentes al optimizar bases de datos

Preguntas clave

Recomendamos

En resumen

Optimizar PostgreSQL y MariaDB en Linux exige método. Primero mide el servidor, después identifica consultas costosas, revisa planes de ejecución, corrige índices y estadísticas, y finalmente ajusta memoria, conexiones y almacenamiento.

En PostgreSQL, las piezas clave son pg_stat_statements, EXPLAIN ANALYZE, VACUUM, ANALYZE, autovacuum, work_mem y shared_buffers. En MariaDB, las piezas clave son slow query log, EXPLAIN, ANALYZE TABLE, estadísticas de índices e InnoDB Buffer Pool.

La optimización no termina con un cambio de configuración. Debe convertirse en una práctica permanente: monitoreo, revisión de consultas, mantenimiento, backups probados y documentación de cada ajuste.