If you’re going to hire a PostgreSQL consultant, hire one. That means access to the database.
I’m writing this because the “we hired you but you can’t touch the thing” conversation happens at the start of roughly one in four PGX engagements, and I would like to have something to point at instead of having the same conversation over and over. I understand the impulse. Production databases are the company’s crown jewels, security people have real worries, compliance is real, and “give some random person root” is not a thing a sane organization does casually. I’m not asking you to do that. I’m asking you to do the professional version of it, which exists, and which reputable consultancies have been doing for decades.
Here is why the alternatives don’t work.
“You can just give us commands and we’ll run them.”
No.
This is repairing a car over the phone. Every PGX engineer has, at some point, watched a client’s staff paste a slightly-wrong version of a command we dictated, or run the right command in the wrong window, or hit return on a half-edited UPDATE because the chat client autocompleted something clever. In one memorable case, a client ran REINDEX against the wrong schema because two terminals were open and they picked the wrong one.
The probability of a database-damaging mistake when a human is typing commands dictated by another human over Slack or Zoom is not small. It is high enough that PGX does not give database-modifying commands by dictation, as a matter of policy. We will do read-only SELECT analysis that way if we have to. We will not hand you a DROP, ALTER, UPDATE, DELETE, or VACUUM FULL by voice or chat. The blast radius is too large and the error rate is too high, and we would rather decline the work than be the voice in the headset when the WHERE clause goes missing.
There is also the small matter that if you are paying us by the hour, and the hour is spent watching your staff slowly and carefully type what we just told them, you are paying a great deal of money to rent an unusually expensive human-assisted IDE.
“We want to watch you do it so our team gets trained at the same time.”
Pick one.
You can hire us to do the work, or you can hire us to train your team. Both are services PGX is happy to provide. They are not the same service, and they cannot be provided simultaneously, especially under production pressure.
When I’m untangling a wedged autovacuum on a live system at 11pm, I am not in teaching mode. I am in “do not make this worse” mode. Teaching mode requires a calm environment, time to explain context, time to answer “but why?”, and the latitude to say “let’s try the wrong thing first and see what happens” without setting money on fire. None of that is available while production is on fire.
If you want training, we’ll do training. Schedule it. Give it the time and the focus it deserves. Don’t try to extract it as a free side-effect of incident response. You will get a bad incident response and bad training, which is a remarkable value proposition in the wrong direction.
“Our security people won’t approve outside access.”
Ask your security people the following question. Name every person at AWS — or Google, or Microsoft — who has root access to your hosted PostgreSQL instance. Every one. By name.
They can’t. Nobody can. It is dozens of people, probably hundreds if you count the operational engineers with break-glass access to the underlying systems, and the roster turns over continuously. Every one of them could, in principle, read your data today. You approved this when you signed the cloud contract, because you concluded — correctly — that the controls around that access (SOC 2, audit logs, background checks, contractual liability) make the risk acceptable.
(Increasingly, we are seeing databases that we are supposedly too risky to allow access to, but whose parameters and even underlying data are write-accessible to an AI via an MCP server. You might want to mention to your legal team that you can’t sue an AI, but you can sue us, and we even have errors and omissions insurance, thankfully unused to this day.)
Now ask those same security people to explain why one named, background-checked consultant from a reputable firm — a firm with everything to lose from one bad incident and nothing whatsoever to gain from mischief — represents a higher risk than the rotating cast of cloud-provider SREs they have already approved.
The correct controls for consultant access are well understood: named individual accounts, time-boxed credentials, session logging, MFA, IP allowlisting where feasible, and contractual obligations around data handling. PGX works this way on every engagement that requires it. We are entirely used to negotiating with security teams, and we have written our share of access-control documents to make them comfortable. What we cannot work around is a blanket “no outside access, ever” posture, because that posture is not actually about security. It is about not having thought the problem through.
“We’ll spin up a copy and you can work on that.”
Sometimes this works. Often it doesn’t.
If the problem is a slow query against 200GB of production data, a 10GB sanitized sample will not reproduce the plan. If the problem is lock contention that only manifests under production concurrency, a copy with no traffic will not reproduce it. If the problem is autovacuum falling behind a specific write pattern, a static snapshot is silent on the subject. If the problem is replication lag — well, you see where this is going.
Copies are useful for some kinds of work (schema redesign, extension testing, migration dry-runs) and useless for others (performance work, live incident diagnosis, anything involving replication or concurrency). Know which kind of problem you have before you offer us a copy, and do not be surprised when we ask to see the real thing anyway.
“We have compliance constraints — HIPAA, PCI, SOX, GDPR.”
Good. So do many of our clients. We are familiar with the drill. We have forms for all of that.
Compliance regimes do not forbid outside consultants from touching regulated systems. They require that the access be controlled, audited, documented, and covered by a written agreement. All of which we do. If your interpretation of compliance is that no external party may ever log into production, your interpretation is stricter than the regulation itself, and you should ask yourself — or your auditor — why.
“We’ll have our DBA run the commands while you watch over Zoom.”
Your DBA is good. That is not the issue.
The issue is that under pressure, with an expensive consultant watching, with the CTO pinging Slack every five minutes for an update, your DBA is going to fat-finger something. Not because they are bad at their job, but because that is what happens to humans under those conditions. And when it happens, the question of who is responsible for the damage becomes genuinely ambiguous, which is the worst possible outcome for everyone in the room.
Let your DBA do the calm work. Let us do the emergency work. That’s the division of labor that makes sense.
If you have hired PGX (and we hope you do! we’re very good at what we do! and we’re nice!), you have already decided that our judgment on PostgreSQL is worth paying for. That judgment includes knowing the difference between a command that is safe to run and one that is not, knowing which diagnostics to collect before making a change, and knowing when to stop and think instead of proceeding. That judgment largely evaporates the moment we are typing into a chat window for someone else to execute.
Give us access. Scope it, log it, time-box it, revoke it when we are done. Let us do what you are paying us for.