Author: MTF Institute Research Team
Independent review: MTF Institute Research QA
Evidence date and geography: 6 October 2026, United States
Technical report number: MTF-CF-RR-2026-10-06-SQLBA
Version DOI: 10.5281/zenodo.23186266
Full report and 100-source appendix: Public PDF
Abstract
SQL is often presented as a syntax subject. Employers describe a wider workplace task: making a business question answerable from relational data, checking the query and measure, and handing a result to someone who must decide or act. We examined a structured purposive sample of 100 distinct, currently open U.S. employer or employer-authorized applicant-tracking vacancies, each checked on 6 October 2026. Ninety-three selected postings state SQL as an applicant capability in their qualifications; seven instead state a specific SQL work task without making that applicant criterion explicit. These are selection strata, not a national estimate of how often SQL is required. The postings span business intelligence, product, revenue, operations and other analytical settings. This report maps their stated responsibilities, outputs, skills, behavioral requirements, tools, qualifications, work rhythms and decision boundaries, with source-linked examples and explicit treatment of unstated fields.
Research question and scope
The question is: what do current U.S. employer postings actually ask a business-facing analyst to do with SQL, and what surrounding judgments make those queries useful? The unit of analysis is a distinct requisition, not a company, job title, advertisement mirror, tool or search result. The study focuses on roles where SQL is either an essential applicant skill or a named part of analytical work that supports a business decision. It does not treat every analyst job as an SQL job. It also does not equate writing a query with owning the business decision that follows.
The U.S. geography was declared before collection. Eligible pages had a live application route and an explicit U.S. workplace or U.S.-remote eligibility statement at the 6 October evidence check. A role needed substantive analyst, business intelligence or business-facing analytical work. We excluded engineering-centered positions despite analyst-like titles, internships, anonymous recruiter reposts, non-U.S. openings, closed job pages, generic company indexes and records in which SQL appeared only as a preferred, bonus, illustrative or alternative tool without a direct SQL task. A separate context log preserves 27 U.S. analytics postings with non-core SQL mentions; none contributes to the 100-posting denominator.
Sampling and coding method
We searched employer and employer-authorized ATS pages, then opened the exact requisition rather than trusting a search snippet. For each candidate we checked the title, employer, location, application route, SQL wording, analytical role scope and unique provider requisition identity. We compared URL variants and provider requisition identities for deduplication, while retaining the exact URL used for the live job-page readback. Several employers advertised similar roles in different teams or locations. We counted a single requisition once even when it appeared in several cities; materially separate, simultaneously open requisition IDs were checked against the employer board before inclusion. The accepted 100 come from 89 employers. The source-family mix is heavily weighted toward Greenhouse, with additional Workday, Lever and Ashby pages. This is a visibility feature of the purposive search, not the composition of U.S. hiring.
We split selected records into two mutually exclusive strata. In A1, 93 postings explicitly put SQL in required or essential applicant qualifications. In A2, seven describe a concrete SQL work task but do not explicitly make SQL a required applicant criterion. A1 therefore supports the statement that those selected employers require SQL of applicants. The union supports only the narrower statement that SQL is required or actively used in the described work. Employer word choices such as preferred, plus, one alternative among tools, or current stack were not silently promoted to required. A qualification can name SQL without naming joins or window functions; specific techniques are coded only where the posting says them.
For each selected page, the matrix codes expressly stated responsibilities and products, SQL techniques and adjacent hard skills, observable collaboration and communication, interfaces, work cadence, and decision or escalation authority. The source ledger also preserves the exact role title and supporting qualification text, but education, seniority and individual product names are not separate counted matrix fields. A short literal role or qualification phrase supports each positive code. Employer introductions, benefits, education-discipline lists and page headings cannot support duty counts. If the page is silent, the field is marked unstated, not negative. Category counts, when included, describe only these 100 selected records; overlapping categories need not add to 100.
Coded observations within the selected postings
The matrix below counts selected postings with an explicit, independently reviewed statement in the relevant role or qualification text. The 93 A1 and seven A2 records are selection strata, so those figures should not be read as the prevalence of SQL across all U.S. analyst vacancies. The other categories can overlap: a posting can ask the analyst to build a dashboard, validate data and define metrics in the same role. Silence was recorded as unstated rather than as evidence that the activity does not occur.
| Dimension | Explicit statement in selected postings | n of 100 |
|---|---|---|
| Duty | Build or maintain dashboards or reports | 52 |
| Duty | Query or analyze business data | 38 |
| Duty | Validate or reconcile data | 32 |
| Duty | Define metrics or KPIs | 29 |
| Output | Dashboard or scorecard | 47 |
| Output | Report or readout | 34 |
| Skill | BI or visualization tool | 38 |
| Skill | Python or R | 32 |
| SQL technique | Joins explicitly named | 9 |
| SQL technique | CTEs explicitly named | 4 |
| SQL technique | Window functions explicitly named | 4 |
| SQL technique | Query performance explicitly named | 5 |
The small counts for named SQL techniques describe how much syntax detail employers chose to disclose, not how often analysts use these techniques. A posting asking for strong SQL may leave joins, CTEs or window functions unnamed. Conversely, a tool listed in a current stack is not automatically an applicant requirement. Explicit daily or weekly work rhythms are also uncommon in the retained text: cadence is unstated in 88 selected postings. Decision or escalation authority is unstated in 89. These gaps need separated occupational or employer-process context; they cannot be filled from job titles or assumed as universal practice.
What the employer examples show
Some employers put query technique at the center of the analyst role. Engine's Staff Data Analyst calls for complex joins, aggregations and window functions across product and finance information, while requiring documented metrics and analytical outputs that leaders can inspect. 9amHealth's customer-success analyst calls for complex SQL across multiple query engines and a client-facing reporting cycle. These examples establish what those particular employers wrote, not the frequency of advanced syntax across U.S. vacancies.
Other postings connect SQL to trust in a measure or report. Digible's Insights and Analytics Strategist asks for strong SQL skills while placing the analyst between a governed semantic layer and client decisions. Garner Health's Data Analyst II, Business Insights centers KPI and dashboard work with SQL at scale. Ethos Life's Staff Business Analyst requires regular SQL use in a marketing-measurement setting where attribution and vendor assumptions need investigation. These are different decision environments; the common transferable work is to connect a precise question, a defensible data selection and a reviewed interpretation.
Validation and communication are part of that work. Newsela's Educational Data Analyst joins SQL queries with customized metrics and dashboards for school-district stakeholders. Recidiviz's Data Analyst asks applicants to work with large datasets in SQL and to contextualize findings for internal and external partners. K2 Space's Senior Data Analyst combines required SQL with reports and dashboards for manufacturing and finance decisions. The underlying sectors are not interchangeable, and the work products have different owners and controls. The examples nevertheless show why a query handoff should preserve source, grain, filters, definitions, checks, date and a reader-facing explanation.
The matrix also needs to preserve what the postings do not say. An employer may ask for SQL proficiency without specifying dialect, workflow frequency or approval authority. A task may name a dashboard but not explain who owns the metric definition. Silence in a vacancy is not proof that the activity is absent from the workplace. The report therefore separates explicit evidence from inference and uses occupational context only where it is clearly labelled as context. For example, O*NET's Business Intelligence Analysts profile describes querying repositories and producing reports, while its 2025 employer-based skill page uses a different nationwide posting population. Those sources cannot be added to the 100 selected postings or used to convert this study into a representative estimate.
Interpretation and limitations
The selected records show concrete employer statements about SQL-enabled analytical work, not observed day-to-day practice. Search indexing, ATS accessibility, application-page turnover and the inclusion rule shape the sample. The strong Greenhouse contribution and the mix of junior, experienced, senior and lead positions mean a simple percentage would not describe the entire U.S. analyst market. Posting language can combine required skills with alternatives or current-stack examples; each has to be read in its original section. Similar titles can hide distinct work, and different titles can describe overlapping work. Counts from this corpus should always be stated as counts of selected postings, with the denominator and date attached.
Several postings serve specialized contexts, including health, financial services, public-sector and manufacturing work. They are useful evidence that SQL is applied to business questions under local controls. They do not establish one transferable policy for those sectors. A general professional SQL learning path can teach the portable analytical mechanics using original synthetic data: define a question and row grain, inspect source tables, write and check queries, reconcile measures, document assumptions, and explain a decision-ready result. The specialist domain decision remains with its authorized owner.
The separate current-changes study examines dated platform and workflow releases. It has an independent vendor-source corpus and cannot validate the frequency of a duty in these vacancies. The two studies answer different questions: what sampled U.S. employers state now, and what relevant tools and interfaces changed recently. This report keeps those populations and claims separate.