You have read the same etl vs elt comparison five times this quarter. Each one compares where the transform runs, each one asks how much data you have, and each one assumes you own the source. You do not.
Set aside which pattern is modern. Modern is a property of your warehouse, not of the API you pull from. When the source belongs to someone else, a few source-side facts decide it: what a re-pull costs, whether the schema is contractual or merely observed, whether personal data may legally land raw, how hard the ceiling is. A documented 5,000 requests per hour does not care where your transform runs.
By the end you will be able to pick a pattern for one specific feed and defend the choice.
Quick Digest
- The shared extract step: ETL and ELT run an identical E, and the E is the part you do not control.
- Sources you do not control: third-party APIs, vendor drops, scraped sites and licensed feeds each bend extraction.
- The differences that decide it: six source-side factors settle a third-party pipeline. Data volume is not one.
- Where ETL wins: regulated PII feeds, no-raw-retention clauses, per-record pricing, narrow access windows.
- Where ELT wins: scraped sources, costly re-pulls, exploratory coverage, moving business logic.
- Choosing per source: five questions from a contract and a week of logs. Most estates run both.
- The acquisition layer: a reliable extract is a precondition for either pattern, not a warehouse feature.
ETL and ELT in one pass
ETL transforms data before it lands in the warehouse. ELT loads it first and transforms it in place. Everything follows from where the transform runs and when the schema is committed.
ETL provisions a transformation tier and commits at extract time, schema-on-write. ELT lands the payload in a data warehouse or lakehouse, models it with dbt, and defers to read time, schema-on-read. Apache Airflow orchestrates either. Background: data pipeline versus ETL.
The pair is not exhaustive. A November 2025 academic paper formalizes ETLT and ELTL as design patterns, because practitioners already run them while “the literature lacks best practices and formal recognition of these approaches as design patterns.” ETL is not the legacy one.
CREATE TABLE raw_vendor_feed (payload VARIANT);
COPY INTO raw_vendor_feed
FROM @vendor_stage
FILE_FORMAT = (TYPE = 'JSON');What do ETL and ELT actually share?
ETL and ELT share the entire extract step and its constraints: the same authentication and auth rotation, the same cursor pagination, the same watermark state, the same exponential backoff on HTTP 429.
And the ceiling. GitHub‘s REST API, as of August 2026, permits 60 requests per hour unauthenticated, 5,000 for an authenticated user or OAuth app, and 15,000 for qualifying Enterprise Cloud organizations, returning HTTP 403 or 429 past that.
The E is identical, and the E is the part you do not control. A shared dependency both patterns sit on.
What breaks when you don’t control the source?
Four acquisition classes, four ways the extract step bends. Third-party APIs hand you auth rotation, cursor state and a ceiling you cannot raise. Vendor file drops arrive on an SFTP schedule under a delivery SLA, columns reordered between deliveries. Scraped web sources bring anti-bot measures, proxy management and an observed rather than contractual structure. Licensed feeds carry retention terms, per-record pricing and residency rules.
None offers change data capture. No log to tail, so you keep the state yourself: cursors, high-water marks, idempotency keys, dedupe on re-extract. No upstream merge gates a change made in someone else’s repository. In practice, data volume, the axis the field decides on, predicts almost nothing here.
Extraction is not a solved first step. A silently truncated pull, a vendor adding a column mid-file, an auth rotation at 3am, a 429 storm halving a day’s records: none are transform events.
Yasmin, Tian and Yang (IEEE ICSME 2020) studied 2,224 OpenAPI specifications covering 1,368 RESTful APIs and found that across the 219 APIs carrying deprecation signals, an average of 46% of operations were deprecation-related, and in 71 of those 219, every operation was affected. There is no standard way to retire an endpoint, which is why reliable automated data collection is a validation discipline, not a scripting one.
GET /repos/acme/widgets/issues?per_page=100&page=3
Authorization: Bearer <token>
HTTP/1.1 403 Forbidden
x-ratelimit-limit: 5000
x-ratelimit-remaining: 0
x-ratelimit-reset: 1787160000
retry-after: 60Neither pattern changes a byte of that exchange.
Quick Summary
Q: What breaks when you don’t control the source?
A: The extract step, in ways neither pattern can see. Sources change without notice, offer no CDC log and enforce ceilings you cannot raise.
The differences that decide a third-party pipeline
Six factors settle the choice, and we call them the Six Source-Side Factors: cost placement, drift behaviour, replay, PII placement, access exposure, failure shape. Each is answered by a fact about the source, not about the warehouse.
Terminology, held from here. Schema drift is an unannounced source-side change. Replay is re-running the transform against retained raw. Backfill is recovering a historical range from the source. Not interchangeable.
| Factor | ETL | ELT |
|---|---|---|
| Order of operations | Transform before load | Load before transform |
| Schema committed | At extract time | At read time, deferred |
| Where compute cost lands | Dedicated tier, paid regardless of queries | Warehouse compute, billed per transform run |
| Cost of a re-run | Paid again unless raw was retained | Paid once if raw is retained |
| Behaviour under schema drift | Fails loudly at the transform, pre-load | Absorbs it, fails silently downstream later |
| Replay and backfill | Only if raw was retained separately | Native: re-run the transform on retained raw |
| Where PII is handled | Masked pre-load; raw PII never lands | Lands raw; masking is a post-load control |
| Rate limit exposure | A failed transform can force a re-pull | Retained raw removes the re-pull |
| Completeness guarantee | Transform-time validation catches short pulls | Preserves an incomplete pull confidently |
| What breaks first | The transform job | The dashboard |
| Fit for licensed data | Compatible with no-raw-retention clauses | Often contractually disqualified |
Where the transform cost lands
ETL pays for a tier regardless of query volume. ELT bills per transform run, re-runs included. In the 2026 State of Analytics Engineering Report, April 2026, n=363, 57% reported increased warehouse and compute spend against 36% reporting increased team budgets, and 53% now prioritize cost reduction, up from 48%.
For a per-call-priced API or a scraped source carrying proxy costs, the mechanism inverts. You pay per record before any transform exists, and again for every retry burned against a ceiling. That spend belongs to the E, so moving the transform does not move it.
What happens when the source schema drifts
A vendor renames a field in Tuesday’s file. ETL fails at the transform, before bad data lands. ELT’s semi-structured landing accepts the rename, the row count looks right, and the blast radius widens for days before a NULL column surfaces. See how extraction pipelines break in production.
SELECT
payload:customer_id::STRING AS customer_id,
payload:amount::NUMBER AS amount
FROM raw_vendor_feed;After the rename to customerId, that first column returns NULL from Tuesday on. Nothing alerts.
Common misconception. ELT does not handle schema drift. It defers it. Loud and early is usually the cheaper failure.
Whether you can replay or backfill
ELT’s retained raw makes replay native and removes the re-pull. ETL’s replay exists only if you retained raw separately; discard it, and a backfill against a vendor’s rolling window returns nothing. Retained raw is still not a backup. It is only as complete as the pull behind it.
Where PII gets handled
ETL masks or drops before load. ELT lands raw and masks downstream while the original still exists. GDPR, in force since May 2018, names the mechanism twice: Article 5(1)(c) requires personal data “limited to what is necessary in relation to the purposes for which they are processed,” and Article 5(1)(e) requires it “kept in a form which permits identification of data subjects for no longer than is necessary.” The second clause bites the ELT raw layer specifically. ETL’s price: the unmasked original is gone, so replay went with it.
Who absorbs a rate limit or a closed access window
A failed ETL transform can force a re-pull straight into a ceiling; retained raw removes the need to pull twice. The pattern that survives is the one whose recovery path does not need the source to cooperate again. A retry policy is not a recovery plan once the window has closed.
What a failure actually looks like
Under ETL the transform job breaks and pages someone. Under ELT it is a gray failure: the dashboard breaks and someone notices, later. You can’t ELT what you couldn’t extract. A raw layer built from an incomplete pull is not a safety net: a truncated extract or a 429-shortened page walk lands as a confident-looking raw table.
Expert Insights
Chad Sanderson, CEO and co-founder of Gable.ai, wrote in March 2025 that “data engineers became reactive firefighters, constantly wrangling broken schemas, cleaning up unexpected transformations, and trying to reconstruct meaning from fragmented event logs,” and that “if a change to a schema or data payload is going to break an ML model or a reporting pipeline, the engineer should know before they hit merge.” For a source you do not own there is no merge to gate.
Where ETL wins in data acquisition
Five acquisition scenarios, named as source types, not data properties. Regulated feeds carrying PII that must not land raw, masked inside the extract job. Licensed data with no-raw-retention or delete-on-transform clauses. Per-record priced sources you cannot afford to re-pull, where a validation gate inside the extract job earns its keep. Small, high-complexity vendor feeds where warehouse compute is the expensive part. Narrow access windows, where the job must validate and quarantine before the window shuts.
What links them is a source behaviour, not a preference. Regulated feeds emit identifiers alongside the fields you need, and the minimisation obligation attaches the moment they land, not when a model reads them. A delete-on-transform clause makes retention itself the breach, and no downstream masking undoes it. Per-record pricing charges on the pull, so a parse you get wrong buys a second invoice, not a second query. An access window shuts on the vendor’s schedule and gives you one attempt to validate, which is why that check belongs inside the extract job.
California Civil Code § 1798.100(c), operative January 2023, sets the standard: a business’s “collection, use, retention, and sharing of a consumer’s personal information shall be reasonably necessary and proportionate to achieve the purposes for which the personal information was collected or processed.” Read that as an architecture constraint, not a legal footnote. An ELT raw layer is by construction retention of everything the source emitted.
Common misconception. For some licensed feeds, ELT is not the worse option. It is contractually disqualified. No cost advantage recovers a clause. ETL’s price is real too: native replay goes with the unmasked original.
This article provides general guidance, not legal or compliance advice. Consult qualified counsel for your organization’s specific requirements.
Where ELT wins in data acquisition
Five again, weighted the same. Scraped and semi-structured sources where the schema cannot be known at extract time. Expensive-to-re-extract feeds, where retained raw buys replay. Exploratory coverage, where you do not yet know which fields matter. High-volume vendor feeds where warehouse compute costs less than a provisioned tier. Business logic still moving, where early schema commitment books technical debt.
What links these is the opposite source behaviour. A scraped source has no contract holding it still, so the structure you parse today is a reading you will revise, and landing the payload whole makes that revision a re-run, not another crawl past anti-bot measures. A feed you cannot re-pull cheaply turns every parse decision into a one-way door unless raw survives. Exploratory coverage has no target schema, so committing one at extract time discards fields you have not learned to want. When business logic outruns the source, replay keeps the rewrite off the extract schedule.
Open table formats are why the raw layer got cheap and queryable after 2024, a shift absent from the published comparisons. Adoption is earlier than the discourse implies: in the same April 2026 survey of 363 respondents, only 9% reported Apache Iceberg in production, with 27% reporting some engagement. Treat the cheap replayable raw layer as a settled default and you skip the completeness checks that make it work.
The honest version of the replay argument: it exists only if the raw pull was complete, so ELT’s strongest advantage is conditional on the extract rather than the warehouse.
Which pattern fits which source?
Six factors, five questions: drift and failure shape resolve together. Each is answerable from a vendor contract and a week of logs. Can you re-extract cheaply, or at all? Is the schema contractual or merely observed? May PII legally land raw? How narrow is the access window? Do you need replay, and would retained raw be permitted?
Most third-party estates converge on EtLT: light normalization and PII masking pre-load, heavy modelling post-load. Not a fence-sit. As of November 2025 the hybrid has a formal specification, and the enhanced variants embed “explicit contracts, versioning, semantic curation, and continuous monitoring as mandatory design obligations.” That is a job description: a data contract for a schema you do not own, a schema registry to make it contractual, not observed, and data observability for third-party datasets replacing the merge gate you do not get.
So reject “standardise on one pattern.” A 40-source estate will legitimately run both, and that follows from the contracts, not indecision. Our view, not either cited source’s: per-source selection becomes the default posture within 12 to 24 months.
Expert Insights
Pooja Crahen, Senior Manager of Analytics Engineering at Okta, framed it in April 2026: “there’s a real tension between moving fast and building trust, and you can’t optimize for both without intention,” and “discipline in modeling, validation, and ownership becomes a requirement, not a best practice.”
Where the acquisition layer fits
Neither ETL nor ELT addresses an extract-side failure, so whoever owns the extract sits upstream of the decision. A March 2025 survey of 307 UK and US data decision-makers and users found 64% reporting that their teams spend more than half their time on repetitive or manual tasks, and 70% rating pipeline management as somewhat or extremely complex.
An acquisition layer absorbs four functions: managed extraction against sources you do not control, schema-drift monitoring at the source boundary, replayable raw retention, and completeness checks before hand-off. Forage AI handles selector drift, anti-bot evolution, and schema changes as part of the service, Managed Data Extraction for teams moving from fragile scripts to managed pipelines.
Not a warehouse replacement, not a transform tier. It makes both patterns available by making the shared E reliable.
Frequently asked questions
Is ELT replacing ETL?
No, and specifically not for sources you do not control. Retention clauses and per-record pricing make pre-load transformation structurally required for a real share of third-party feeds.
Which is better for third-party or API data, ETL or ELT?
Neither, universally. It turns on whether you can re-extract cheaply and whether the schema is contractual or observed. Answer those two and the rest falls out.
Is ELT actually cheaper than ETL?
Only if you measure transform compute alone. For per-call-priced APIs and scraped sources the extract dominates, and warehouse compute spend is outrunning the budgets meant to absorb it.
Can you run ETL and ELT in the same pipeline?
Yes, and most third-party estates should. Light normalization and PII masking pre-load, heavy modelling post-load, formalized as a design pattern in November 2025.
What happens to an ELT pipeline when the source schema changes?
The load usually succeeds. Semi-structured landing absorbs the change instead of rejecting it, so the failure surfaces days later in the models, not at ingestion.
Is dbt ETL or ELT?
dbt is the T in ELT. It transforms data already in the warehouse and never touches your source, so it cannot fix an extract-side failure.
Conclusion
Pick one source you already own. Run the five questions against it this week, write the answers next to the feed name, and see whether the pattern you inherited is the one the source actually selects. Per-source selection is the posture that survives a vendor changing a field, because it does not require re-platforming every time one does. If you land somewhere that contradicts what we have argued, we would rather hear it.
Related Articles
- Data Pipeline vs ETL: Key Differences (2026): the upstream explainer if the vocabulary is new
- Why Most Enterprise Data Pipelines Break and How to Fix It: the failure modes both patterns inherit
- Data Observability for Third-Party Datasets: how to know your external feed broke before your dashboard does
- Automated Data Collection: How Enterprise Teams Build Reliable Extraction Pipelines: the acquisition layer that sits upstream of both patterns
Sai is a data infrastructure enthusiast who has spent the past two to three years following the AI space closely, from the infrastructure layer to the fast-growing world of data for AI. He is genuinely curious about how modern data pipelines get built and where the data industry is heading, and he writes insightful pieces on the core topics that shape this niche.
