ChatGPT for DBAs: Useful or Overhyped?

A Fair Answer: Both

General-purpose assistants are genuinely useful to a DBA, and they are genuinely oversold. The way to get value out of them is to be precise about which tasks they are good at, because the failure cases aren’t random — they follow a pattern you can predict.

The pattern: they are strong where the answer is general knowledge and weak where it depends on your specific state.

Where They Genuinely Help

• Explaining unfamiliar code. Paste a 400-line package and ask what it does. This is the single highest-value use, and it is exactly the task nobody wants to do by hand.
• Syntax translation you can verify. “What is the PostgreSQL equivalent of NVL?” The answer is short, well-known, and checkable in ten seconds.
• Boilerplate. Monitoring queries, a first-draft backup script, the shape of a trigger function.
• Rubber-ducking a design. Talking through a partitioning strategy with something that asks reasonable questions back.
• Writing the regex you always look up. Unglamorous and a real time save.

Where They Fail, Predictably

• Anything about your actual schema. It cannot see your tables, so it invents plausible column names and writes confident SQL against a schema that doesn’t exist.
• Version-specific behaviour. Training data blends PostgreSQL 12 through 18. Answers about recent syntax or removed features drift, and it will not tell you which version it was thinking of.
• Performance advice without a plan. “Add an index on that column” is a guess without EXPLAIN (ANALYZE, BUFFERS) output and real statistics.
• Scale. A schema of 4,000 objects does not fit in a chat window, and reviewing it one paste at a time is slower than reviewing it by hand.
• Anything confidential. Schema and query text pasted into a hosted service has left your building. That is a policy question, and often the whole conversation.

The Rule That Makes Them Safe

Use them where you can verify the answer faster than you could have produced it. “What replaces DECODE?” passes: the answer is CASE, and you know it in seconds. “Convert this 900-line package” fails: verifying it is the entire job, so the assistant saved you nothing and added a review burden.

Where Purpose-Built Tooling Differs

Not intelligence — context and determinism. A migration tool is connected to your actual database, so it reads real columns and real row counts instead of guessing. It converts through tested rules, so the same input produces the same output every time. It knows which constructs have no equivalent and says so. And it can run locally, so the confidentiality question has a boring answer.

The honest summary: use a general assistant to understand code, and purpose-built tooling to convert it. They are complementary, and the mistake is asking either to do the other’s job.