Where do I list SQL on a resume?

Put SQL in your skills section, with the dialect or tools next to it (for example PostgreSQL, BigQuery, dbt). Then prove it in your experience bullets by saying what the queries produced. A skills line alone is easy to ignore; a bullet with a result is evidence.

Should I put SQL on my resume if I only know basics?

Yes, if you can write SELECT, JOIN and GROUP BY queries without help and the job asks for SQL. Label it honestly, for example 'SQL (basic: joins, aggregation)', and back it with a course project or a real task. Expect a SQL question in the interview and be ready to answer it.

How do I show my SQL level on a resume?

Name what you have actually done instead of using a label like 'expert'. Window functions, CTEs, query tuning, schema design and dbt models all signal depth. Add the dialect and the size or purpose of the data, such as a weekly dashboard or a pipeline that runs daily.

Do I need to list SQL dialects like PostgreSQL or MySQL?

Yes. The dialects differ in date functions, window behaviour and performance tuning, so naming the ones you have used in real work tells the reader more than 'SQL' alone. List only the ones you could work in tomorrow.

Should SQL be a separate section or part of a skills list?

For most roles, a line in the skills section is enough. If SQL is central to the job, such as data analyst or analytics engineer, give it its own row (for example 'Databases and query languages') and mention it in at least two experience bullets.

How do I check if my resume shows the SQL a job ad asks for?

Paste the job ad and your CV into NextCV's free job match tool at /en/job-match. It is deterministic, needs no signup, and shows which keywords from the ad your CV does not yet mention.

How to Put SQL on Your Resume (With Examples)

To put SQL on your resume, list it in your skills section with the dialect or tools beside it (for example "SQL: PostgreSQL, BigQuery"), then prove it in one or two experience bullets that say what your queries produced. Add a level only if you can back it up, such as "basic", "working" or "advanced". This works for any role that touches data, from marketing and finance to engineering, not only for analysts.

Analysts will find the role-specific detail further down.

Where SQL Goes on a Resume

Skills section. Write "SQL" with the dialect and one signal of depth: "SQL (advanced): BigQuery, Snowflake, dbt, window functions". A bare "SQL" tells the reader nothing about which kind of SQL user you are.

Experience bullets. This is where the claim becomes believable. If SQL was part of your work, name it in at least one bullet per relevant role, with the system and the outcome. If it was central to the job, use two or more.

Projects. If you have a GitHub repo with SQL, a dbt project or a public dashboard (Looker Studio, Tableau Public), link it. This matters most for beginners and career changers, who have fewer work bullets to point at.

Not sure whether your CV shows the SQL a particular job ad asks for? Paste both into the free job match tool. It is deterministic and needs no signup, and it shows which terms in the ad your CV does not mention yet.

How to Show Your SQL Level Honestly

Skip labels like "expert" and describe what you have done. Interviewers often test SQL live, so a claim your answers cannot support costs you more than a modest claim would.

Basic: SELECT, WHERE, JOINs, GROUP BY. Say "SQL (basic)" or list the operations.
Working: CTEs, subqueries, CASE expressions, date handling, window functions like ROW_NUMBER. Say "SQL (working)" and name the dialect.
Advanced: Query plans and indexing, schema design, dbt models, performance work on large tables. Say "SQL (advanced)" and give a bullet with proof.

Example SQL Bullets by Level

These are illustrations. Swap in your own tools and numbers, and never use a figure you cannot defend in an interview.

Beginner or career changer: Wrote JOIN and GROUP BY queries in PostgreSQL to analyse a public dataset of 200,000 rows for a portfolio project; published the queries and findings on GitHub.

Non-data role (marketing, operations, finance): Pulled weekly campaign data with SQL from the company warehouse instead of waiting on a report request; cut turnaround on channel reviews from two days to same-day.

Analyst: Built 30 production SQL queries in BigQuery feeding the weekly executive dashboard, including a cohort retention analysis using window functions that identified the segment driving most churn.

Engineer or analytics engineer: Rewrote slow Redshift queries using EXPLAIN plans and sort keys, and moved reporting models into dbt with tests; daily pipeline run time dropped from 4.5 hours to under 1 hour.

For Analysts: What Hiring Managers Actually Test For

Before worrying about how to present SQL on your CV, it helps to understand what interviewers expect at different levels:

Mid-level analyst (3–5 years): Comfortable joins (INNER, LEFT, FULL OUTER, CROSS), aggregation with GROUP BY and HAVING, subqueries, CTEs (WITH clauses), basic window functions (ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD), date arithmetic, CASE expressions. Can write readable, maintainable queries.

Senior analyst (5+ years): Advanced window functions (PARTITION BY with ordered frames), recursive CTEs, query performance intuition (indexes, query plans, scan vs seek, partition pruning), working knowledge of the dialect differences between PostgreSQL, BigQuery, Snowflake, and Redshift. Can design schemas (star schema, fact/dimension tables), write data quality checks, and build modular SQL with dbt.

Principal / analytics engineer: Deep schema design, understanding of columnar storage and query optimisation in MPP databases, orchestration of SQL-based pipelines, governance over SQL conventions in a team.

Your CV should reflect your actual level honestly, and your bullets should prove the level you claim.

How to Quantify SQL Work on a CV

The challenge with SQL is that the work often feels invisible — you wrote a query, someone got a dashboard, business moved on. The discipline is to trace what your SQL enabled, not just describe the SQL itself. The figures in the examples below are made up to show the shape of a good bullet; use your own.

Before: Wrote SQL queries to analyse customer data.

After: Built a suite of 40+ production SQL queries in BigQuery powering the weekly executive dashboard — including a customer lifetime value calculation across 5M+ rows using window functions and a churn cohort analysis that identified three distinct behaviour segments; findings led to a targeted re-engagement campaign generating £180K in recovered ARR.

Before: Used SQL for data extraction and reporting.

After: Migrated 14 legacy Oracle SQL reports to a Snowflake + dbt architecture; refactored correlated subqueries into CTEs and materialised intermediate models, reducing average query runtime from 8 minutes to 22 seconds and eliminating a recurring monthly reporting window that had blocked the finance team for two days.

Before: Optimised slow queries in the data warehouse.

After: Identified and resolved three critical query bottlenecks in Redshift using EXPLAIN plans; added sort keys and distribution keys to two core fact tables, converted three full-table scans to partition-pruned queries — reduced daily pipeline completion time from 4.5 hours to 55 minutes, cutting compute costs by $2,100/month.

SQL Tools and Ecosystem: What to List

SQL does not exist in isolation. The tools around it matter as much as the language itself:

Warehouse dialects: PostgreSQL, BigQuery (Standard SQL), Snowflake (SQL), Redshift, SQL Server (T-SQL), MySQL, DuckDB (increasingly relevant for local analytics). Note which dialects you have production experience with — they differ meaningfully in window function behaviour, date functions, and performance tuning approaches.

Transformation tooling: dbt (data build tool) is now a near-universal expectation for analytics engineering roles and increasingly expected for senior analyst roles. If you have written dbt models, tests, and documentation — say so. Note whether you have used dbt Cloud or dbt Core.

Query interfaces: Tableau, Looker (LookML), Mode, Redash, Metabase, Apache Superset. If you have written SQL that feeds BI tools, mention the tool — it signals the downstream user of your work.

Orchestration: Airflow, Prefect, dbt Cloud Scheduler, AWS Glue. If your SQL runs in a pipeline, note what orchestrates it.

Version control for SQL: SQL in dbt models under Git is a genuine engineering practice. Mentioning this distinguishes an analytics engineer from someone running ad-hoc queries in a browser.

Certifications and Credentials

SQL certifications are plentiful but not universally respected. The ones worth listing:

dbt Certified Analytics Engineer: A legitimate and increasingly recognised credential for analytics engineering roles. Worth pursuing if you work with dbt.
Google Professional Data Engineer: Requires strong BigQuery SQL and data pipeline knowledge — carries meaningful weight for GCP-focused roles.
Snowflake SnowPro Core / SnowPro Advanced: Data Engineer: Credible for Snowflake-heavy roles, especially in companies that have standardised on the platform.
Microsoft Certified: Azure Data Engineer Associate (DP-203): Relevant for SQL Server and Azure Synapse environments.
HackerRank / LeetCode SQL certifications: Useful for entry-level candidates but low signal for experienced analysts — interviewers will probe SQL in the interview regardless.

For most mid-to-senior analyst roles, a strong portfolio of SQL work visible in your experience bullets outweighs any certification. Certs supplement; they do not substitute.

Common Mistakes That Weaken SQL CVs

"Proficient in SQL" without any detail. This tells a hiring manager nothing about whether you can write a window function or explain why a query is slow. Add the dialect, add the complexity level, add the context.

Not mentioning dbt. For any analyst role at a data-mature company in 2026, dbt literacy is increasingly expected. If you have not used it, it is worth learning before you apply. If you have used it, it belongs prominently on your CV.

Describing SQL as a supporting tool rather than a core skill. If SQL is how you generated 80% of your analytical output, it should be treated as a primary skill on your CV — not listed quietly alongside Excel and PowerPoint.

Omitting query performance work. The ability to write a correct query is entry-level. The ability to write a fast, maintainable query is what separates analysts from great analysts. If you have diagnosed query plans, added indexes, or restructured queries for performance, say so.

No mention of schema understanding. Analysts who only query data they were handed are less valuable than analysts who understand the underlying schema, can trace data lineage, and can identify model design issues. If you have worked with DBAs, contributed to data models, or designed analytical schemas, include it.

See how NextCV tailors your CV to match the job posting

Closing

Any role that touches data can list SQL, and for analyst roles it is expected. Listing "SQL" is the floor, not the ceiling. The analysts who get the strongest offers are the ones whose CVs show query complexity, warehouse fluency, performance awareness, and downstream impact. Every SQL bullet you write should connect the query to something that happened in the business as a result.

NextCV reads the analyst job description you are applying to and highlights the SQL work in your background — the warehouse dialects, the query depth, the dbt experience — that matches what that team actually needs to see.

Ready to put this into practice? Tailor your CV to a job with NextCV →

This guide has three close neighbours: the data visualisation CV guide, the Excel for finance CV guide, and the guide to consulting CVs. The climate analyst guide covers ESG data and policy-to-industry framing; for requirements work and outcome evidence, turn to the Business Analyst CV guide.