TL;DR

ETL (Extract, Transform, Load) and ELT (Extract, Load, Transform) are the two primary patterns for moving recruitment data from source systems - ATS, HRIS, payroll, job boards - into a data warehouse or analytics platform. The difference is where transformation happens: before loading in ETL, after loading in ELT. The choice affects cost, flexibility, and how quickly analysts can access new data.

How ETL/ELT Works

In ETL, data is extracted from source systems, passed through a transformation layer that cleans, reshapes, and standardizes it, and then loaded into the destination in its final, analysis-ready form. The transformation layer might be a custom script, a dedicated ETL tool like Talend or Informatica, or a cloud service like AWS Glue. The destination warehouse receives data that is already in the correct format.

In ELT, data is extracted from source systems and loaded into the warehouse in raw form - exactly as it came from the source. Transformation happens after loading, using the warehouse's own compute power. Tools like dbt (data build tool) are specifically designed for this: they write SQL transformation logic that runs inside Snowflake, BigQuery, or Redshift, producing clean, analysis-ready tables from the raw data.

Modern cloud data warehouses have pushed most teams toward ELT for several reasons. Storage is cheap - loading raw data first and transforming later does not add meaningful cost. Warehouse compute is powerful - Snowflake can transform millions of rows in seconds. And loading raw data first means analysts can always re-run transformations with different logic without re-extracting from source systems.

For recruitment data specifically, transformation logic is non-trivial. Source systems use inconsistent field names (Greenhouse calls it "application_stage", Bullhorn calls it "status"), inconsistent date formats, inconsistent null handling, and different taxonomies for the same concepts. The transform step - whether in ETL or ELT - is where these inconsistencies get resolved into a consistent data model.

Why It Matters in Recruitment

Recruitment generates data across a fragmented stack. An enterprise talent acquisition team might have Greenhouse for corporate hiring, Bullhorn for contract roles, LinkedIn Talent Hub for sourcing, Checkr for background checks, and Workday for HRIS. Each system has its own schema, its own terminology, and its own data quality standards. None of them talk to each other natively in a way that enables cross-system analysis.

ETL/ELT pipelines are the infrastructure that unifies this fragmented data. Without them, the only way to analyze hiring data across systems is to export CSVs, manually reconcile field names, and build one-off reports that become stale the moment they are finished. With a working pipeline, that same analysis is a SQL query that runs on fresh data every morning.

Time-to-hire analysis across the full funnel - from first sourcing touchpoint to background check cleared to first day - requires data from at minimum three systems (sourcing platform, ATS, background check provider). That analysis is only possible if all three systems feed into a common data store through a reliable ETL/ELT pipeline.

ETL/ELT in Practice

A large staffing company uses Bullhorn for candidate and job management, ADP for payroll, and Snowflake as their data warehouse. They run a nightly ELT pipeline using Fivetran to extract data from both Bullhorn and ADP - Fivetran handles the extraction and loads raw tables into Snowflake by 2 AM.

Starting at 2 AM, dbt runs a series of SQL transformations inside Snowflake. It renames fields to a consistent schema, joins Bullhorn placement records to ADP payroll records on employee ID, calculates gross margin per placement, and produces a clean "placements" table that the finance and operations teams query for their morning reports. By 7 AM, the dashboards in Tableau reflect the previous day's placements with accurate margin calculations.

The operations director queries the Snowflake table directly to answer ad-hoc questions: which recruiters have the highest-margin placements by client sector, which clients have the shortest average time-to-fill, which job categories have the highest contractor attrition rate.

Key Considerations

Reverse ETL - the less-discussed third option - deserves specific attention in recruitment contexts. After computing insights in the warehouse (AI candidate scores, time-to-hire predictions, diversity metrics by department), those insights often need to flow back into the ATS where recruiters actually work. Tools like Census or Hightouch handle this reverse flow, writing warehouse-computed fields back to ATS records via API. This closes the loop between analytics infrastructure and day-to-day recruitment operations.