We Lost 9 Hours to One Query, the 7-Step Method I Now Use to Hire Postgres Engineers in Singapore

The requisition that reaches me usually says “we need someone strong on databases”. That sentence is where most of the wasted weeks come from, because it describes a feeling rather than a problem.

Step 1: Work out which of the four problems you actually have

Nearly every database requisition we receive maps to one of four situations, and they need different people.

A performance problem. Things were fine, then got slow. You need someone fluent in execution plans, indexing and query rewriting, typically a backend engineer with depth, and usually the fastest of the four to fix.

A reliability problem. Outages, failovers that did not work, a restore nobody has tested. You need operational experience: replication, recovery, connection management. Different person, different interview.

A scale problem. The current shape genuinely will not carry the next order of magnitude. This needs architectural judgement and is the rarest of the four, and the one companies claim most often, usually incorrectly.

A data-model problem. The schema fights every new feature. Migrations are frightening. This is the least glamorous and, in my experience, the most common actual cause. It needs someone who is good at modelling and at changing a live system safely.

Write down which one you have before anything else. If you find yourself claiming a scale problem, check whether the slow thing is slow at current volume, in which case you have a performance or modelling problem wearing a more exciting costume.

Step 2: Specialist or generalist? Usually generalist

Below roughly two hundred engineers, you almost certainly want a backend engineer with genuine PostgreSQL depth rather than a dedicated database administrator.

Managed database services have absorbed most of the classical DBA workload. Patching, backups, failover orchestration and provisioning are largely operated by the provider now. What they have not absorbed is anything requiring knowledge of your data: schema design, index strategy, migration safety, and diagnosing why one query got slow after one deploy.

That remaining work sits naturally with someone who also writes application code, because it is inseparable from how the application queries. Splitting it into a dedicated role often creates a handoff that slows both sides: the DBA cannot fix the query because it lives in the application, and the application engineer defers to the DBA and stops learning.

The exception is genuine: if you run multiple large clusters with strict recovery objectives and regulatory reporting, a dedicated database or platform engineer is warranted. That is a real role at a certain size, just considerably rarer than the number of requisitions asking for it.

Step 3: Write a requisition that names the actual system

Strong database engineers self-select on specifics, and generic adverts repel exactly the people you want.

Name the PostgreSQL version. State the approximate size of the largest table and the total dataset. Describe the workload shape: read-heavy, write-heavy, analytical queries against the same instance. Say what hurts. “Our largest table is 400 GB, migrations require a maintenance window we can no longer afford, and we need someone to make online schema change routine” will attract better candidates than three paragraphs about a fast-paced environment.

This is also an honesty filter that works in both directions. A candidate who reads that description and is not interested has saved you five weeks. That is a good outcome, and it happens at the top of the funnel where it is cheap.

Step 4: The three screening questions

These take fifteen minutes on a call and remove roughly seventy percent of candidates.

Question 1: “Describe the last execution plan you read, what it told you, and what you changed.” The single most reliable question we have. People who genuinely work with Postgres at depth answer immediately and concretely: a sequential scan where an index was expected, a row estimate off by two orders of magnitude, a join order that changed after statistics went stale. They also describe how they verified the fix. People who have used Postgres only as a place to put data talk generally about adding indexes. It is hard to fake because it requires the memory of a specific investigation.

Question 2, “Tell me about a time a migration or a query took a lock you did not expect.” Lock behaviour is where Postgres surprises people, and it is where production incidents come from. Anyone who has run meaningful migrations against a live system has this story. Absence of the story usually means absence of the experience.

Question 3, “When did you last restore a backup, and what went wrong?” Note the second half. Restores always have a complication: a missing extension, a permissions mismatch, a duration nobody had measured. A candidate who says restores went smoothly has probably never done one under pressure.

Step 5: Run the incident-based interview

Replace the technical exercise with a real incident from your own history. Ninety minutes.

Present the symptom exactly as your team first saw it: “At 09:40 the API latency went from 80 milliseconds to nine seconds. Nothing was deployed. Here is what the monitoring showed.” Then let the candidate investigate by asking you questions. You answer as the system would.

What you are evaluating is the order of their hypotheses. Strong candidates narrow systematically: is it all queries or one, did the plan change, is there lock contention, did a batch job start, did statistics go stale. Weaker candidates jump to a solution (add an index, add a cache, add a read replica) before establishing what is actually happening.

This format has a second benefit that we did not anticipate. It shows candidates real work, and the good ones find it far more engaging than an abstract exercise. We have had two Singapore candidates say the interview was why they accepted the offer.

Step 6: Benchmark the band and check the pass thresholds early

Monthly figures from Singapore offers benchmarked in 2026.

Add employer CPF contributions for citizens and permanent residents. For foreign hires, check the Employment Pass qualifying salary threshold before you start sourcing, not after you have chosen someone. In practice the threshold removes junior foreign candidates from this role entirely, which is worth knowing at the top of the funnel rather than at offer stage.

On timeline: ten to fourteen weeks for local or PR hires. Notice periods in Singapore commonly run two to three months and are almost always the largest single component, larger than sourcing, interviewing and offer combined. Plan the start date accordingly rather than hoping.

Step 7: Onboard against a 90-day scoreboard

Write it before they start. Share it in week one.

Day 30: has run a migration in production, however small, using your normal process. This validates access, tooling and the review path while the stakes are low.

Day 60: has diagnosed one real performance issue end to end and documented the finding. This is the first evidence that the screening signal was genuine.

Day 90: owns the problem you identified in step 1, and has proposed a plan for it. If this has not happened, the cause is usually unclear scope rather than capability, and it is fixable now rather than at the annual review.

One more thing worth doing in the first month, regardless of which problem you hired for: have them run a restore drill. It is the fastest way for a new database engineer to learn your system genuinely, and it routinely surfaces something nobody knew was broken.

If the wider platform team is being built at the same time, our guides on hiring a data engineer in Singapore and hiring Kubernetes platform engineers in Singapore cover adjacent roles with the same level of detail.

Frequently asked questions