FEATUREDApplication Development & Modernization
Modern teams need speed, flexibility, and scalability in data. ELT supports agile analytics and AI—making it the default for today’s data workflows.
We’ve all been there: stuck waiting on data. Whether it’s questions from leadership, a new use case to explore, or a broken dashboard, delays often trace back to one culprit—transformation that happens before the data even lands.
That’s the legacy of ETL: Extract, Transform, Load. ETL emerged with the first generation of data warehouses, which required a rigid structure with data defined by fixed columns. This meant the data had to be transformed before it could be loaded. ETL worked well for structured transactional data like financial records or ERP outputs, ensuring compliance, data quality, and schema alignment.
As unstructured data entered the picture, the data lake arrived. Data lakes support a wide range of file types—including PDFs, logs, images, and formats that don’t fit neatly into tables. Teams began to extract data and load it into lakes first, deferring transformation. This flexibility allowed the same dataset to be transformed in different ways, depending on the use case. Engineers were no longer locked into one schema.
Now, we have data lakehouses, which combine the capabilities of both data warehouses and data lakes. Lakehouses empower teams to build pipelines for structured and unstructured data, adjusting transformation logic per use case. The result? Traditional analytics, AI, ML, and real-time processing—on one unified platform.
The Basics: ETL vs. ELT
A quick breakdown of each process:
ETL (Extract, Transform, Load): Data is extracted, transformed in a staging area to fit a defined schema, and then loaded into a structured warehouse. Traditional warehouse architectures require this because they cannot efficiently handle unstructured formats without pre-processing.
ELT (Extract, Load, Transform): Data is taken from the source, the raw data is preserved and loaded directly into a flexible storage environment (lakehouse or data lake). Transformations are applied later based on the specific analytical or operational use case.
Why ELT Works for Today’s Teams
Let’s start with infrastructure. Modern data center architectures separate compute and storage, allowing you to load first and transform data when needed. That’s a huge advantage when you’re dealing with large volumes or mixed data types. Tools like dbt and orchestration frameworks like Airflow & Iceberg have made in-warehouse transformation not only possible, but manageable at scale..
ELT also puts control back in the hands of analysts and engineers. Instead of waiting on centralized ETL jobs, they can build, test, and deploy transformations quickly. This agility means fewer delays when business needs change.
Real Reasons ELT Has Become the Default
- Modern platforms enable it: Data lakehouses like Databricks, Snowflake, and BigQuery handle structured, semi-structured, and unstructured data.
- Faster time-to-insight: Data is available for query immediately after loading.
- Flexibility: Schema-on-read and raw storage adapt to changing needs.
- Empowered teams: Analysts own models and iterate without bottlenecks.
- Big data support: ELT easily scales to diverse, high-volume input.
- Tool alignment: Solutions like Fivetran, Stitch, and Meltano follow ELT-first designs.
But ETL Still Matters
ETL remains essential where compliance and governance require transformations before loading, or where raw data storage isn’t allowed. It’s also suited for complex transformations better handled outside the main data platform.
A Hybrid Reality
Many organizations run both ETL and ELT. They use ETL for regulated, structured environments and ELT for agile, data-rich projects. Data lakehouses unify the storage and processing capabilities of data lakes and warehouses, allowing teams to combine ETL and ELT patterns in a single environment while accommodating both structured and unstructured data.
Key differences: ETL vs. ELT
To summarize, the table highlights the main distinctions between ETL and ELT, so you can see at a glance how they differ in process, flexibility, and practical considerations.
| Category | ETL | ELT |
| Process Order | Extract → Transform → Load | Extract → Load → Transform |
| Storage Target | Traditionally a structured data warehouse | Data lake, lakehouse, or cloud warehouse supporting raw formats |
| Transformation Location | Staging area before loading | Within the storage platform after loading |
| Data Types Supported | Primarily structured | Structured, semi-structured, and unstructured |
| Flexibility | Less flexible; schema fixed before load | More flexible; schema can be applied as needed (schema-on-read) |
| Compliance Use Case | Ensures compliance and quality before data is stored | Compliance handled during or after transformations |
| Security | Strong security and governance enforced before load; may require custom applications to meet certain data protection needs | Security controls applied within the platform after load |
| Cost | Potentially higher upfront cost due to transformation infrastructure | Often lower upfront cost but variable based on transformation workload |
| Speed | Slower to initial availability due to pre-load transformations | Faster access to raw data with transformations applied as needed |
Where This Is Going
ELT is now a foundation for AI and automation. By keeping full-context raw data accessible, organizations can support use cases like vector search, semantic enrichment, and RAG for LLMs. Lakehouses, in particular, enable the integration of these advanced workflows directly with traditional analytics.
If you’re still transforming data before loading by default, it may be time to reconsider your approach.