<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Opinions/Thoughts: SQL Best Practices in Production .. DBT vs DLT ? in Data Engineering</title>
    <link>https://community.databricks.com/t5/data-engineering/opinions-thoughts-sql-best-practices-in-production-dbt-vs-dlt/m-p/129484#M48546</link>
    <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/146924"&gt;@BS_THE_ANALYST&lt;/a&gt;&amp;nbsp;,&lt;/P&gt;&lt;P&gt;That’s a really good question! I don’t think there’s a single definitive answer, since the choice depends on several factors. Each framework has its own advantages and disadvantages.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;In my opinions strengths of dbt are:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;- Wide adoption - dbt is very popular, with a large and active community.&lt;/P&gt;&lt;P&gt;- SQL on steriods - you can write transformations purely in SQL, but dbt also supports Jinja templating, which makes it easier to add loops, conditionals, and other logic.&lt;/P&gt;&lt;P&gt;- Auto-generated documentation -&lt;/P&gt;&lt;P&gt;- Support for multiple environments - it fits nicely into dev/test/prod setups.&lt;/P&gt;&lt;P&gt;- Familiarity for analysts - since it’s SQL-based, a team of BAs or analysts with strong SQL skills can be productive quickly.&lt;/P&gt;&lt;P&gt;- Open source -&amp;nbsp; community-driven and not tied to a single vendor.&lt;/P&gt;&lt;P&gt;That said, dbt has limitations. It focuses mainly on the “T” in ETL/ELT. It doesn’t handle the extraction part, and its orchestration capabilities are more limited compared to native tools.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;As about strengths of Declarative Pipelines:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;- Supports ingestion as well as transformation - full ETL process&amp;nbsp;&lt;/P&gt;&lt;P&gt;- SQL and Python support - Python provides more flexibility, automation, and complex transformations for experienced teams.&lt;/P&gt;&lt;P&gt;- Tight integration with Databricks Unity Catalog and the broader ecosystem - since it's a native product, it often feels more seamless and coherent.&lt;/P&gt;&lt;P&gt;- Efficient incremental loading - I think DLT should handle incremental loading in a better manner thanks to features like the Enzyme engine and auto-optimization&lt;/P&gt;&lt;P&gt;- Ifrastructure management - DLT manages the underlying compute resources and integrates with Databricks Workflows, while dbt requires external orchestration tools.&lt;/P&gt;&lt;P&gt;- Streaming: DLT has native support for streaming data, whereas dbt can handle streaming via the dbt-databricks package.&lt;/P&gt;&lt;P&gt;On the other hand, there are trade-offs. The entry barrier is higher, and for now, there’s still an element of vendor lock-in. Databricks has announced plans to donate Declarative Pipelines to open source, but feature parity isn’t there yet, and practically speaking, choosing it means committing to the Databricks ecosystem.&lt;/P&gt;&lt;P&gt;My personal take: If your entire platform is already built on Databricks, Declarative Pipelines are a strong choice. If you need flexibility to run your pipelines on other databases or cloud platforms, dbt might be the safer choice.&lt;/P&gt;</description>
    <pubDate>Sun, 24 Aug 2025 10:08:54 GMT</pubDate>
    <dc:creator>szymon_dybczak</dc:creator>
    <dc:date>2025-08-24T10:08:54Z</dc:date>
    <item>
      <title>Opinions/Thoughts: SQL Best Practices in Production .. DBT vs DLT ?</title>
      <link>https://community.databricks.com/t5/data-engineering/opinions-thoughts-sql-best-practices-in-production-dbt-vs-dlt/m-p/129479#M48545</link>
      <description>&lt;P&gt;Hey everyone,&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;I'd like to hear the experiences of the community on DLT (Lakeflow declarative pipelines) vs DBT.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;1. Why would one choose one instead of the other?&amp;nbsp;&lt;BR /&gt;2. How does picking one of these level up your SQL strategy?&lt;BR /&gt;&lt;BR /&gt;I am somebody who's well-versed in using SQL to answer business problems (more of an analyst). I'd love to know the next steps for levelling up &amp;amp; using best practices.&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;All the best,&lt;BR /&gt;BS&lt;/P&gt;</description>
      <pubDate>Sun, 24 Aug 2025 09:30:05 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/opinions-thoughts-sql-best-practices-in-production-dbt-vs-dlt/m-p/129479#M48545</guid>
      <dc:creator>BS_THE_ANALYST</dc:creator>
      <dc:date>2025-08-24T09:30:05Z</dc:date>
    </item>
    <item>
      <title>Re: Opinions/Thoughts: SQL Best Practices in Production .. DBT vs DLT ?</title>
      <link>https://community.databricks.com/t5/data-engineering/opinions-thoughts-sql-best-practices-in-production-dbt-vs-dlt/m-p/129484#M48546</link>
      <description>&lt;P&gt;Hi&amp;nbsp;&lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/146924"&gt;@BS_THE_ANALYST&lt;/a&gt;&amp;nbsp;,&lt;/P&gt;&lt;P&gt;That’s a really good question! I don’t think there’s a single definitive answer, since the choice depends on several factors. Each framework has its own advantages and disadvantages.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;In my opinions strengths of dbt are:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;- Wide adoption - dbt is very popular, with a large and active community.&lt;/P&gt;&lt;P&gt;- SQL on steriods - you can write transformations purely in SQL, but dbt also supports Jinja templating, which makes it easier to add loops, conditionals, and other logic.&lt;/P&gt;&lt;P&gt;- Auto-generated documentation -&lt;/P&gt;&lt;P&gt;- Support for multiple environments - it fits nicely into dev/test/prod setups.&lt;/P&gt;&lt;P&gt;- Familiarity for analysts - since it’s SQL-based, a team of BAs or analysts with strong SQL skills can be productive quickly.&lt;/P&gt;&lt;P&gt;- Open source -&amp;nbsp; community-driven and not tied to a single vendor.&lt;/P&gt;&lt;P&gt;That said, dbt has limitations. It focuses mainly on the “T” in ETL/ELT. It doesn’t handle the extraction part, and its orchestration capabilities are more limited compared to native tools.&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;As about strengths of Declarative Pipelines:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;- Supports ingestion as well as transformation - full ETL process&amp;nbsp;&lt;/P&gt;&lt;P&gt;- SQL and Python support - Python provides more flexibility, automation, and complex transformations for experienced teams.&lt;/P&gt;&lt;P&gt;- Tight integration with Databricks Unity Catalog and the broader ecosystem - since it's a native product, it often feels more seamless and coherent.&lt;/P&gt;&lt;P&gt;- Efficient incremental loading - I think DLT should handle incremental loading in a better manner thanks to features like the Enzyme engine and auto-optimization&lt;/P&gt;&lt;P&gt;- Ifrastructure management - DLT manages the underlying compute resources and integrates with Databricks Workflows, while dbt requires external orchestration tools.&lt;/P&gt;&lt;P&gt;- Streaming: DLT has native support for streaming data, whereas dbt can handle streaming via the dbt-databricks package.&lt;/P&gt;&lt;P&gt;On the other hand, there are trade-offs. The entry barrier is higher, and for now, there’s still an element of vendor lock-in. Databricks has announced plans to donate Declarative Pipelines to open source, but feature parity isn’t there yet, and practically speaking, choosing it means committing to the Databricks ecosystem.&lt;/P&gt;&lt;P&gt;My personal take: If your entire platform is already built on Databricks, Declarative Pipelines are a strong choice. If you need flexibility to run your pipelines on other databases or cloud platforms, dbt might be the safer choice.&lt;/P&gt;</description>
      <pubDate>Sun, 24 Aug 2025 10:08:54 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/opinions-thoughts-sql-best-practices-in-production-dbt-vs-dlt/m-p/129484#M48546</guid>
      <dc:creator>szymon_dybczak</dc:creator>
      <dc:date>2025-08-24T10:08:54Z</dc:date>
    </item>
    <item>
      <title>Re: Opinions/Thoughts: SQL Best Practices in Production .. DBT vs DLT ?</title>
      <link>https://community.databricks.com/t5/data-engineering/opinions-thoughts-sql-best-practices-in-production-dbt-vs-dlt/m-p/129487#M48547</link>
      <description>&lt;P&gt;That's a cracking write up&amp;nbsp;&lt;a href="https://community.databricks.com/t5/user/viewprofilepage/user-id/110502"&gt;@szymon_dybczak&lt;/a&gt;.&amp;nbsp;Thanks for that &lt;span class="lia-unicode-emoji" title=":handshake:"&gt;🤝&lt;/span&gt;.&lt;BR /&gt;&lt;BR /&gt;That's certainly given me some food for thought. I think the safest option here, at least for me, is digging into both of them. I feel better informed moving forward with this.&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;I'd love to hear about people's experiences/thoughts on working with either DBT/DLT and how they've found it in practice? The pros and cons they've found, and most importantly, what they'd have done differently whilst adopting DBT or DLT.&lt;BR /&gt;&lt;BR /&gt;All the best,&lt;BR /&gt;BS&lt;/P&gt;</description>
      <pubDate>Sun, 24 Aug 2025 10:27:04 GMT</pubDate>
      <guid>https://community.databricks.com/t5/data-engineering/opinions-thoughts-sql-best-practices-in-production-dbt-vs-dlt/m-p/129487#M48547</guid>
      <dc:creator>BS_THE_ANALYST</dc:creator>
      <dc:date>2025-08-24T10:27:04Z</dc:date>
    </item>
  </channel>
</rss>

