Technical support comes in many shapes. Sometimes it’s "try rebooting" or "check the cable." And sometimes it’s deep engineering work you wouldn’t mind dedicating your whole life to. Which version lives inside Postgres Professional, and what’s more important in this field — people or tech? We dig into this with Kamil Karimov, Senior technical support engineer at Postgres Professional.

Technical support found me first

After a few years working in field X, I realized I wasn’t growing anymore and wanted to dive into PostgreSQL. I wasn’t planning to go into tech support — I was simply looking for anything connected to this DBMS. Like many others, I imagined support work as a series of short replies like "click here," "reboot that," and so on.

Then I saw an opening for a Junior support engineer at Postgres Professional. The responsibilities included consulting on PostgreSQL and Postgres Pro, troubleshooting DBMS issues, and performing technical tasks.

It sounded interesting. More importantly, I understood it would let me get hands-on with PostgreSQL — which I had never worked with before (yes, that’s allowed).

What a technical support engineer actually does

Most of our work is real engineering. Clients come to us with everything from package installation questions to "the application keeps crashing and it looks like data corruption."

The first step is always collecting diagnostics: figure out what’s happening and which system is actually at fault.

The choice of tools depends on the case. If something is stuck or performance is tanking, GDB or perf is a good fit. Sometimes system views inside Postgres help.

Among Postgres Professional tools, we often use pgpro_stats paired with pgpro_pwr. For example, these let us generate workload reports for the time of an incident and compare them against a baseline when everything worked fine.

The main thing is deep product knowledge — sometimes that alone is enough to narrow down the problem area.

Once we identify the issue, we try to reproduce it: build a test environment and generate the exact workload that triggers the error. If we suspect a bug or see room for improvement, we bring in the developers.

It’s the same kind of work a DB engineer or DBA does — but much lower-level and with a heavy focus on troubleshooting.

We handle requests through a dedicated support portal. It’s far more convenient than email, where things inevitably get lost.

The 6 TB case

A client’s standard checkpoint process stopped running. Over four hours, their pg_wal directory grew to 6 TB and ate all available disk space.

Investigating, we saw that checkpointing ran normally for some time and then suddenly stopped triggering. Using our crash_info tool, we grabbed a backtrace and noticed calls inside the checkpoint process that definitely shouldn’t have been there.

Digging through the code, we discovered that a specific code path activates if the parameter archive_timeout is enabled. This was a non-obvious case, because we’d always assumed that archive_timeout doesn’t run when the main parameter archive_mode is disabled. We turned off the parameter and fixed the issue. A fun bug hunt.

Who comes to us

Most of our clients have a strong technical background, and this helps a lot. When someone isn’t deeply familiar with the tech, we write more detailed explanations and provide simple examples. Usually that’s enough.

The ideal support request includes:

  • a detailed problem description;

  • a timeline of events that led up to it;

  • all required diagnostics, ideally with a reproducible case.

But reality is different. Sometimes students contact us asking for help with coursework or theses. We don’t do that — we explain that it’s better to learn by solving it themselves.

Sometimes a client asks us to settle a developer vs. DBA dispute. For example, the app developer blames a misbehaving VACUUM, while the admin insists the procedure runs normally. We’re always happy to step in there.

Certain phrases raise immediate red flags. For example: "We found something on the internet and tried it, but it didn't help." This usually means things got worse.

What you need to know to work in Postgres Professional support

Both hard and soft skills matter equally.

On the technical side, you should:

  • know Postgres Pro — architecture, features, quirks, the whole ecosystem;

  • understand operating systems and be able to administer and troubleshoot them;

  • understand networking and have a general idea of server infrastructure;

  • be able to program or at least read code.

On the communication side, it’s important to remember that clients usually come to us under stress. Some have time to solve things calmly, others need help right now. A support engineer has to develop communication skills — the client must feel that we care and are doing everything we can.

Tech support is as much about people as it is about technology. Actually, all of IT is heading this way. Even if your role doesn’t involve direct customer work, you’re still interacting with many adjacent teams. So you can’t just sit in a corner and focus on tech anymore.

Growing inside and outside tech support

It depends on the company, but I think you can grow endlessly in our support team. Every release brings new features, new cases, and new bugs that push you to explore PostgreSQL’s codebase and sharpen your skills.

Overall, tech support is a great launchpad for entering IT. You’ll touch all kinds of tasks and fields. Later, you can choose whatever you like most. Sometimes, that turns out to be support itself.

For anyone interested in this field, I recommend Brendan Gregg’s book Systems Performance. It covers situations like "nothing works, please help." For Postgres specifically, it helps to watch conference talks and read anything Postgres-related.

The future of technical support is…

More complex cases — because features and abstraction layers keep growing. I’ve definitely seen this trend over the last three years.

For simpler routine tasks, AI will take over a bigger share. I already use it as a smarter search engine and for generating DDL.

Words of wisdom from an experienced engineer

  • If a P1 ticket lands first thing in the morning, you’re in for a fun day.

  • Friday is ticket day: clients spend the whole week fighting issues on their own, and whatever they can’t fix gets ceremoniously delivered to us on Friday.

  • Don’t make evening plans on Friday. Clients sense this and will send you something urgent. The reverse is also true.

  • Take breaks — run errands, go for a walk, hit the gym. No rest means no productivity.

  • If you just joined support, take on any task you can. It’s the fastest way to level up.

In our stories about the awesome folks working at Postgres Professional, we’ve also featured articles about: