Postgres Performance Tuning Services: Build or Buy?

A Postgres database that was fine at 5 million rows starts timing out at 50 million. p95 on your order list drifts from 200 ms to two seconds, someone adds an index, it helps for a month, and then it doesn't. This usually lands on a CTO or an engineering lead at an Indian B2B company with no dedicated DBA — one or two backend developers who already have a roadmap to ship. At that point the real question is not how to tune Postgres. It is whether to hire, to buy a tuning service, or to move the problem to a managed provider.

What "postgres performance tuning services" actually means

Vendors sell four different things under one name, and the price gap between them is large.

• A one-off audit. Someone reads pg_stat_statements, your schema and your slow query log, then hands you a prioritised list. Typically 3-7 working days, and for an SMB-sized database, usually ₹40,000-₹1,50,000.
• A fixed-scope fix sprint. They implement the changes — indexes, query rewrites, connection pooling, configuration — and prove it with before-and-after numbers. Typically 2-6 weeks.
• A monthly retainer. Monitoring, alerting, capacity planning and advice on call. Commonly ₹25,000-₹75,000 a month.
• A configuration job. Someone runs pgtune, edits shared_buffers and work_mem, restarts, and sends an invoice. On its own this is worth very little, and it is what a lot of cheap "tuning" turns out to be.

Knowing which of the four you are buying is more useful than comparing hourly rates.

Where the time actually goes

In our experience, well over half of slow Postgres incidents are not server configuration problems at all. They are one of these:

• A missing or wrong composite index on a table that has outgrown RAM.
• An ORM emitting N+1 queries, or a SELECT * dragging wide rows across a network hop.
• A reporting query running against the primary instead of a replica.
• Table bloat caused by a long-running transaction, a stale replication slot, or autovacuum settings nobody revisited.
• Connection exhaustion from serverless functions opening a new connection per request.

None of these get fixed by buying a bigger instance. A competent engagement finds them in week one. A config-only vendor never finds them. If the schema itself is the constraint — no partitioning, a random UUID primary key on a 200-million-row table — that is a system design problem rather than a tuning one, and it is worth a proper architecture review before you spend anything on tuning.

Build versus buy, with numbers

A worked example. A Gurgaon B2B SaaS company ran a 180 GB Postgres database on a 4 vCPU / 16 GB managed instance costing about ₹78,000 a month. p95 on their main list endpoint was 1.4 seconds and climbing. Three things were wrong: a missing composite index on (tenant_id, created_at), a status filter forcing a sequential scan across 90 million rows, and roughly 40% table bloat from a replication slot nobody had dropped. The index, one query rewrite and dropping the slot took about nine days of work. p95 fell to 180 ms, and the team moved to a 2 vCPU instance at ₹41,000 a month.

Now the options around that work. A mid-level Postgres DBA in India costs roughly ₹18-30 lakh a year fully loaded — about ₹1.5-2.5 lakh a month — and most SMBs do not have enough database work to keep one busy. A freelance consultant runs ₹3,000-₹8,000 an hour: reasonable for a day, expensive for a quarter. A tuning service sits in between, letting you rent the expertise for a defined scope.

There is a third path worth pricing honestly: moving to a provider that absorbs the operational side. If you are weighing a self-hosted box against a managed one, the cost model is not just the instance — it is backups, failover, patching and who gets paged at 2 a.m. We have written about running your own server infrastructure, and the trade-offs get clearer once you list them out.

When to build, when to buy

Build in-house when your team already reads query plans, the database is under about 50 GB, and the slowdowns are recent. A developer who can use EXPLAIN ANALYZE and pg_stat_statements will solve most of what you have.

Buy when the database is blocking revenue, when nobody on the team has tuned Postgres at this scale, or when the work needs to happen once and correctly. Insist on three things in any contract: access to pg_stat_statements data before recommendations are made, before-and-after measurements on a realistic dataset, and a written rollback plan for every index and configuration change.

Where to start

Before you talk to anyone, enable pg_stat_statements, collect a full week of data, and rank queries by total time rather than average. Most teams find five to ten queries responsible for the bulk of the load — which often tells you whether you need a service at all. If you want a second opinion on the schema and query plans before committing to a vendor, or you are deciding between self-hosted and managed Postgres, that is the kind of work Maysan Labs does.