PostgreSQL Performance Consultant
PostgreSQL performance consultant for slow queries, missing indexes, locking, bloat, and connection limits. EXPLAIN-driven audits with measured before/after. Remote, senior.
If your database is the bottleneck and you want a PostgreSQL performance consultant who works from query plans instead of guesses, that’s my favourite kind of engagement. I’m Kuldeep Pisda — a senior backend engineer and former startup CTO in Bengaluru. I treat Postgres as a first-class part of the system and fix the actual cause, measured before and after.
What a performance engagement covers
- Slow-query diagnosis — reading
EXPLAIN (ANALYZE, BUFFERS)to find the real problem: a sequential scan throwing away rows, a bad join order, a sort that should be an index, or an N+1 storm from the ORM. - Indexing strategy — composite indexes in the right column order (equality before range), partial and covering indexes, index-only scans — plus removing the unused indexes quietly slowing every write.
- Locking and concurrency — diagnosing lock contention, long-held transactions,
and the
ACCESS EXCLUSIVEmigrations that stall production; moving correctness into constraints where it belongs. - Bloat and autovacuum — table/index bloat, dead tuples, and tuning autovacuum so it keeps up instead of falling behind under write load.
- Connections and pooling — right-sizing connections and putting PgBouncer in front so a traffic spike doesn’t exhaust the server.
- Scaling the schema — partitioning large tables, archiving cold data, and safe
online migrations with
CREATE INDEX CONCURRENTLY.
What “measured” means
I’ve taken a hot endpoint from ~30 seconds to roughly 200ms — the before-plan was a sequential scan discarding tens of thousands of rows; the after-plan read eight cached pages on an index. I’ve enforced no-double-booking with a GiST exclusion constraint that, as a side effect, made availability lookups thousands of times faster. Every change comes with the plan that justifies it.
How engagements work
Usually a focused audit: send me the slow query, its EXPLAIN output, table sizes,
and the schema, and I come back with the specific fix and the reasoning. From there
it’s a one-off, a short optimization sprint, or an ongoing retainer as your
database-of-record grows. Remote, IST, US/EU overlap.
FAQ
What do you need to start?
The problem query, its EXPLAIN (ANALYZE, BUFFERS) plan, table sizes, and the
relevant schema. That’s usually enough to pinpoint it.
Can you work on a production database safely? Yes — I work read-only first, test changes off-peak, and flag any migration that would lock a large table before it runs.
Do you tune the server itself?
Within reason — work_mem, autovacuum, and pooling settings that matter for your
workload. I won’t hand-wave postgresql.conf changes without a reason.
RDS, Aurora, Cloud SQL, or self-hosted? All of them. Managed Postgres hides some knobs; I work within what your platform exposes.
How is this different from general Postgres work? This is the performance-audit angle; for RLS, pgvector, and broader schema design see hire a PostgreSQL expert.
Let’s talk
Send me the query that’s keeping you up at night — get in touch, or grab a time below:
Related: Hire a PostgreSQL Expert · Hire a Django Consultant · Hire a Backend Engineer in India · Hire a Django Developer in India