ETL/ELT PatternsETL vs ELT Trade-offsMedium⏱️ ~3 min

ETL and ELT at Scale: The Real Numbers

The Volume Challenge: At companies like Netflix or Amazon, you are not moving megabytes. Daily ingestion can hit multiple terabytes across hundreds of data sources: mobile app events generating 5,000 to 50,000 events per second, transactional databases with hundreds of writes per second per shard, microservice logs, and third party data feeds.
ETL Pipeline Latency
1 to 4 hrs
P99 LATENCY
50 TB
CURATED STORAGE
ETL at Production Scale: Classic ETL architectures batch process data hourly or daily. Sources write Change Data Capture (CDC) streams or periodic dumps into staging. A processing engine like Spark pulls data, applies business rules including data type normalization, Personally Identifiable Information (PII) masking, and reference data joins, then writes dimension and fact tables into the warehouse. Storage stays relatively compact because you only keep curated datasets. Instead of 500 TB of raw plus curated, you might store just 50 TB of modeled data. Query performance is strong because schemas and indexes are designed upfront for known access patterns. The cost: end-to-end latency from event occurrence to queryable metric hits p99 of 1 to 4 hours. This works for finance reporting or executive dashboards that refresh once or twice daily, but fails for real time product analytics.
ELT Pipeline Latency
30 sec
P50 INGESTION
2 min
P99 INGESTION
ELT at Production Scale: Modern cloud warehouses like Snowflake, BigQuery, Databricks, and Redshift enable ELT by separating storage from compute. Raw data lands directly via streaming or micro batch. Clickstream events appear in raw tables within seconds. Storage grows to hundreds of terabytes or petabytes because you preserve all raw fields. Transformations run inside the warehouse on elastic compute. You can schedule sessionization and denormalization every 5 to 15 minutes for near real time analytics. For heavy backfills, you scale compute clusters up to finish in 30 minutes instead of 6 hours, then scale down immediately to control cost.
"The complete system view is almost always hybrid: ETL for regulated payment data, ELT for behavioral logs and clickstreams."
The Hybrid Reality: Production systems rarely pick one pattern exclusively. You use ETL for highly regulated datasets where only clean data can enter the analytics environment. In parallel, you use ELT for behavioral data where analysts, data scientists, and machine learning engineers benefit from raw history access. Orchestrators coordinate dependencies so downstream dashboards with 99.9 percent availability always read from validated tables.
💡 Key Takeaways
ETL systems typically achieve p99 end to end latency of 1 to 4 hours, suitable for daily reporting but not real time analytics
ELT systems land raw data with p50 ingestion latency under 30 seconds and p99 under 2 minutes, enabling near real time queries
ETL keeps storage compact at tens of terabytes by storing only curated data, while ELT preserves hundreds of terabytes of raw history
Cloud warehouses enable ELT through elastic compute: scale up for 30 minute backfills, scale down to control cost
Hybrid architectures are standard at scale: use ETL for payments and regulated data, ELT for behavioral and experimental datasets
📌 Examples
1Netflix ingests 5,000 to 50,000 events per second from mobile apps using ELT, landing raw events in under 2 minutes for product analytics
2A payment processing system uses ETL to mask PII and apply strict validation before loading, keeping warehouse storage at 50 TB instead of 500 TB
3An ecommerce platform runs transformation jobs every 5 to 15 minutes inside Snowflake for near real time conversion funnel metrics
← Back to ETL vs ELT Trade-offs Overview