Post

From Prep Kitchens to Open Kitchens: An ETL vs. ELT Story

Confused by ETL vs ELT? This simple story uses a restaurant kitchen analogy to finally explain the difference and why tools like dbt are a game-changer.

From Prep Kitchens to Open Kitchens: An ETL vs. ELT Story

Leo’s laptop screen flickered as the deployment pipeline crashed for the third time that morning. The red error message glared back at him: “ETL job failed - transformation timeout after 6 hours. The business intelligence team was blocked, and the VP of Marketing was already asking for the numbers he was promised yesterday.” He rubbed his eyes and glanced around the bustling open office. Developers chatted over their morning coffee while product managers gestured animatedly at sticky notes on glass walls.

“This can’t be right,” Leo muttered, scrolling through the logs. The customer churn analysis that should have taken an hour was eating up their entire ETL server capacity. Again.

“Rough morning?”

Leo looked up to see Zachary approaching with two cups of coffee, that familiar knowing smile on his face.

“Zachary! Perfect timing.” Leo accepted the coffee gratefully. “Remember last week when you explained the whole data warehouse versus data lake thing? That was a lifesaver.”

“The restaurant storage analogy?”

“Exactly. Well, I thought I had everything figured out, but now…” Leo gestured helplessly at his screen. “I’m drowning in ETL vs ELT confusion. Everyone keeps saying we should switch to ELT, and that modern transformation tools are game-changers. But honestly? I don’t even understand why moving the ‘T’ around matters so much.”

Zachary chuckled and pulled up a chair. “Want to grab some fresh air? I think this conversation needs more space than your desk.”

They walked toward the company’s rooftop terrace, Leo still clutching his laptop. “I feel like I’m missing something fundamental here. We’re literally just rearranging three letters, but people talk about it like it’s a revolution.”

“That’s because it is,” Zachary said as they stepped onto the terrace overlooking the city skyline. “But you’re right - the letters are just the surface. What you’re really seeing is the difference between two completely different philosophies about how data teams should work.”

The Restaurant Kitchen Revolution

Zachary pulled out his phone and opened a notes app, sketching a simple diagram. “Let me tell you about two restaurants. Same food, completely different kitchens.”

“Restaurant analogies again?” Leo raised an eyebrow.

“Trust me on this one.” Zachary grinned. “Restaurant A - let’s call it ‘ETL Bistro’ - has a very traditional setup. They have a prep kitchen in the back where all the magic happens. Raw ingredients come in through the loading dock. Chefs spend hours in that prep kitchen - washing, chopping, seasoning, partially cooking everything.”

He drew arrows flowing from “Raw Ingredients” through “Prep Kitchen” to “Dining Room” on his phone.

“Only when everything is perfectly prepared, seasoned, and ready to serve do they bring it out to the main dining area. Customers never see the messy prep work. They just get beautiful, finished dishes.”

Leo nodded slowly. “Okay, so ETL is like the prep kitchen approach?”

“Exactly! Extract the raw ingredients, Transform them in your prep kitchen, then Load the finished products into your dining room - your data warehouse.”

When the Prep Kitchen Breaks Down

“Now here’s where it gets interesting,” Zachary continued, his finger tracing paths on the screen. “ETL Bistro starts getting really popular. More customers, more complex dishes, more dietary restrictions. Suddenly, that prep kitchen becomes a bottleneck.”

“How so?”

“Well, what happens when a customer wants to substitute quinoa for rice? Or asks if that sauce has nuts? The waiter has to run back to the prep kitchen, find the chef who made that specific dish hours ago, and hope they remember exactly what went into it.”

Leo winced. “That sounds like a nightmare.”

“It gets worse. What if you want to add a new dish to the menu? You have to redesign your entire prep workflow. And god forbid something breaks in that prep kitchen - your whole restaurant shuts down while you fix it.”

Zachary drew a big red X over the prep kitchen on his screen. “This is what happened to ETL in the age of big data. Those transformation servers became expensive bottlenecks. Every change required rebuilding entire data pipelines.”

The Open Kitchen Revolution

“Now, Restaurant B - ‘ELT Kitchen’ - has a completely different philosophy.” Zachary started drawing a new diagram. “They have an open kitchen concept. Raw ingredients come in and go straight to a massive, high-tech main kitchen where everyone can see what’s happening.”

“The ingredients just sit there raw?”

“Not exactly. Think of it like a really smart kitchen with perfect storage. Fresh fish stays fresh, vegetables stay crisp, everything maintains its quality. But here’s the key - the actual cooking and seasoning happens right there in the main kitchen, in full view, when customers order.”

Leo’s eyes lit up. “So with ELT, you Extract and Load first, then Transform in the warehouse itself?”

“Bingo! And here’s why it’s revolutionary - when that customer wants quinoa instead of rice, the chef doesn’t need to run to some back room. They just grab the quinoa from the perfectly organized main kitchen and make the substitution right there.”

The Modern Kitchen Revolution: Beyond Basic Tools

“But wait,” Leo said, “if everything’s happening in the main kitchen, wouldn’t that get chaotic? How do you manage all those transformations?”

Zachary’s eyes gleamed. “This is where modern data transformation tools enter the story. Remember how I said ELT was revolutionary? These tools didn’t just improve ELT - they completely changed what it means to be a data professional.”

He started sketching a new section on his phone labeled “Modern Data Stack.”

“Imagine if our open kitchen got equipped with the most advanced cooking system ever built. Recipe cards that automatically update when ingredients change. Quality control that catches mistakes before food hits the table. Version control that tracks every single recipe modification.”

“That sounds almost too good to be true.”

“Here’s what modern data transformation tools actually do,” Zachary explained, getting more animated. “They bring software engineering best practices into data work. Take tools like dbt as a prime example - before these frameworks, transformations were like having each chef keep their recipes in their head. No documentation, no testing, no collaboration.”

The Engineering Transformation

Leo leaned forward. “So these tools made data work more like… actual engineering?”

“Exactly! Think about it - before modern transformation frameworks, if Sarah the data analyst left the company, her complex transformations might as well have been black magic. No one knew how she calculated customer lifetime value or why she excluded certain records.”

Zachary started listing on his fingers. “Tools like dbt introduced version control for data transformations. Code reviews for SQL. Automated testing to catch data quality issues. Documentation that actually stays up to date.”

“It’s like the difference between a food truck where one person knows all the recipes,” Leo said slowly, “and a professional kitchen with standardized procedures, recipe cards, and training protocols.”

“Perfect analogy! And just like that professional kitchen can train new chefs faster and scale more efficiently, these modern data transformation tools let data teams grow without losing institutional knowledge.”

Zachary paused, then continued with a grin. “Of course, dbt isn’t the only ‘culinary school’ out there. Some kitchens - like those running on Google Cloud - prefer their built-in official cookbook called Dataform. Then you have more avant-garde kitchens using tools with holographic simulation features like SQLMesh, ensuring nothing goes wrong before the dish hits the table.”

“Holographic simulation?” Leo raised an eyebrow.

“Think of it as being able to test your entire recipe in a virtual kitchen before you risk ruining actual ingredients. And some restaurants have executive chefs like Dagster who think recipe cards aren’t enough - they want to use Python to manage everything from ingredient sourcing to final presentation.”

Leo chuckled. “So there’s a whole ecosystem of kitchen management philosophies?”

“Exactly! dbt just happens to be the most popular ‘culinary school’ right now, with the biggest community and the most standardized approach to collaboration. But the key principle remains the same across all these tools - bring engineering discipline to data work.”

The Modern Data Stack Ecosystem

“Okay, but how does this all fit together?” Leo asked. “You mentioned something called the Modern Data Stack?”

Zachary drew three connected boxes on his phone. “Think of it as a well-oiled restaurant chain. You have your suppliers - companies like Fivetran and Airbyte that handle the ‘E’ and ‘L’ of ELT. They’re like perfect logistics companies that get fresh ingredients from farms to your kitchen without you thinking about it.”

He pointed to the middle box. “Your kitchen is Snowflake, BigQuery, or Databricks - these massive, scalable cloud kitchens that can handle any volume. And your cooking instructions? That’s modern data transformation tools like dbt, Dataform, or SQLMesh handling all the transformations.”

“And the dining room?”

“That’s your BI tools - Looker, Tableau, Power BI. They present the finished data dishes to your customers in beautiful, digestible formats.”

Leo stood up and walked to the terrace railing. “So instead of having one restaurant trying to do everything, you have specialists at each stage?”

“Exactly! And here’s the beautiful part - each piece can be swapped out or scaled independently. Need more extraction power? Upgrade your data connector. Need more transformation capability? Scale your cloud warehouse. Want better visualization? Switch BI tools.”

The Economics of the New Kitchen

“But doesn’t all this cloud stuff get expensive?” Leo asked. “I mean, running transformations in Snowflake instead of some dedicated ETL server?”

Zachary laughed. “That’s the counterintuitive part. Remember our prep kitchen analogy? In the old ETL world, you had to maintain that prep kitchen 24/7, whether you were busy or not. Like paying rent on a massive kitchen that sits empty most of the day.”

He sketched two cost curves on his phone. “With ELT and cloud data warehouses, you only pay for what you use. It’s like having access to the world’s best kitchen, but only paying for the time you’re actually cooking.”

“So if we only run transformations at night, we only pay for a few hours of compute?”

“Precisely! And during month-end reporting when you need massive processing power, you can scale up instantly. Try doing that with physical ETL servers.”

The Cultural Revolution

Leo was quiet for a moment, processing everything. “You know what’s crazy? This isn’t just about technology, is it? It sounds like it changed how entire teams work.”

“Now you’re getting to the heart of it,” Zachary said.

“The move from ETL to ELT wasn’t just technical - it was cultural. It democratized data transformation.”

“How so?”

“In the ETL days, you needed specialized ETL developers who knew proprietary tools like Informatica or DataStage. These were expensive, hard-to-find people. If you wanted to change a transformation, you had to wait for the ETL team, and they had limited capacity.”

Zachary gestured broadly. “With modern ELT transformation tools, anyone who knows SQL can contribute. Data analysts, analytics engineers, even business users can write and maintain transformations. Whether they’re using dbt, Dataform, SQLMesh, or Dagster - it’s like the difference between needing a master chef for every recipe versus having clear instructions that any competent cook can follow.”

The Aha Moment

Leo walked back toward Zachary, then suddenly spun around. “Wait, I think I get it now. ETL vs ELT isn’t really about the order of operations. It’s about where you put your intelligence.”

“Go on…”

“With ETL, all the smart stuff - the business logic, the transformations - happens in this separate system. With ELT, you’re leveraging the power and intelligence of your destination system. You’re using your data warehouse as your transformation engine.”

Zachary smiled widely. “And what does that give you?”

“Flexibility! If the business changes how they define ‘active customer,’ I don’t need to rebuild some complex ETL job. I just update the transformation model and rerun it. If I want to add a new metric, I’m working in the same environment where all my data already lives.”

“Plus?”

Leo was getting excited now. “Plus, I get all the benefits of modern cloud infrastructure. Automatic scaling, pay-per-use pricing, and insane processing power when I need it.”

The Future Kitchen

“So where does this all lead?” Leo asked. “What’s next for data pipelines?”

Zachary leaned against the terrace railing. “Well, we’re starting to see the emergence of even more specialized tools. Streaming data pipelines for real-time processing. Data mesh architectures for massive organizations. AI-powered data quality monitoring.”

“But the core principle remains the same?”

“Exactly. Leverage the power of modern cloud data platforms. Make data work more like software engineering. Enable teams to move fast without breaking things.” Zachary pocketed his phone. “The restaurant analogy still holds - we’re just getting better appliances and more efficient workflows, with different tools for different kitchen styles.”

The New Data Engineer

Leo looked out at the city skyline, then back at Zachary. “You know what’s funny? When I started this conversation, I thought I was just confused about acronyms. But really, I was missing the bigger picture of how data teams actually work now.”

“And what’s that picture?”

“It’s not about moving data around anymore. It’s about building reliable, scalable systems that let data people focus on generating insights instead of fighting with infrastructure. And there are multiple good approaches - dbt, Dataform, SQLMesh, Dagster - each with their own strengths.”

Zachary nodded approvingly. “So when someone asks you about ETL vs ELT again?”

Leo grinned. “I’ll tell them it’s like asking about traditional prep kitchens versus open kitchens. Same ingredients, same final dishes, but completely different workflows. And one of them scales a lot better with modern data stack transformation tools.”

“Perfect. Now, want to grab lunch? All this restaurant talk made me hungry.”

As they walked toward the elevator, Leo paused. “One more question - why did it take so long for everyone to switch to ELT?”

“Technology readiness,” Zachary replied. “You needed cloud data warehouses powerful enough to handle transformations, and modern transformation tools to make it manageable. It’s like asking why restaurants didn’t always have open kitchens - you need the right equipment and the right management systems to make it work.”

Leo nodded as they stepped into the elevator. “Makes sense. Sometimes the best solutions are only obvious in hindsight.”

“That’s engineering for you,” Zachary said with a laugh. “Today’s revolution is tomorrow’s ‘well, of course we do it that way.’”


Key Takeaways:

  • ETL processes data in separate systems before loading, while ELT leverages destination platform power for transformations
  • Modern data transformation tools revolutionized data work by bringing software engineering practices to data teams
  • The modern data stack enables specialized tools working together efficiently
  • ELT provides better scalability, cost efficiency, and team collaboration than traditional ETL approaches
  • This shift represents both a technological and cultural evolution in how data teams operate
  • dbt: The universal “culinary school” (Standardization & Collaboration)
  • Dataform: The official Google “kitchen cookbook” (Native Integration)
  • SQLMesh: The “holographic simulation kitchen” (Pre-deployment Validation)
  • Dagster: The “executive chef” managing the entire restaurant (End-to-End Orchestration)
This post is licensed under CC BY 4.0 by the author.