Hire PostgreSQL Developers: Rates, Vetting and Engagement Models

What a PostgreSQL developer actually does, and where hiring goes wrong

A SaaS company came to us with a dashboard that took 40 seconds to load. Their previous developer had "optimized" it by adding an index to every column mentioned in a WHERE clause. Eighteen indexes on one table. Writes had slowed to a crawl, autovacuum could not keep up, and the table had bloated to four times its real size. The actual problem was a single query where the planner was choosing a sequential scan because the statistics on a JSONB column were useless and random_page_cost was still set to 4.0 on SSD storage. Nobody had ever run EXPLAIN ANALYZE. They had been reading query timings from application logs and guessing.

That is the job. A PostgreSQL developer is not someone who writes SELECT statements. They are the person who reads a query plan and knows why the planner chose a nested loop over a hash join, who understands that MVCC means every UPDATE writes a new row version and that dead tuples do not clean themselves up if a long-running transaction is holding back the xmin horizon. They know when a partial index beats a composite one, when GIN beats GiST for a JSONB containment query, and why your BRIN index on a randomly-ordered column does nothing at all.

Hiring goes wrong in a specific way here. Postgres is friendly enough that any backend developer can ship features on it for a year without ever hitting a wall. Then the table crosses 50 million rows, or you turn on a read replica and replication lag starts spiking during nightly batch jobs, or connection count climbs past what the server can handle because Django or Rails is opening a connection per worker and nobody put PgBouncer in front of it. The person who built it has no framework for any of this. They start cargo-culting: bumping shared_buffers to half of RAM because a blog post said so, adding NOLOCK-style hints that do not exist in Postgres, or worst, migrating to a different database because "Postgres does not scale." It scales fine. It was configured by someone who had never read the planner output.

The second failure mode is the opposite: hiring a DBA when you needed a developer. A classic Oracle or SQL Server DBA will happily tune your instance and set up backups, and will be completely lost when asked to write a recursive CTE, design a schema for a multi-tenant app with row level security, or reason about how your ORM generates queries. Postgres work in a product company is mostly application-adjacent. You want someone who lives in both the schema and the code.

Engagement models and the honest trade-offs

In-house hire. Makes sense when your database is the hard part of your product: a fintech ledger, an analytics platform, a system with heavy write throughput and strict consistency requirements. A full-time person accumulates context that nobody else can hold, and that context is worth real money when a replica falls over at 2am. The problem is that most companies do not have enough Postgres work to fill a week, let alone a year. You hire a specialist, they fix everything in three months, and then they spend the next nine months writing CRUD endpoints and quietly looking for a new job. Deep Postgres people get bored fast.

Freelancer. Excellent for bounded, diagnosable problems. "Our checkout query is slow." "We need to partition this events table before it hits a billion rows." "Set up logical replication so we can migrate to a new instance with under a minute of downtime." A good freelancer can walk into an unfamiliar codebase, run pg_stat_statements, find the top ten queries by total time, and hand you a plan within a few days. The risk is the deep end of the freelance pool. Postgres attracts people who have read a lot and applied little. Someone who can recite the difference between REPEATABLE READ and SERIALIZABLE but has never debugged a serialization failure under load will produce confident, wrong advice.

Agency. Worth it when the database problem is entangled with the application, which it usually is. The slow query is slow because the ORM is generating it badly, and fixing it means touching the schema, the migration strategy, the caching layer and the API. An agency staffs a Postgres specialist next to a backend developer who can actually change the calling code. You pay a premium for the coordination and for continuity when someone leaves. If your problem is purely operational (backups, failover, monitoring) an agency is overkill and a freelancer or a managed provider is cheaper.

Staff augmentation. A specialist embedded in your team, reporting to your engineering lead, for three to six months. This is the right shape when you have a decent team that has hit a ceiling and needs someone to both fix things and teach. The failure mode is treating the augmented person as a ticket-taker. If you give them Jira tickets instead of ownership of the data layer, you get contractor output at specialist prices.

Rates and what it really costs

These bands are what we pay Postgres people, what we quote for them, and what our clients report being quoted elsewhere. They are not survey data and they move constantly.

Offshore, in Eastern Europe, India, Latin America and Southeast Asia, a competent mid-level developer who is strong on Postgres typically runs $40 to $85 per hour. Below roughly $30 you are almost always buying someone who knows SQL syntax and nothing about the planner, autovacuum, or WAL. That person will write your migrations and will not save you when the database is on fire.

Onshore in the US, UK, Canada or Western Europe, $95 to $180 per hour is the working band for a strong backend developer with real Postgres depth. Specialists who contribute to extensions, have run Postgres at multi-terabyte scale, or can talk credibly about logical decoding internals, command $150 to $250 per hour and up. For a two-week engagement to unbreak a production system, that is cheap. As a permanent staffing model it is not.

On the in-house side, budget well beyond base salary. Payroll taxes, health coverage, equipment, software and the share of office and admin overhead push the real cost meaningfully above base, and when we help clients run that comparison we load the base by 1.25 to 1.4 times for a typical US employer, higher in parts of Europe where employer contributions are steeper. Add recruiting: either a recruiter fee, which on the searches our clients run lands around a fifth of first-year salary, or forty to sixty hours of your engineers' time doing screens and interviews for a role where most candidates fail the technical bar. Then add ramp. A senior person still needs six to twelve weeks to understand your schema, your query patterns and which parts of it are load-bearing. During that time they are net negative on delivery.

The number people miss: the cost of not hiring. A badly indexed database on a managed provider gets fixed by scaling the instance. We have repeatedly seen teams paying four and five figures a month on RDS or Cloud SQL for hardware that exists to cover for a missing index and a missing connection pooler. Two weeks of specialist time often pays for itself in the following quarter's cloud bill.

How to vet a PostgreSQL developer

Skip the SQL trivia. Everyone can write a JOIN. Test the diagnostic loop.

The query plan question. Give them a real EXPLAIN (ANALYZE, BUFFERS) output from your system, ideally one with a bad estimate. Ask them to read it out loud. A strong candidate immediately compares the estimated rows to actual rows, spots where the planner was off by two orders of magnitude, and explains why: stale statistics, a correlated predicate the planner treats as independent, a function call the planner cannot see through. They mention default_statistics_target and extended statistics with CREATE STATISTICS if the columns are correlated. Weak candidates just point at the slowest node and say "that is the problem."

The vacuum question. Ask: "Our table has 10 million live rows but occupies 40 gigabytes. What happened and what do you do?" You want to hear MVCC, dead tuples, bloat, and then the diagnostic path: check pg_stat_user_tables for n_dead_tup and last_autovacuum, check for long-running transactions or abandoned replication slots holding back the xmin horizon, look at whether autovacuum settings are too conservative for the table's write rate, and only then talk remediation: per-table autovacuum tuning, pg_repack rather than a blocking VACUUM FULL on a live system. If their first answer is "run VACUUM FULL," they have never done this on production.

The locking question. "You need to add a NOT NULL column with a default to a table with 200 million rows, zero downtime. Walk me through it." Modern Postgres handles the default without a rewrite, and a good candidate knows which version changed that and will still check yours. They should talk about lock_timeout so a failed ACCESS EXCLUSIVE attempt does not queue behind itself and freeze every reader, adding constraints as NOT VALID then VALIDATE in a separate transaction, and creating indexes with CONCURRENTLY. Ask what happens when CREATE INDEX CONCURRENTLY fails halfway. The answer is an invalid index left behind that must be dropped and rebuilt, and they should know to check pg_index.indisvalid.

The connections question. "Our app opens 800 connections to Postgres. Is that fine?" No. Each connection is a backend process with its own memory. They should reach for PgBouncer or pgpool, and then know the trap: transaction pooling mode breaks prepared statements, session-level SET, advisory locks and LISTEN/NOTIFY. A candidate who says "just use PgBouncer" without naming a single caveat has read the README and not run it.

Take-home. Do not ask them to build a CRUD app. Give them a schema with real problems: a UUID v4 primary key on a huge table causing index write amplification, a text column storing timestamps, a query using OFFSET for pagination on page 5000, an ORM-generated N+1 pattern, and a JSONB column being queried with a path expression and no GIN index. Ask for a written diagnosis with EXPLAIN output and a prioritized fix list, plus the one change they would refuse to make and why. Two to three hours, paid. What you are grading is judgment and sequencing, not whether they found all five.

Portfolio review. Ask for a specific incident. "Tell me about a time a Postgres database broke in production." The good ones have a story with a timeline and a root cause, and they usually admit which of their own decisions caused it. Ask what monitoring they set up afterwards. If the answer does not include pg_stat_statements, they were guessing then and they will guess on your system too.

Red flags

They reach for a different database first. "This should be in Mongo" or "you need Cassandra for this" within the first hour, before reading a single query plan. Almost every scale problem we see at under a few terabytes is a Postgres configuration and schema problem. Ask instead: "What would you need to see before recommending we move off Postgres?" You want a candidate with a threshold, not a preference.

Config tuning by blog post. They immediately suggest raising shared_buffers, work_mem and effective_cache_size to specific numbers without asking about workload, RAM or connection count. work_mem is per sort operation per connection, so a generous setting times 500 connections is an out-of-memory event waiting to happen. Ask instead: "What would you measure before changing any config value?"

ORM-blind. They can write beautiful hand-tuned SQL but have no idea what Prisma, SQLAlchemy, ActiveRecord or Hibernate actually emits. In a product company most of your queries are machine-generated. Someone who cannot read the ORM's output and change the calling code fixes nothing durably. Ask instead: "Show me how you would find the exact SQL your ORM generates for this endpoint."

No opinion on migrations. Ask how they run schema changes against a live database and they describe running a migration file in CI and hoping. No mention of lock timeouts, no mention of expand-and-contract for column renames, no mention of what happens when the migration takes an exclusive lock and 300 web workers pile up behind it. Ask instead: "Describe a migration you rolled back, and how."

Indexes as the universal answer. Every problem gets an index. They cannot articulate the write cost, do not mention that indexes must be maintained on every UPDATE unless the update is HOT, and have never dropped an unused index. Ask instead: "How would you find indexes we should delete?" The answer involves pg_stat_user_indexes and idx_scan, and any candidate with production scars will add that you check the replicas too before dropping anything.

When to hire this role at all, and how Digital Heroes staffs it

If you are pre-product-market-fit with under a million rows and queries returning in under 200 milliseconds, do not hire a PostgreSQL developer. Hire a backend developer with reasonable database instincts and revisit in a year. You do not have a database problem yet, and buying one early just adds a salary.

If your queries are slowing down, your cloud bill is climbing to compensate, or you are about to add read replicas or partition a large table, you need Postgres depth, but almost certainly not full-time. This is where a bounded engagement wins: someone spends two to four weeks doing a real diagnosis, ships the fixes, sets up pg_stat_statements and proper monitoring, writes down the reasoning, and leaves your existing team able to maintain it.

If the database is the product, meaning you are building a ledger, a time-series platform, a data warehouse or anything where correctness under concurrency is the core value, hire in-house and pay properly. Fractional does not work when the schema decisions compound daily.

Digital Heroes staffs this as a pairing rather than a lone specialist. A Postgres-deep engineer works alongside a backend developer who owns the application side, because the fix is almost never confined to the database. We start with a diagnostic pass: pg_stat_statements ordered by total time, index usage stats, bloat and autovacuum health, connection topology, and the actual query plans behind your three slowest user-facing endpoints. That produces a ranked list of what is costing you money and what it takes to fix each item, and you decide what we do. Most engagements start narrow and expand once we have shown you the plan output. You own the schema, the migrations, the code and every diagnostic script we write, in your repository, from the first commit.