Hire SQL developers

SQL is the one skill that outlasts every framework on this list, and hiring for it means testing whether someone can read a query plan rather than only write a query.

What SQL actually is

SQL is the language for querying and manipulating relational data, standardised in principle and dialect-specific in practice. It has outlived a long succession of technologies built to replace it, and it remains the interface to the systems most businesses actually keep their data in. Almost every developer claims it; the range of what that claim covers is wider than for any other skill.

The reason it matters disproportionately is that database work is where application performance is usually won or lost. An application that is slow because of its framework can often be tuned. An application that is slow because of its queries and its schema is slow in a way that gets worse as the business succeeds. By the time that becomes obvious, the schema has years of data in it and changing it is a project.

There is a second, less discussed reason to interview for it properly. Object-relational mappers have made it possible to work with databases for years without reading the SQL they generate. That is a productivity gain and a real skills gap: a developer who cannot read a query plan cannot diagnose the most common category of production performance problem in any stack.

The part that separates seniors from mid-levels

The query planner is the concept that separates levels. You describe what you want, the database decides how to get it, and its decision depends on indexes, statistics and its estimate of how many rows each step will produce. When a query is slow, the answer is in the plan: a sequential scan where an index was expected, an estimate that is wildly wrong, a join order that materialises far more rows than necessary. A developer who reads plans is diagnosing; one who does not is guessing and usually adds an index that does not help.

Indexing is where that knowledge becomes action, and the common mistakes are specific. Column order in a composite index determines which queries can use it. An index on a column that a function is applied to will not be used. Every index makes writes slower and takes space, so unused indexes are a cost with no benefit. Candidates who have removed indexes as well as added them are describing genuine experience.

Transactions and isolation are the third area, and the one most likely to produce bugs that cannot be reproduced. What one transaction sees while another is running depends on the isolation level, and the defaults differ between databases in ways that surprise people moving between them. Lost updates, phantom reads and deadlocks are real, they appear under concurrency rather than in testing, and understanding them is what separates someone who can be trusted with a system handling money.

Where SQL is used

The label “SQL developer” covers several jobs that share a technology and little else. These are the settings the work usually turns up in, and the one you are hiring into should shape the whole process, because the judgement each demands is different.

Application back ends

Every system with persistent data, whether accessed through an ORM or directly.

Analytics and reporting

Warehouse queries over large datasets, where the cost model and the optimisation techniques differ from transactional work.

Data pipelines

Transformation logic expressed as SQL, increasingly the dominant approach over procedural code.

Performance remediation

Diagnosing and fixing slow systems, which is nearly always query and index work rather than application code.

Data migration

Moving and reshaping data between systems, where correctness matters more than elegance.

Financial and regulated systems

Where transactional correctness and auditability are the primary requirements.

If a candidate's experience sits in a different row of that list from the work you have, that is not a reason to reject them, but it is the thing to probe. Ask what would be different about their approach in your setting. Someone who can answer that has transferable judgement. Someone who says it would be much the same has probably not thought about it.

Support status of the tools in this stack

SQL itself is a standard rather than a product, so what matters is the engine and version a team runs and whether it remains supported, which the table below reads from public release data.

SQL itself is not versioned as a single product, so the useful equivalent is the support status of the tools a SQL developer works with daily. The table is read from public release data rather than written by hand, so it states what is supported now. It is worth having in front of you during an interview: asking which of these a candidate has upgraded, and what broke, gets you further than asking how many years they have used each.

Source: endoflife.date public release data, read 2026-09-25. A tool with no published end-of-life dates sets its support boundary by ecosystem practice rather than by policy.

The practical use of this is in judging an estate rather than a person. A team running several of these past their support dates is usually not behind by accident; it is behind because upgrades were never anyone's job. That is worth knowing before you hire, because it tells you whether the first six months will be building new things or paying down what was deferred.

The toolchain around it

Nobody hires for SQL alone. The surrounding tools are where most of the day-to-day work happens, and a gap in any of them costs more time than a gap in the core library. This is the set that turns up most often on real job specifications alongside it.

PostgreSQL

The most common choice for new transactional work, with a rich feature set and strong standards support.

MySQL or MariaDB

Dominant in the content and commerce world, and behind an enormous installed base.

EXPLAIN and query plans

The primary diagnostic tool, and the thing to interview about.

A warehouse

Snowflake, BigQuery or Redshift for analytical workloads with very different performance characteristics.

dbt

Transformation pipelines expressed as SQL with testing and lineage.

Migration tooling

Versioned schema changes, whether framework-provided or standalone.

Connection pooling

Essential at any real concurrency, and a common omission.

Monitoring on slow queries

Statement statistics and slow query logs, which is how problems are found before users report them.

Related skills that frequently appear on the same specification: Python, Java, .NET, Data Engineering, MySQL.

What to test in an interview

These are the topics that separate candidates in practice. Each one is given with why it discriminates, what a strong answer sounds like, and the response that should make you slow down. None of them requires a whiteboard.

Reading a query plan

The single most useful database skill and the one most often missing.

• Strong answer: Can walk through a plan, spot a sequential scan on a large table, notice a bad row estimate, and explain what to do.
• Warning sign: Has never run EXPLAIN, or treats adding an index as the universal fix.

Index design

Where most performance problems are solved, and where many are created.

• Strong answer: Understands composite index column order, knows a function on a column defeats an index, and has removed unused indexes.
• Warning sign: Adds single-column indexes to everything, or believes indexes are free.

The N plus one problem

The most common performance fault in any ORM-based application.

• Strong answer: Recognises it immediately, knows how to find it in a query log, and can explain the fix in their stack.
• Warning sign: Has not encountered it, which usually means nobody has looked.

Transactions and isolation

Where correctness bugs hide, particularly in anything handling money.

• Strong answer: Can explain isolation levels, what a deadlock is, and how they would prevent a lost update.
• Warning sign: Treats transactions as something the framework handles and has never chosen a level.

Schema design

The decision that is hardest to change later.

• Strong answer: Normalises sensibly, denormalises deliberately with a reason, and thinks about how the schema will change under real data volume.
• Warning sign: Designs for the current screen, or normalises to a degree that makes every query a six-way join.

Migrations on large tables

Where database work causes outages rather than slowness.

• Strong answer: Knows which operations lock, adds indexes concurrently where supported, and separates schema change from backfill.
• Warning sign: Has only run migrations on small development databases.

Window functions and set thinking

Distinguishes procedural habits from genuine SQL fluency.

• Strong answer: Reaches for set-based solutions and window functions instead of loops in application code.
• Warning sign: Pulls rows into the application to process them one at a time.

Warning signs in a SQL codebase

The fastest way to read a candidate is to ask what they have found wrong in code they inherited. These are the patterns that come up most often, what they cost, and what fixing them looks like. A developer who recognises three or four of these from their own experience is worth more than one who can recite the documentation.

SELECT star in application code

• What you see: Queries retrieving every column regardless of need.
• What it costs: Unnecessary data transfer, broken assumptions when columns are added, and index-only scans made impossible.
• The fix: Name the columns. It also documents what the code actually depends on.

The N plus one query

• What you see: A loop issuing one query per record, usually generated by an ORM.
• What it costs: Hundreds of round trips where two would do, with latency scaling with data volume.
• The fix: Eager load or join. Log query counts in development so the pattern is visible when written rather than when it hurts.

Functions applied to indexed columns

• What you see: A WHERE clause wrapping the column in a function or a cast.
• What it costs: The index cannot be used and the query falls back to a full scan.
• The fix: Restructure so the column is compared directly, or create an index on the expression where the database supports it.

Indexes added and never reviewed

• What you see: A table with a dozen indexes, several unused.
• What it costs: Every write updates every index, and storage grows for no benefit.
• The fix: Check index usage statistics and remove what is never used. Removing indexes is as legitimate as adding them.

Business logic in the application that belongs in the query

• What you see: Large result sets pulled into the application to be filtered, sorted or aggregated.
• What it costs: Network transfer and memory use proportional to data the user will never see.
• The fix: Filter and aggregate in the database. It was built for this and it has the statistics to do it well.

Schema changes applied without regard for locking

• What you see: A migration altering a large table in a single statement during business hours.
• What it costs: A table lock and an outage during what was planned as a routine deployment.
• The fix: Know which operations lock in your database. Add columns without defaults then backfill, and build indexes concurrently.

What each level can own

Job titles are not comparable between companies, so it is more useful to describe levels by what a person can be left to own without supervision. These are the boundaries we use when we assess a SQL developer.

Junior

Writes queries against an existing schema. Needs review on indexing and on anything inside a transaction.

Mid-level

Owns the data access for a feature, reads plans, designs indexes, and writes migrations that are safe on real data volumes.

Senior

Owns schema design, the indexing strategy, transaction and consistency decisions, and can diagnose a production performance problem from the plan up.

Staff

Owns the data model across services, the migration and partitioning strategy at scale, and the boundary between transactional and analytical systems.

How the work is usually scoped

Team shape follows the kind of work, not the headcount you happen to have budget for. These are the shapes that come up most often and the constraint that actually governs each one.

Performance remediation

• Usual team: One senior engineer, time-boxed.
• What governs it: One of the highest-return engagements available. Usually a handful of queries and indexes account for most of the problem.

Schema design for a new system

• Usual team: One senior engineer with the domain owner.
• What governs it: The most consequential decision in the project and the hardest to revisit once data accumulates.

Database migration between engines

• Usual team: One to two engineers.
• What governs it: Scoped by how much logic lives in stored procedures and engine-specific features rather than by data volume.

Analytical layer build

• Usual team: One engineer with warehouse experience.
• What governs it: Different skill from transactional SQL. Cost models and optimisation techniques do not transfer directly.

Index and query review

• Usual team: One engineer, short engagement.
• What governs it: Quick and usually worthwhile on any system that has grown without review.

Migration work you may actually be hiring for

A large share of SQL work is not new development. It is moving an existing system from one state to another while it stays in service. These are the migrations that come up most often, and each one asks for a different kind of experience from the person you hire.

MySQL to PostgreSQL

• Why teams do it: Richer feature set, better support for complex queries, and stronger standards compliance.
• What to watch: Data types, case sensitivity and stored procedures are where the work is. Scope it by how much logic lives in the database, not by how much data there is.

A self-managed database to a managed service

• Why teams do it: Backups, patching, failover and replication become the provider's responsibility rather than someone's weekend.
• What to watch: Extensions, custom configuration and superuser operations may not be available. Test a full restore from backup before switching, because that is the capability you are actually buying.

Application-side filtering to database-side queries

• Why teams do it: Moving work to where the data and the statistics are, rather than transferring rows to discard them.
• What to watch: Straightforward and high value. The usual blocker is that the application code has accumulated logic that nobody wants to touch, so start with the endpoints that are demonstrably slow.

A transactional database used for reporting to a separate analytical store

• Why teams do it: Reporting queries competing with transactional load is a common cause of unpredictable application performance.
• What to watch: The replication or pipeline is the project, and so is agreeing acceptable data freshness. Doing this before the reports become business-critical is far easier than after.

Migration work rewards a different temperament from greenfield work. The useful question in an interview is not whether someone has done the specific migration you face, but whether they have ever run one incrementally: behind a flag, with both paths live, and with a way back. Developers who have only done big-bang cutovers tend to propose them again.

What a good brief for this role contains

Most of the time lost in hiring a SQL developer is lost before anyone is interviewed, in the gap between what the brief says and what the team actually needs. These are the points that, for this technology specifically, change who the right candidate is. A brief that answers them can be matched in days. One that does not produces a shortlist that looks reasonable and converts badly.

• Which database engine and version, since dialects and locking behaviour differ materially.
• Whether access is through an ORM, direct SQL, or both.
• The size of the largest tables, because this determines whether migrations are routine or hazardous.
• Whether the work is transactional, analytical, or a migration between them.
• Whether there is an existing performance problem, which makes this a diagnosis engagement rather than a development one.
• Who currently owns schema changes and how they reach production.

If you cannot answer some of these yet, that is normal and it is still worth writing down which ones are open. An unknown that is named can be worked around. An unknown that is papered over in a job specification turns into a rejected shortlist and a restart four weeks later.

What the US market pays for this work

SQL work is counted by the US Bureau of Labor Statistics under Database Administrators. That classification is broader than the technology itself, so treat the figures as the shape of the market a SQL developer is hired into rather than as a rate card for the skill. Across the United States the Bureau counts 69,990 people in this occupation, with a median annual wage of $104,620.

The spread matters more than the midpoint. The 90th percentile is about 2.7 times the 10th, which is a wide band for a single occupation and tells you that the title on its own carries very little pricing information. Two people described as a SQL developer can sit at $60,230 and $163,320 in the same national dataset. When a budget is set from a median without asking which end of that range the work actually needs, the hire that follows is usually the wrong one in one direction or the other.

Related classifications are worth reading alongside it, because teams hiring for SQL frequently end up recruiting against these titles too:

Source: BLS Occupational Employment and Wage Statistics, May 2025. Figures cover all US employers and are not FuturByte rates.

These are employer-side wage figures for people on a US payroll. They exclude employer taxes, benefits, recruitment cost and the months a seat sits empty, all of which are real and none of which appear in a salary line. The useful way to read the table is as the cost of the alternative you are comparing against, not as a number to match.

How US metro markets compare for this role

The same job is priced very differently across the country. Ranked by median annual wage for Database Administrators, the gap between the highest and lowest of the 27 metro areas covered here is a factor of about 1.4. San Jose sits at the top with a median of $138,620; Minneapolis-St. Paul sits at the bottom with $101,610. A budget built from a national median will be wrong in both of those markets, in opposite directions.

Location quotient compares how concentrated this occupation is in the metro against the national average. A value above 1 means the metro has more of this work than its size would predict.

The location quotient column is the more useful one for hiring. A high median tells you what a role costs; a high quotient tells you whether the people exist. Boston, Austin, Baltimore, Raleigh, Washington, D.C. each have a quotient of 1.5 or above, meaning the work is concentrated there well beyond what the size of the local economy would predict. Those are the markets where a search is likely to be quick and competitive at the same time, and where a counter-offer is most likely to take a candidate off the table late in the process.

The opposite case is worth planning for too. In a metro with a low quotient, the total pool is small even when wages look reasonable, so the realistic options are to widen the search radius, accept a longer time to hire, or bring the capability in from outside the local market entirely. That last option is what most teams are weighing when they come to us.

Hiring risks worth naming

Every one of these has produced a bad hire somewhere. They are written down so that the process tests for them deliberately rather than discovering them in month three.

ORM experience presented as SQL experience. Ask them to read a plan. This is the most common and most consequential gap in the market.

Development-scale experience only. Ask about a migration on a large table. Everything is fast with ten thousand rows.

Transactional skills applied to analytics. Warehouse optimisation is a different discipline. Be explicit about which you need.

No production diagnosis experience. Ask about a slow query they fixed and how they found it. Vague answers here are very informative.

Hiring SQL developers by metro area

Wages for this occupation vary more between US metro areas than most budget models assume. Each page below sets out the published employment and wage figures for that market, how it compares with the national picture, and what the local industry mix means for the kind of SQL developer who will be available.

• New York, NY $121,550 median
• Seattle, WA $133,180 median
• San Jose, CA $138,620 median
• Washington, D.C. $108,750 median
• San Francisco, CA $127,760 median
• Dallas-Fort Worth, TX $122,390 median
• Los Angeles, CA $112,540 median
• Boston, MA $132,370 median
• Chicago, IL $109,680 median
• Atlanta, GA $110,950 median
• Austin, TX $123,830 median
• Phoenix, AZ $104,280 median
• Philadelphia, PA $104,930 median
• Minneapolis-St. Paul, MN $101,610 median
• Denver, CO $120,120 median
• Detroit, MI $110,160 median
• Houston, TX $116,030 median
• Charlotte, NC $113,890 median
• San Diego, CA $106,820 median
• Salt Lake City, UT
• Miami, FL $105,590 median
• Portland, OR $103,110 median
• Baltimore, MD $123,730 median
• Tampa, FL $124,560 median
• Orlando, FL $115,100 median
• Raleigh, NC $122,950 median
• Kansas City, MO $103,640 median
• Pittsburgh, PA $102,070 median

Frequently asked questions

Do our developers need SQL if we use an ORM?

Yes, and arguably more than before. ORMs make it easy to write code that produces poor queries without noticing, and when something is slow the diagnosis is in the generated SQL and its plan. A team where nobody can read a query plan cannot fix the most common category of performance problem, regardless of how good the rest of their engineering is.

PostgreSQL or MySQL?

PostgreSQL for new work in most cases: a richer feature set, stronger standards compliance and better support for complex queries and data types. MySQL where you are already there, or where the surrounding ecosystem assumes it, which in the content and commerce world it frequently does. Both are capable, and the decision is usually settled by what your platform and team already know.

Why is our application slow when the server looks fine?

Nearly always queries. A database server can appear unremarkable on CPU and memory while individual queries take seconds because of a missing index or an inefficient plan. Enable slow query logging or statement statistics, look at the worst offenders, and read their plans. This is usually a day of work and frequently the highest-return day available.

Should business logic live in the database?

Some of it, and less than it used to. Constraints, foreign keys and uniqueness belong there, because they are correctness guarantees that no amount of application discipline reliably replaces. Extensive stored procedures are a different matter: they are harder to test, version and review, and they make migrating between engines expensive. The useful line is integrity in the database, behaviour in the application.

How do we handle schema changes on a large table?

Carefully, and with knowledge of what locks in your specific database. The general pattern is to avoid operations that hold long locks: add columns without defaults and backfill separately, build indexes concurrently where supported, and split a change into several safe steps rather than one convenient one. Test against a copy at production scale, because a migration that takes a second on a development database may take an hour.

Is NoSQL a better choice for us?

Sometimes, and less often than it is chosen. Document and key-value stores genuinely suit some access patterns, particularly where the shape of the data varies or where horizontal scale matters more than query flexibility. What often happens instead is that a team picks one to avoid schema design, then reimplements joins in application code. If your data has relationships and you will want to query it in ways you cannot predict, relational is usually right.

How many indexes is too many?

There is no fixed number, and the test is usage. Every index costs write performance and storage, so an index nothing uses is pure overhead. Most databases expose index usage statistics. Reviewing them on a table that has accumulated indexes over years frequently finds several that can be removed, which speeds up writes at no cost.

Do we need a database specialist?

For most teams, no, provided the developers can read plans and design indexes. A specialist earns their place when data volume is large enough that ordinary techniques stop working, when there is a serious performance problem nobody can diagnose, or when a migration between engines is on the table. A short specialist engagement on a struggling system is often better value than a permanent hire.