TUNING POSTGRESQL — DESDE 2008

    POSTGRES LENTO NO ES AUTOVACUUM.

    Casi nunca es autovacuum. Es un plan que cambió tras ANALYZE, un seq scan en tabla con índice ignorado, bloat acumulado por UPDATE-heavy, o 800 conexiones sin pooler. Leemos pg_stat_statements y lo mostramos.

    60%
    Reducción media de latencia p95
    pg_stat
    Análisis top queries por tiempo total
    RDS/Aurora
    Especialistas en Postgres on Cloud
    12→16
    Cobertura completa en producción

    DBAs PostgreSQL confiados por

    Startups Serie B·Fintech·DataPrev·SaaS B2B·E-commerce·Sector Público

    EL DIAGNÓSTICO INCORRECTO

    "SUBE LA INSTANCIA". ¿DE NUEVO?

    AWS recomienda r6g.4xl → 8xl

    Duplica la factura mensual. Si el cuello es una query con Bitmap Heap Scan en 50M tuplas porque ANALYZE tomó muestra mala, la instancia mayor solo quema dinero.

    Equipo mira CloudWatch, ignora pg_stat_statements

    CPU 70% no dice nada. Lo que mata es la query top-1 que sola consume 38% del tiempo de DB. pg_stat_statements lo responde en 2 minutos.

    Autovacuum atrasado, bloat en silencio

    Tabla de 200GB con 140GB de bloat. SELECTs leyendo páginas vacías. VACUUM FULL bloquea prod. Sin tuning por tabla, el problema vuelve.

    El pooling existe, nadie lo usó

    App abriendo 600 conexiones directas. Cada una = un proceso. RAM se agota, OOM killer mata postmaster. PgBouncer en transaction mode lo resuelve en 1 día.

    ALCANCE TÉCNICO

    TUNING POSTGRES DE VERDAD.

    No es "correr VACUUM y rezar". Análisis de pg_stat_statements, autovacuum por tabla, EXPLAIN ANALYZE con BUFFERS, y prueba de reducción en p95.

    01

    pg_stat_statements DEEP DIVE

    Top 20 queries por total_exec_time. Detección de N+1, planes subóptimos, queries con I/O desproporcionado.

    pg_stat_statementsauto_explain
    02

    AUTOVACUUM POR TABLA

    autovacuum_vacuum_scale_factor ajustado por tabla caliente, autovacuum_analyze_scale_factor para preservar planes, vacuum_cost_limit real.

    AutovacuumVACUUMANALYZE
    03

    BLOAT RESOLUTION

    pg_repack online en producción sin bloqueos, detección con pgstattuple, prevención vía fillfactor y HOT updates.

    pg_repackpgstattupleHOT
    04

    EXPLAIN ANALYZE TUNING

    EXPLAIN (ANALYZE, BUFFERS, VERBOSE), detección de underestimates de cardinality, CREATE STATISTICS, pg_hint_plan cuando crítico.

    EXPLAINStatspg_hint_plan
    05

    POOLING & CONEXIONES

    PgBouncer en transaction mode, dimensionamiento por carga real, monitoreo de pool exhaustion, RDS Proxy cuando aplica.

    PgBouncerRDS Proxy
    06

    PARTITIONING

    Declarative partitioning range/list/hash, partition pruning real, mantenimiento automatizado, BRIN en series temporales.

    RangeHashBRIN

    ESPECIALISTAS POSTGRES

    ¿QUIÉN TOCARÁ TU POSTGRES?

    No es dev que aprendió Postgres en un blog. Es DBA con track record en producción desde 8.4, hoy 16, en sala física controlada en PIT/SP.

    • DBAs con producción Postgres desde 8.4
    • Track record en fintechs, SaaS B2B y sector público
    • Sala física con acceso biométrico — sin freelance remoto
    • Especialistas en RDS, Aurora PostgreSQL, GCP CloudSQL y on-premise

    pg_stat_statements es tu radiografía. Si nadie lo leyó en 30 días, el problema te está esperando.

    RESULTADOS MEDIDOS

    ANTES Y DESPUÉS.

    FINTECH SERIE B

    p95 -80%

    API checkout

    Latencia p95 de API checkout en PostgreSQL 14 reducida de 850ms a 170ms con 3 índices, 1 query reescrita y PgBouncer en transaction mode.

    SAAS B2B

    200GB 60GB

    Bloat removido

    Tabla de eventos de 200GB con 70% de bloat reducida a 60GB con pg_repack online, sin ventana, autovacuum tunado para prevenir recurrencia.

    E-COMMERCE

    -40% RDS

    Costo mensual

    Aurora PostgreSQL bajada de r6g.4xl a r6g.2xl tras tuning de 8 queries top, sin pérdida, ahorro anual de US$78K.

    METODOLOGÍA

    DEL pg_stat AL FIX EN 5 DÍAS.

    Día 1

    Recolección pg_stat + EXPLAIN

    Exportas pg_stat_statements, pg_stat_user_tables, auto_explain log y postgresql.conf. Sin acceso al ambiente.

    Días 2–3

    Diagnóstico técnico

    Top queries por tiempo total, detección de bloat y stats stale, análisis de connection pattern.

    Día 4

    Plan de fix priorizado

    Scripts de índice, ajuste de autovacuum por tabla, pg_repack si aplica, deploy de PgBouncer. Ordenado por ROI.

    Día 5

    Aplicación supervisada

    Homologación con workload realista, deploy en prod con rollback documentado. Reporte post-fix con pg_stat_statements comparativo.

    FAQ

    Preguntas frecuentes.

    ¿Necesitan acceso a mi Postgres para empezar?

    +

    No. El diagnóstico inicial corre con pg_stat_statements + pg_stat_user_tables + auto_explain log que tú generas. Acceso solo en la aplicación del fix.

    ¿Atienden Aurora PostgreSQL y RDS?

    +

    Sí. Aurora PostgreSQL, RDS for PostgreSQL, Cloud SQL (GCP), Azure Database for PostgreSQL y on-premise. Las herramientas cambian, los principios no.

    ¿Cómo evitan que el plan cambie tras el fix?

    +

    Postgres no tiene plan baselines nativos, pero usamos extended statistics, pg_hint_plan cuando crítico y monitoreo continuo de pg_stat_statements.

    VACUUM FULL bloquea prod. ¿Cómo rebuild?

    +

    pg_repack. Reorganiza online sin bloqueos largos. Usamos en producciones con SLA 99.9% sin ventana.

    ¿Atienden versiones antiguas (9.6, 10, 11)?

    +

    Sí, con recomendación de upgrade. 9.6 y 10 fuera de soporte. Tuning funciona, pero varias mejoras de planner solo vienen en 13+.

    ENVÍA EL pg_stat.

    20 minutos con un DBA Senior PostgreSQL. Envías pg_stat_statements, devolvemos diagnóstico técnico. Sin formulario comercial.

    Versiones y plataformas soportadas

    PostgreSQL 12PostgreSQL 13PostgreSQL 14PostgreSQL 15PostgreSQL 16Aurora PostgreSQLAWS RDS PostgresGCP CloudSQLAzure DatabasePgBouncerpg_repack

    POR QUÉ HTI

    AUTORIDAD
    EN BASE
    DE DATOS.

    Sustentando ambientes críticos en Brasil desde 1990. No somos una consultoría genérica que aprendió base de datos — somos The Database Company.

    01

    35+ AÑOS EN EL MERCADO

    Operando ininterrumpidamente desde 1990. Más de 25.000 horas de consultoría entregadas y 596+ incidentes críticos resueltos en producción. Pattern recognition que solo viene con décadas de operación real.

    02

    ORACLE AMEC — ÚNICA EN BRASIL

    Único MySQL Authorized Education Center (AMEC) de Oracle University en Brasil — logro obtenido dos veces. Más de 1.000 DBAs formados en cursos oficiales HTI.

    03

    SALA FÍSICA CONTROLADA

    DBAs en sala de acceso restringido en PIT São José dos Campos: cámaras 24h, acceso biométrico, rack dedicado. Sin freelancer remoto, sin estación improvisada. Compliance que va más allá de la política interna.

    04

    DBSNOOP — HERRAMIENTA PROPIA

    Monitoreo comportamental desarrollado internamente. Detecta patrones anómalos de ingestión y accesos a objetos protegidos — sin dependencia de herramienta de terceros.