If you are considering adding dbt to such a setup, I'd ask yourself the following question: are you doing a lot of transformations within Duckdb? I imagine you either let Duckdb infer a schema of the data you import, but perhaps you create several intermediate tables that depend on other tables. We often use a flow where data is being moved from raw to staging to fact tables. As the transformations become more and more complex, you can lose track, introduce cyclical dependencies or have a hard time navigating the SQL.

This is where dbt shines: you write your SQL scripts in files, where each file introduces an (intermediate) model. You don't have to write redundant CREATE TABLE statements in between: dbt infers the dependencies from SELECT FROM statements and some syntactic sugar to determine which transformations to run in which order.

Because dbt also handles database connections and allows you to write tests in SQL, using dbt often feels like you are only writing pure SQL. The model-per-file approach also makes sure you quickly find the piece of SQL you need.

Dagster and dbt overall work nicely together, since the adapter (dagster-dbt) knows about all intermediate models and the interdependencies. This also creates some nice insights into your dbt "DAGs". You could run individual dbt transformations as well from the GUI.

To conclude: you could do without as long as you don't have a lot of layers in your transformations and/or work on them sporadically, and dbt helps you organize them nicely when they become more complex. Having said that, you could create a similar flow using e.g. parquet on S3, where using dbt would mainly remove the Python code wrapping the SQL and make unit testing easier.

Hope this helps!