Stored Procedures vs. dbt: A Data Engineer’s Survival Guide - The Information Lab Nederland

Picture this: You’ve just joined a new company, and the previous data engineer—let’s call him Bob—has left for a remote island with no Wi-Fi. You’re tasked with figuring out why last month’s revenue report is off by 17%. You dig into the database and uncover a labyrinth of stored procedures, each calling another in an endless cycle of cryptic SQL and questionable logic. There are no comments, no version history, and Bob’s only note in the code is a mysterious “fix for issue 423” with no context.

If this scenario feels oddly familiar, you have my sympathy and you’re not alone. It’s the story of many teams that rely solely on stored procedures for data transformations. But what if there was a better way?

dbt has long established themselves as a modern approach to transforming data that brings software engineering best practices to your analytics pipeline. Let’s break down why dbt is often the hero we didn’t know we needed.

Version Control: The Time Machine You Actually Need

Stored procedures live in the database, which means tracking changes is an exercise in pain. If Bob made a bad update two weeks ago, and you need to roll back? Good luck.

With dbt, your transformations live in a version-controlled codebase (GitHub, GitLab, etc.), allowing for:

• Branching and pull requests (so changes are reviewed before going live)
• A clear history of modifications (so you know who to blame—uh, I mean, collaborate with)
• Easy rollbacks when things inevitably break

Stored procedures? They require manual logging or some external backup system that someone was supposed to maintain. And we all know how that usually goes.

Maintainability: Do You Like Your Sanity?

Stored procedures tend to turn into monolithic beasts—long, complex, and impossible to untangle once they’ve grown out of control. The “one giant stored procedure” approach is like having all your kitchen appliances soldered together—useful at first, but a nightmare to fix when something breaks.

In contrast, dbt promotes modularity and reusability:

• Each transformation step is a separate model (i.e., a SQL file), making it easier to debug.
• Configurations are handled separately in YAML, keeping logic and metadata organized.
• Dependencies are managed declaratively (so you don’t have to worry about the order in which scripts should run).

Stored procedures force you to remember which one calls what, in what order, and pray that nobody renames anything without telling you. It’s like an escape room but without the fun.

Testing & Data Quality: The Safety Net You Deserve

Let’s face it: testing in stored procedures is often an afterthought. Sure, you can write separate procedures for validation, but will they actually run before deployment? Probably not.

In dbt, testing is built-in:

• With a few lines of YAML, you can enforce uniqueness, not-null constraints, and referential integrity.
• Custom tests can be written in SQL and included in automated workflows.
• You can run dbt test to catch issues before they break reports.

Stored procedures? Well, the test is usually, “Let’s run it in production and see what happens.”

Documentation

Stored procedures rarely come with documentation, unless you count “mysterious inline comments left by Bob.”

dbt, on the other hand, lets you generate self-updating documentation:

• Each model and column can have descriptions.
• A simple command (dbt docs generate) creates a web-based documentation site.
• Lineage graphs show you exactly where data is coming from and where it’s going.

Stored procedures often require tribal knowledge to decipher. If Bob didn’t tell you how it works before vanishing, you’re in trouble.

Governance & Collaboration: Teamwork Makes the Dream Work

Stored procedures are often controlled by the few brave souls who dare to edit them. There’s little to no enforced workflow, meaning changes can go directly into production with little oversight.

dbt embraces collaboration and governance:

• All changes go through a Git-based workflow.
• Teams can enforce code reviews and testing before deployment.
• Access can be managed centrally without needing direct database permissions.

Stored procedures? Well, if your DBA is on vacation and you need an urgent fix, you might just be out of luck.

So, Should We Just Ban Stored Procedures?

Not necessarily. Stored procedures still have their place:

• They are great for operational tasks like inserting/updating/deleting records.
• They perform well for highly procedural logic that requires loops or transactions.

But for analytical transformations, dbt is almost always the better choice. It brings clarity, version control, automated testing, and governance to your data pipelines, saving you from the nightmare of debugging someone else’s 2,000-line stored procedure.

So, next time you’re about to write a stored procedure for a transformation, ask yourself: Is this my best option? Or will you be cursing yourself in six months?

Choose wisely.

Work together with one of our consultants and maximize the effects of your data. 

Contact us, and we’ll help you right away.