35+ YEARS IN MARKET
Continuously operating since 1990. 25,000+ consulting hours delivered and 596+ critical production incidents resolved. Pattern recognition only decades of real operation can build.
POSTGRESQL PERFORMANCE TUNING — SINCE 2008
It's almost never autovacuum. It's a plan that flipped after ANALYZE, a seq scan on a table with an ignored index, accumulated bloat on UPDATE-heavy workload, or 800 connections without a pooler. We read pg_stat_statements and show you.
PostgreSQL DBAs trusted by
THE WRONG DIAGNOSIS
AWS recommends r6g.4xl → 8xl
Doubles the monthly bill. If the bottleneck is a query doing Bitmap Heap Scan on 50M tuples because ANALYZE picked a bad sample, the bigger instance just burns money faster.
Team watches CloudWatch, ignores pg_stat_statements
70% CPU avg means nothing. What matters is the top-1 query that alone consumes 38% of DB time. pg_stat_statements answers that in 2 minutes.
Autovacuum behind, bloat in silence
200GB table that's 140GB bloat. SELECTs reading empty pages. VACUUM FULL freezes prod. Without per-table tuning of autovacuum_vacuum_scale_factor, it returns.
Pooling exists, nobody used it
App opens 600 direct connections to Postgres. Each = one process. RAM blows, OOM killer kills postmaster. PgBouncer in transaction mode solves it in a day.
TECHNICAL SCOPE
Not "run VACUUM and pray". pg_stat_statements analysis, per-table autovacuum, EXPLAIN ANALYZE with BUFFERS, and proven p95 reduction measured via comparative pg_stat_statements snapshots.
Top 20 queries by total_exec_time. N+1 detection, suboptimal plans, queries with disproportionate I/O. Baseline vs incident snapshot.
autovacuum_vacuum_scale_factor tuned per hot table, autovacuum_analyze_scale_factor to preserve plans, vacuum_cost_limit to actually do I/O.
pg_repack online in production with no blocking, bloat detection with pgstattuple, prevention via fillfactor and HOT updates.
EXPLAIN (ANALYZE, BUFFERS, VERBOSE), cardinality underestimate detection, CREATE STATISTICS for correlations, pg_hint_plan when needed.
PgBouncer in transaction mode, pool sizing based on real load, pool exhaustion monitoring, RDS Proxy integration when it fits.
Declarative partitioning range/list/hash, real-query pruning, automated new-partition maintenance, BRIN on time series.
POSTGRES SPECIALISTS
Not a dev who learned Postgres from a blog. A DBA with production track record since 8.4, today 16, in a controlled physical room at PIT/SP.
pg_stat_statements is your X-ray. If nobody read it in the last 30 days, the problem is waiting.
MEASURED RESULTS
SERIES B FINTECH
Checkout API
PostgreSQL 14 checkout API p95 latency cut from 850ms to 170ms with 3 indexes created, 1 query rewritten and PgBouncer in transaction mode.
SAAS B2B
Bloat removed
200GB events table at 70% bloat reduced to 60GB with pg_repack online, no maintenance window, and tuned autovacuum to prevent recurrence.
E-COMMERCE
Monthly cost
Aurora PostgreSQL downsized from r6g.4xl to r6g.2xl after tuning 8 top queries, no performance loss, US$78K annual savings.
METHODOLOGY
pg_stat + EXPLAIN collection
Export pg_stat_statements, pg_stat_user_tables, auto_explain log and postgresql.conf. No environment access required.
Technical diagnosis
Top queries by total time, bloat and stale stats detection, connection pattern analysis. Report with documented root cause.
Prioritized fix plan
Index scripts, per-table autovacuum tuning, pg_repack when needed, PgBouncer deploy. Ordered by ROI.
Supervised rollout
Staging with realistic workload, production deploy with documented rollback. Post-fix report with comparative pg_stat_statements.
FAQ
No. Initial diagnosis runs on pg_stat_statements export + pg_stat_user_tables + auto_explain log you generate. Access only during fix application with a restricted user revoked at project end.
Yes. Aurora PostgreSQL, RDS for PostgreSQL, Cloud SQL (GCP), Azure Database for PostgreSQL and on-premise. Tools differ slightly, principles are the same.
Postgres has no native plan baselines like Oracle, but we use 3 strategies: extended statistics for correlations, plan stability via pg_hint_plan when critical, and continuous pg_stat_statements monitoring to detect regression before the user.
pg_repack. Reorganizes table online with no long locks. Runs in parallel, swaps the table atomically at the end. Used in 99.9% SLA prods with no window.
Yes, with a technical recommendation to plan upgrade. 9.6 and 10 are out of support, 11 in 2024. Tuning works, but several planner improvements only ship in 13+.
20 minutes with a Senior PostgreSQL DBA. Send pg_stat_statements export, we return a technical diagnosis. No sales form.
Versions and platforms supported
WHY HTI
Sustaining critical environments in Brazil since 1990. We're not a generic consultancy that learned databases — we are The Database Company.
Continuously operating since 1990. 25,000+ consulting hours delivered and 596+ critical production incidents resolved. Pattern recognition only decades of real operation can build.
The only MySQL Authorized Education Center (AMEC) of Oracle University in Brazil — achieved twice. Over 1,000 DBAs trained in official HTI courses.
DBAs operate from a restricted-access room at PIT São José dos Campos: 24h CCTV, biometric access, dedicated rack. No remote freelancers, no improvised workstations. Compliance that goes beyond internal policy.
Behavioral monitoring developed in-house. Detects anomalous ingestion patterns and access to protected objects — no third-party tool dependency.