Prep Now or Prep to Order

Opening Scene

Two restaurants serve the same dish. In the first, every ingredient is washed, chopped, and portioned before service even begins — the walk-in is full of neatly prepped containers, ready to combine and cook the moment an order comes in. In the second, the walk-in is full of whole, raw ingredients exactly as they arrived, and every dish is prepped fresh, from scratch, the moment it’s ordered.

Both kitchens can produce the exact same plate. They just disagree about when the work happens — and that disagreement is the entire difference between ETL and ELT.

In Plain English

ETL (Extract, Transform, Load) transforms data before loading it into its destination — prep happens first, and only finished, ready-to-use data gets stored. ELT (Extract, Load, Transform) loads raw data into its destination first, and transforms it later, on demand, using the destination system’s own processing power. Neither is universally “better” — they’re two different bets about where computing power is cheap, how much flexibility you need later, and how much you’re willing to store in raw form.

The Old Way

ETL was, for a long time, the only realistic option. Storage and compute outside the warehouse were expensive and limited, so it made sense to do the heavy transformation work upfront, on separate infrastructure, and load only the clean, finished result — much like a kitchen with a small walk-in cooler that simply can’t hold a full evening’s worth of unprepped, raw ingredients. Prepping ahead of time was a space and cost constraint as much as a workflow choice.

This approach had a real cost: once data was transformed and loaded, the raw version was often gone or hard to get back to. If a business question came up later that needed the ingredients in a different form than however they’d already been prepped, someone had to go back to the source and start over — the equivalent of a customer wanting a dish made a different way, only to find the kitchen already turned the raw ingredients into something else entirely.

What’s Changing (and Why AI Is the Reason)

1. Cheap, powerful storage flipped the economics. Modern warehouses and lakehouses can affordably store enormous amounts of raw data and run heavy transformations directly inside them. The walk-in got big enough to hold everything raw, which made “store first, prep later” a genuinely practical option instead of a theoretical one.
2. AI workloads want the raw ingredients too. Machine learning and AI tools often need data in a much rawer form than a traditional BI dashboard ever did — ELT’s habit of keeping the untransformed original around turns out to be exactly what an AI system needs to work with directly, rather than only the pre-cooked version.
3. Transformation logic itself is easier to change now. Because AI tools can help draft and adjust transformation logic quickly, teams are more comfortable pushing that work later, in the destination system, where it’s cheap to redo — a kitchen willing to prep to order because doing so no longer meaningfully slows anything down.

The Metaphor, Fully Extended

Kitchen Element	ETL vs. ELT Concept
A small walk-in that can’t hold raw ingredients for long	Limited storage forcing transformation before loading (ETL)
A large walk-in stocked with raw ingredients	Cheap storage enabling loading before transformation (ELT)
Prepping everything before service	Transform-then-load (ETL)
Cooking to order from raw stock	Load-then-transform (ELT)
A customer who wants a dish made differently than usual	A new business question needing data in an unexpected shape
Having to call the farm back because ingredients were already used up	Needing to re-extract from the source because raw data wasn’t kept
A well-stocked pantry ready for any recipe	Raw data retained and available for AI/ML workloads
A kitchen confident enough to prep quickly, to order	Fast, flexible transformation logic pushed later in the pipeline

Quick Recap

• ETL transforms data before loading it; ELT loads raw data first and transforms it later, inside the destination system.
• ETL made sense when storage and compute were expensive and limited; ELT became practical once both got cheap.
• Keeping raw data around (ELT’s default) is increasingly valuable because AI and ML workloads often want it in that unprocessed form.
• Neither approach is universally correct — the right choice depends on cost, flexibility needs, and what kind of workloads the data ultimately has to serve.
• Whatever pattern you choose, the ability to answer an unanticipated question later is the real prize worth designing for.

Where This Fits in the Series

This closes out the series’ opening arc — the whole kitchen (Article 1), each station along the way (Articles 2 through 4), and now the two philosophies for running it. Later articles in this series will go deeper into specific stations: streaming and continuous pipelines, data quality checks, orchestration, and how AI agents are changing who — or what — the kitchen is really cooking for.