If you're working out how to hire SQL developers, the first problem is that "SQL developer" means three different jobs on job boards. One person designs schemas and tunes the queries your application runs. Another keeps a database server alive, patched and backed up. A third moves data from your product into a warehouse. Post one ad for all three and you'll get applicants who are strong at whichever job they happened to have last. It's part of our series Hire developers by tech stack: rates, vetting and interview guides.
Which hire do you need: SQL developer, DBA or data engineer?
These are our working definitions, not an industry standard. Titles overlap at small companies, where one person does two of the three. At that point, decide which job gets the first month.
| Role | Owns | Typical first deliverable | Not this role |
|---|---|---|---|
| SQL developer | Schema design, queries, indexes and migrations for an application's database | A reviewed schema change or a slow-query fix with before and after plans | Running servers, backups and failover |
| Database administrator (DBA) | The database service: availability, backups, patching, access, capacity | A tested restore and an upgrade plan | Writing application queries day to day |
| Data engineer | Pipelines that move and transform data into a warehouse or lake | A reliable daily load with checks on it | Tuning the production OLTP database |
The practical split is workload. If your application is slow or your schema is fighting you, hire the developer. If the risk is losing data or running an unsupported server, hire the DBA. If analysts can't trust the numbers, you need a data engineer, and the data engineer hiring guide covers pipelines, idempotency and warehouse cost, none of which we repeat here.
Which database and version should the job description name?
SQL is a standard, but the engine isn't. Postgres, MySQL and SQL Server differ in locking behaviour, index types, procedural languages and tooling. Require one engine deeply, then ask how the candidate would transfer to yours. Someone with six years of Postgres can learn SQL Server, but they'll be slower for a few months and you should say so up front.
The version matters as much as the engine, because a hire inherits whatever you're running. This is where support dates stand as of 2 October 2026.
| Engine and version | Support status |
|---|---|
| PostgreSQL 18 | Final release 14 November 2030 |
| PostgreSQL 17 | Final release 8 November 2029 |
| PostgreSQL 16 | Final release 9 November 2028 |
| PostgreSQL 15 | Final release 11 November 2027 |
| PostgreSQL 14 | Final release 12 November 2026 |
| PostgreSQL 13 | Unsupported since its final release on 13 November 2025 |
| MySQL 8.0 | Under Oracle Sustaining Support since 21 April 2026 |
| SQL Server 2019 | Mainstream support ended 1 March 2025, extended support ends 9 January 2030 |
| SQL Server 2022 | Mainstream support ends 12 January 2028, extended support ends 12 January 2033 |
The PostgreSQL dates come from the project's versioning policy page, which says the project "supports a major version for 5 years after its initial release". It ships a new major version about once a year and minor releases at least every three months. PostgreSQL 14 stops getting fixes in about six weeks. If you're on 14 or older, your next hire inherits an upgrade, so put it in the job description. What to test before the next major release lands is covered in what to test before PostgreSQL 19 reaches GA.
For MySQL, Oracle's end-of-life notice puts 8.0 under Sustaining Support from 21 April 2026 and encourages a move to 8.4 LTS or 9.7 LTS. For SQL Server, Microsoft publishes the dates on separate lifecycle pages: SQL Server 2019's lifecycle entry and the SQL Server 2022 page.
A candidate who has only run a version that's already out of support has never done the hard part of the job, which is moving a live system forward.
What separates a senior SQL developer from someone who writes queries
Plenty of developers can write a JOIN. Seniority shows in what they do when the table has 400 million rows and the deploy can't take the site down. The general markers of seniority in backend work are in what separates senior backend developers from mid-level ones. Below is what's specific to databases.
Schema design and constraints
A senior developer normalises by default and denormalises on purpose, with a reason they can state. They put rules in the database: primary and foreign keys, NOT NULL, unique and check constraints. Application code gets bypassed by scripts, imports and the next service someone writes. Constraints don't. Ask where uniqueness of an email address is enforced, and be wary of any answer that stops at "in the app."
Reading query plans
They run EXPLAIN before they guess. They can tell a sequential scan that's fine (small table, most rows needed) from one that's a bug, and they know when an index won't help: low-selectivity columns, functions wrapped around the indexed column, stale statistics. They also know the tool has a sharp edge. In Postgres, the EXPLAIN documentation warns that "the statement is actually executed when the ANALYZE option is used", so a candidate who runs EXPLAIN ANALYZE on an UPDATE against production without wrapping it in BEGIN and ROLLBACK has just changed your data.
Migrations on a live table
None of the six competitor hiring pages we read on 2 October 2026 explains how to test for it. A senior developer uses expand-and-contract: add the new column nullable, deploy code that writes both, backfill in batches, switch reads, then drop the old column in a later release. They also know that index builds lock. In Postgres, a standard build "locks out writes (but not reads)", while CREATE INDEX CONCURRENTLY builds "without taking any locks that prevent concurrent inserts, updates, or deletes", according to the CREATE INDEX reference. The same page notes that the concurrent form can't run inside a transaction block and that a failure leaves an invalid index behind to clean up. Someone who has done this knows all three facts. Someone who hasn't will tell you migrations are "just a script."
Transactions, isolation and locking
Ask what isolation level their last system ran at and what anomaly that allowed. A good candidate can describe a lost update or a deadlock they actually hit, how they found it, and what they changed: lock ordering, shorter transactions, SELECT ... FOR UPDATE, or a retry loop. Reciting the four isolation level names proves nothing.
ORM literacy
In many applications, the SQL is generated by an ORM such as SQLAlchemy or Hibernate. A senior developer reads the SQL the ORM emits, spots the N+1 pattern (one query for the list, then one per row for an association), and knows when to drop to hand-written SQL. They don't treat the ORM as the enemy. They treat it as a tool whose output they're responsible for.
How to vet an SQL developer in four stages
This sequence is our own editorial guidance, not a sourced standard. Each stage filters for something the one before can't.
1. Run a scoped screening call
Spend 20 minutes. Ask which engine and version their last system ran, how big the largest table was, and what the slowest query they fixed looked like. Specifics (a row count, a version, an index type) are the signal. "We used Postgres for the backend" is not.
2. Give them a plan to read
Send a slow query, the table definitions, and the EXPLAIN output (not ANALYZE, which would mean running it). Ask for a written diagnosis in 30 minutes. A strong candidate finds the sequential scan or the bad join order, proposes an index with the column order justified, and says what they'd measure after. A weak one suggests adding an index on every column in the WHERE clause.
3. Ask for a migration design on a live table
Give them a table with 200 million rows that's taking writes all day, and ask them to split one name column into first_name and last_name with no downtime. Listen for expand-and-contract, batched backfill, a rollback path, and CONCURRENTLY or the engine's equivalent for any index. If they never mention what happens to writes during the backfill, they haven't done this under load.
4. Have them review a schema for planted defects
Hand over a 10-table schema with three defects: a missing foreign key, a column storing comma-separated IDs, and a money value in a floating-point type. Ask for a review as if it were a pull request. Strong candidates find all three and rank them by blast radius. Bonus points for a defect you didn't plant.
Interview questions that expose depth
These are our suggestions, and the strong-answer notes are what we'd listen for.
- An endpoint got slow after a data import. How do you find out why? A strong answer starts with the plan, then checks statistics and row estimates before touching an index.
- When would an index not be used even though it exists? Look for low selectivity, expressions wrapped around the column, type mismatches and stale statistics.
- How do you add a NOT NULL column to a large live table? Strong answers add it nullable, backfill in batches, then enforce the constraint, and know what their engine does on a plain
ALTER TABLE. - Describe a deadlock you've debugged. They should name how they found it (engine logs, lock views) and the fix, not only define the word.
- Where do you enforce data integrity, the app or the database? The right answer is "the database for anything that must never be violated, and the app for friendly error messages."
- What does your ORM do when you load a list and then touch a related object on each item? You want N+1 named without prompting, plus at least two fixes.
- Tell me about a database upgrade you ran. Good answers include what broke, how they rehearsed it, and how they would have rolled back.
Which data does the hire touch? GDPR and where the engineer sits
An SQL developer or DBA works near your most sensitive data. Production tables often hold names, emails, addresses and payment references. Before you pick a vendor or a freelancer, get straight answers to four questions. Will this person have read access to production, or only to a masked copy? Can they work on staging data that's been anonymised? Where does the engineer physically sit? And what contract covers their access to personal data? Of the six top-ranking hiring pages we read on 2 October 2026, five don't raise any of it, and the sixth lists GDPR only as a certification, so the buyer has to ask.
If personal data is involved, your data processing agreement needs to cover the engineer's access. We don't give legal advice here, and the right answer depends on your setup, so get your counsel involved before the person gets credentials. The cheapest control is also the best one: give developers a masked copy of production and keep real access with a small number of named people.
What drives SQL developer cost
We aren't quoting a general range because we don't hold a dated, primary rate source for SQL in Europe, and a made-up number is worse than none. What moves the price is predictable. Seniority is the biggest driver: someone who can design a zero-downtime migration costs more than someone who writes reports. The engine matters, and so does whether the role carries on-call duty, which a DBA often does and a developer often doesn't. Engagement model and margin disclosure matter too.
For one dated data point, Lemon.io's SQL developer page gave two sets of figures when we read it on 2 October 2026: a headline range of $40-$90 per hour, and a seniority table of £35-£55 (junior), £60-£90 (mid-level) and £100-£130 (senior, 7+ years). Even one vendor's page doesn't give a single answer, so treat neither as a market rate. Other top results quote salaries rather than rates, and only for the US, UK, Australia and Canada: HackerEarth cites 2025 Glassdoor figures, and Adaface's guide is dated December 2024. Ask any vendor to separate what the engineer earns from what the vendor adds before you compare quotes.
Freelance, in-house or staff augmentation for database work
Bounded work suits contractors: a query-tuning audit, a major version upgrade, a one-off migration with a clear finish line. In-house suits ownership of a live system, because the person who carries the history of why a table looks the way it does saves you from repeating mistakes. Staff augmentation sits between the two when the work runs for months and you don't want a permanent seat yet.
Managed databases change the DBA question. On managed services such as Amazon RDS or Cloud SQL, the provider runs backups and routine patching, and failover too if you configure high availability, so you rarely need a full-time DBA. You still need someone who owns schema design, query performance, access control and cost, and that's usually a developer with strong database skills plus a cloud engineer. The cloud engineer hiring guide covers where that second role starts.
FAQ
What is the difference between an SQL developer and a database administrator?
An SQL developer works inside the database: schemas, queries, indexes, migrations. A DBA runs the database as a service: availability, backups, patching, access and capacity. Small teams combine them in one person, but the failure modes differ. A developer's mistakes usually show up as slow queries or a migration that blocks writes, while a DBA's show up as downtime or lost data.
What is the difference between an SQL developer and a data engineer?
An SQL developer works on the database your product runs on. A data engineer builds the pipelines that copy and reshape that data for analytics. Both write SQL, but a data engineer's day is about scheduling, backfills and warehouse cost, while an SQL developer's is about the production schema and query plans.
Which database should I hire for: PostgreSQL, MySQL or SQL Server?
The one you already run. Core SQL skills transfer, but locking, indexing and tooling don't transfer for free, so require one engine deeply and ask how the candidate would learn yours. If you're choosing an engine for a new system, hire for the engine you'd pick, and check the version table above so you don't start on one near end of support.
How do I test an SQL developer's query-tuning skill?
Give them a slow query, the table definitions and the EXPLAIN output, and ask for a written diagnosis in 30 minutes. Strong candidates find the scan or join problem, justify an index, and say how they'd measure the result. Don't give them EXPLAIN ANALYZE on a write statement against a shared database, since it executes the statement.
Do I need a DBA if my database runs on a managed cloud service?
Usually not full time. The provider runs backups and routine patching, and failover if you've enabled high availability. You still need someone accountable for schema design, slow queries, access and upgrades, and that can be a senior SQL developer. Bring in a part-time or contract DBA for audits, major version moves and capacity planning.
Does an SQL developer need to know an ORM like SQLAlchemy?
If your application uses one, yes. In that case much of your SQL is generated by it, so the developer must read the emitted queries, spot N+1 patterns and know when raw SQL is the better tool. A candidate who knows SQL well but has never used your ORM can learn it in weeks. The reverse, an ORM user who can't read a query plan, takes much longer.