PostgreSQL Consulting
I help teams diagnose PostgreSQL bottlenecks, tune autovacuum and bloat, improve indexing and query plans, set up connection pooling with PgBouncer, and design infrastructure that performs predictably under real traffic — on RDS PostgreSQL, Cloud SQL, Supabase, or self-hosted.
PostgreSQL has a rich set of diagnostic tools that most teams underuse. The work usually starts here before touching a single query or index.
The difference between EXPLAIN and EXPLAIN ANALYZE (BUFFERS) tells you not just what the planner intended but what actually happened at runtime — row estimates vs. actual rows, buffer hits vs. reads, and where time actually went. Most slow query investigations start here.
The extension that shows aggregate query performance across your entire workload — total time, calls, mean time, and stddev. The highest total_time entries are almost always the right starting point, not the slowest individual query.
PostgreSQL's MVCC model means dead tuples accumulate and must be cleaned up. Misconfigured autovacuum — or autovacuum that cannot keep up with write volume — leads to table bloat, index bloat, and query slowdowns that look like query problems but are actually maintenance problems.
PostgreSQL forks a process per connection. At high concurrency, connection overhead becomes a bottleneck before the database itself is under load. PgBouncer in transaction-mode pooling is the standard fix — but the configuration requires care, especially with prepared statements and session-level features.
Query analysis with EXPLAIN ANALYZE, index design, execution-plan review, and workload-specific tuning using pg_stat_statements to find the queries with the highest cumulative cost.
Autovacuum configuration, bloat monitoring, replication health, connection pooling with PgBouncer, backup strategy, and safer operational workflows for teams running PostgreSQL in production.
Schema design, access patterns, logical replication setup, caching, and application boundaries when PostgreSQL is becoming a throughput or reliability bottleneck.
PostgreSQL consulting work covers the full range of deployment environments:
Result
Dashboard load time cut from 6s to under 400ms after autovacuum misconfiguration was identified.
A reporting dashboard was progressively slowing down despite no obvious query changes. EXPLAIN ANALYZE showed sequential scans on a heavily updated table. pg_stat_user_tables revealed dead tuple accumulation — autovacuum had fallen behind on a high-write table due to a misconfigured cost delay setting. After tuning autovacuum, running a manual VACUUM ANALYZE, and adding a partial index for the dashboard's primary filter, response time dropped from 6 seconds to under 400ms.
A fixed-scope Database Performance Audit is $1,500 and takes one week — slow query analysis with pg_stat_statements and EXPLAIN ANALYZE, index and autovacuum review, and a prioritized fix list. Larger engagements are scoped per project. See the full offer details.
Yes. Both are common in client work. The diagnostic approach is the same as self-hosted PostgreSQL, but managed environments have specific constraints — parameter group limits on RDS, flag restrictions on Cloud SQL, and connection limits that are lower than what self-hosted PostgreSQL can support. These constraints matter when planning fixes.
pg_stat_statements analysis to identify high-cost queries, EXPLAIN ANALYZE review for the top offenders, index coverage and access pattern assessment, autovacuum configuration and bloat check, connection behavior review, and a written report with a prioritized fix list. Delivered within one week.
Yes. PgBouncer configuration — particularly choosing the right pooling mode and handling prepared statement compatibility — is a common implementation engagement. I can review your current connection behavior, recommend the right configuration, and help implement it safely with zero-downtime rollout.
Related services