Hire SQL Developers: Rates, Vetting and Engagement Models

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

It is Tuesday morning. The executive revenue dashboard in Power BI takes 41 seconds to render, and when the CFO finally sees the number it is about 3 percent off what Stripe says. Someone opens the underlying view and finds it is a view on a view on a view, seven layers deep, and at the bottom there is a join to a subscription table that silently doubles every row for any customer who ever changed plans. Nobody knows when that broke. Nobody can prove it was ever right.

That is the work nobody was doing. A SQL developer on a business intelligence project is not there to write SELECT statements. They are there to take raw application tables, Fivetran or Airbyte landing schemas and event streams, and turn them into a model a BI tool can query fast and correctly: fact tables at a declared grain, dimensions that hold their history, metric definitions that survive contact with a finance team. Then they keep the thing fast as it grows from two million rows to two hundred million.

Hiring goes wrong in three predictable ways. First, teams hire for syntax. A candidate writes a clean window function and a common table expression on the screen, gets the offer, and then produces the seven-layer view stack above, because writing a query and designing a model are different skills. Second, teams hire an analyst and expect an engineer. Someone who is excellent at ad hoc questions in Metabase may have never owned an incremental refresh, a backfill or a schema migration. Third, teams hand it to a backend engineer who "knows SQL" and then wonder why the dashboard is built on a flat 90 column table that Power BI chokes on.

Engagement models: in-house, freelancer, agency, staff augmentation

In-house hire. Right when you have at least two years of continuous data work ahead, sensitive data you cannot move, and someone who will own the semantic layer as a permanent asset. The honest downside: this is a narrow market and the search takes real time, and a single SQL developer with no peer to review them will drift. There is nobody to catch the fanout join. If you go in-house, budget for either a second data person or an external review cadence.

Freelancer. Right for bounded work with a clear finish line. Tune the ten worst queries. Migrate SSRS reports to Power BI. Rebuild one dashboard properly. The downside is ownership: when they leave, the model has no maintainer, and most freelancers are strong at either modeling or the BI tool, rarely both plus warehouse operations. Freelancers also work in gaps between clients, so a two week job can stretch to six.

Agency. Right when you need modeling, pipeline, BI and documentation delivered as one thing, and you want a single accountable party when the number is wrong. You pay more per hour than a freelancer and you should. The trap is renting the model forever: write knowledge transfer into the contract, insist the dbt project and the warehouse live in your accounts, and require a walkthrough your own team can follow.

Staff augmentation. Right when you have an internal lead, a data lead or a technical founder, who can direct the work but has no hands free. The augmented developer plugs into your standup, your repo, your ticket queue. The downside is that this model needs your direction. Without a lead it degrades into vague tickets and a developer quietly building whatever seems reasonable, which is how you get three different definitions of active customer.

What SQL developers cost

These are the ranges we quote in Digital Heroes delivery and the offers our clients tell us they are competing against. Rates move with region, seniority and how much of the stack the person owns, so treat these as bands, not price tags.

• India and South Asia, mid level, comfortable with dbt and a cloud warehouse: roughly $25 to $45 an hour through an agency.
• Senior offshore who owns dimensional modeling and query tuning end to end: roughly $45 to $70 an hour.
• Eastern Europe and Latin America: roughly $45 to $85 an hour.
• US, UK and Australia contract senior: roughly $95 to $180 an hour, with Snowflake and BigQuery cost optimization specialists at the top of that band.
• Open marketplace freelancers: $20 to $60 an hour, with the widest quality spread of any option here.
• US in-house base salary, from the offers clients show us: roughly $90,000 to $120,000 mid level, $130,000 to $170,000 senior.

The in-house number is the one people underestimate. Base is not the cost. Payroll taxes, health coverage, equipment and paid time off push the real number well above base, and the planning multiple we use when helping clients compare options is 1.25x to 1.4x depending on geography and benefits. On top of that: the recruiter fees our clients quote us land around a fifth of first year salary, and a new hire needs six to ten weeks before they are productive on your schema, because your schema is undocumented and the tribal knowledge lives in Slack. Add tool seats too, a dbt Cloud seat, Power BI Premium or Fabric capacity, and the warehouse credits their queries burn while they learn.

Which points at the number nobody puts in the budget: warehouse spend. A badly modeled Snowflake or BigQuery setup can cost more per month than the developer does. We have taken over projects where a single dashboard filter fired a full scan of an unpartitioned 400 million row table every time someone changed a date range. A SQL developer who understands partition pruning, clustering and result caching often pays for their own rate out of the credit line alone.

How to vet a SQL developer

Skip the trivia. Test the four things that actually break.

Can they read an execution plan? Paste real output: EXPLAIN (ANALYZE, BUFFERS) from Postgres, or an actual plan from SQL Server. Ask what is wrong. A good answer names the specific thing: a nested loop with a wrecked row estimate, a hash join spilling to disk, a sequential scan because the predicate is wrapped in a function so the index is not sargable, a key lookup that a covering index would remove. A weak answer says "it needs an index."

Do they think in grain? Ask: here are orders, order_items, refunds and a subscriptions table, design the fact table for a revenue dashboard, what is the grain and why. Listen for the questions they ask before answering: partial refunds, currency, whether a cancelled then reinstated subscription counts, whether the finance team recognizes revenue on charge or on delivery. Someone who starts writing SQL immediately has never had a CFO disagree with them.

Do they know what history does to a dimension? Ask what happens to last quarter's dashboard when a customer moves sales region. If the answer is not "depends on whether that dimension is type 1 or type 2, and what the business wants to see," they have never been burned by slowly changing dimensions, which means they will burn you.

Warehouse specifics, matched to your stack. Snowflake: clustering keys, warehouse sizing, result cache, why SELECT * on a wide table is expensive on columnar storage. BigQuery: partitioning and clustering, partition pruning, why joining on a non-partitioned key scans the whole table, slot contention. Postgres serving BI directly: materialized views, refresh strategy, and when to admit you need to move off. On dbt, ask about incremental models and late arriving records, unique_key behavior, when a full refresh is required, and which tests they write. The best answer to "how would you catch a fanout join that silently doubles revenue" is a uniqueness test at the declared fact grain plus a reconciliation count against source.

The take-home. Do not ask for a dashboard. Give them a dump of five or six deliberately messy tables: nullable foreign keys, duplicate rows from a connector resync, orders in three currencies, a soft delete column, timestamps in UTC while the business reports in local time. Give them one business question, for example monthly net revenue by region for the last 24 months split by new versus returning. Three hours. Pay for it.

Grade the process, not the output. Did they ask questions before writing anything? Did they write down their definition of net revenue? Did they find the duplicates, and can they tell you how they found them? Is there a sanity check reconciling their total back to a source table? Are the CTEs named for what they contain rather than cte1 and cte2? Did they notice the currency problem at all, because most candidates do not. For a portfolio review, ask them to walk through a model they built and name one decision they would make differently now, plus the runtime or cost before and after. People who have shipped have numbers.

Red flags

• "I would just add an index." Ask instead: which columns, in what order, and show me the plan after. And what does that index cost you on writes and on storage?
• Views stacked on views with no materialization strategy. Ask instead: how many layers deep do you go before you materialize, and what decides it, freshness requirement or query cost?
• Never mentions money. Ask instead: the last time you cut warehouse spend, what exactly did you change and by how much? Candidates who only worked where compute felt free will design like compute is free.
• Cursors and row-by-row loops for set operations, or pulling data into pandas because they cannot express it in SQL. Ask instead: when do you deliberately leave SQL, and why?
• Cannot define a metric. Ask instead: how do you define an active customer, and who signs off on that definition? If they think that is somebody else's job, your dashboards will keep disagreeing with each other.

When to hire a SQL developer, and how Digital Heroes staffs it

Do not hire this role if your real problem is that data is not arriving. Broken connectors, orchestration and API ingestion are a data engineer's job, and hiring a modeler to fix Airflow wastes both of you. Do not hire this role if the real problem is that nobody has decided what to measure. That is an analyst or an ops lead with business authority. And if you have five employees and three tables in Postgres, point Metabase at a read replica and spend the money on something else.

Hire a SQL developer when you have a warehouse, more than a handful of source systems feeding it, and dashboards that are either slow, expensive or quietly wrong. That combination does not fix itself and it gets more expensive every month you leave it.

Digital Heroes staffs this as a pair rather than a lone hire. A modeling-led SQL developer owns the fact and dimension design, the dbt project and query performance, and a part-time BI specialist handles the last mile in Power BI, Looker or Metabase, because the skills diverge at that boundary. We start with a two to three week paid scoping block: audit the existing model, rebuild one real dashboard end to end so you can see the working method, and set a cost and runtime baseline you can hold us to. Everything lives in your repo, your warehouse and your accounts from day one, and the models, tests and documentation are yours whether you extend the engagement or not.