PostgreSQL Performance Tuning
NZ & ANZ
Senior PostgreSQL tuning for teams facing slow queries, Aurora/RDS instability, vacuum and bloat pressure, replication lag, connection issues or incident-level performance risk. The focus is simple: find the real bottleneck, change safely, and leave your team with evidence and runbooks.
Available immediately for contract & partner subcontracting · Auckland / Remote ANZ
When to call me
A query has become a business problem
A report, batch, API or job is now slow enough to affect customers, operations or release confidence.
- Execution plan review
- Wait and lock analysis
- Safe mitigation path
The database is getting harder to operate
Bloat, autovacuum lag, replication lag, storage growth, connection pressure or failover uncertainty are creating ongoing risk.
- Vacuum/bloat strategy
- Replication review
- RDS/Aurora parameters
Spend is rising but performance is not improving
Bigger instances or more storage have not solved the root cause, and the team needs targeted tuning before scaling again.
- Workload diagnosis
- Index and query options
- Cost-aware remediation
What I investigate first
Plans, joins, indexes and statistics
EXPLAIN output, row estimates, join order, index usage, missing or harmful indexes, stale stats and query rewrite opportunities.
- Low-risk query fixes
- Index sequencing
- Before/after validation
Vacuum, bloat and parameters
Autovacuum posture, dead tuples, table/index bloat, checkpoints, work_mem, shared_buffers, WAL behaviour and parameter group fit.
- Bloat control
- Parameter review
- Maintenance rhythm
Aurora/RDS-specific behaviour
Storage I/O, replica lag, failover design, connection pooling, Performance Insights signals and workload patterns unique to managed PostgreSQL.
- Aurora/RDS tuning
- Connection strategy
- Operational visibility
Typical deliverables
Diagnostic output
- Slow-query and workload summary
- Root-cause hypothesis with evidence
- Priority-ranked tuning actions
- Risk level and expected impact per change
Change plan
- Rollback-safe sequencing
- Index/query/parameter recommendations
- Validation checklist and before/after metrics
- Monitoring improvements
Handover
- RCA summary for stakeholders
- Runbook for future incidents
- Knowledge transfer for engineers
- Optional follow-up tuning sprint
Engagement shapes
Best fit options are a 48-hour incident triage, a two-week performance sprint, or longer support where tuning is part of a migration, HA/DR or AWS platform engagement.
How I avoid tuning guesswork
Evidence before edits
Performance work starts with plans, waits, workload patterns and operational signals. This reduces the risk of adding indexes, changing parameters or scaling infrastructure without fixing the real cause.
Small safe changes first
The best tuning path is usually staged: prove the bottleneck, make the smallest high-impact change, validate before/after behaviour, then decide whether deeper work is justified.
Runbooks after rescue
A good fix should not disappear into one engineer's memory. I turn the lesson into monitoring checks, rollback notes and repeatable guidance your team can use next time.