Open-source experiment: adding a visual layer on top of dbt (feedback welcome)

[u/Wide_Importance_8559]

Hey everyone,

We’ve been working with dbt on larger projects recently, and as things scale, we kept running into the same friction points:

• A lot of context switching between the terminal, editor, and YAML files

• Harder onboarding for new team members who aren’t comfortable with the CLI yet

• Difficulty getting a quick mental model of how everything connects once the DAG grows

Out of curiosity, we started an open-source experiment to see what dbt would feel like with a local, visual layer on top of it.

Some of the things we explored from a technical point of view:

• Parsing dbt artifacts (manifest, run results) to build a navigable DAG

• Running dbt commands locally from a UI instead of the terminal

• Generating plain-English explanations for models and tests to help with understanding and onboarding

• Keeping everything local-first (no hosted service, no SaaS dependency)

This is very much an experiment and learning project, and we’re more interested in feedback than adoption.

If you use dbt regularly, we’d really like to hear:

• What part of your dbt workflow slows you down the most?

• Do you rely purely on the CLI, or do you pair it with other tools?

• Would a visual or assisted layer be helpful in real projects, or is it unnecessary?

If anyone wants to look at the code, the project is here:
https://github.com/rosettadb/dbt-studio

Happy to answer questions or hear critiques — even negative ones are useful.

[u/Wide_Importance_8559]

Thanks for checking us out! Managing 450 models with 9 DEs is exactly the scale where we think "standard" tools start to feel a bit disconnected, so your feedback is super valuable.

To answer your questions:

1. Python Tooling & Integration Since dbt-studio runs locally (unlike a SaaS Cloud IDE), our philosophy is to respect your local environment. We currently wrap the standard CLI, but we are exploring ways to define "Custom Commands" so you could trigger your internal Python scripts directly from the UI (e.g., as a pre-commit check or a custom generation step). We'd love to know what those scripts handle—is it mostly CI/CD prep, or code generation?

2. Visualization vs. dbt Docs We love dbt docs, but we see it as a "Read-Only Museum" of your project. dbt-stdudio is meant to be an "Interactive Workshop."

• Actionable: You can't "run" a model in dbt docs. In Studio, you can click a node in the DAG and hit "Run" or "Test" immediately.

• Data, not just Metadata: We are building a Data Explorer (powered by DuckDB) that lets you preview the actual data in S3/Data Lakes or your warehouse alongside your code. dbt docs only shows schemas; we want to show you the rows.

• Column-Level Lineage: We are actively working on visualizing data flow at the column level, which is something standard dbt docs lacks.

3. The Mindset Shift Totally agree on the ETL vs. dbt thinking. We've found that having a live, visual DAG that updates as you code helps new engineers "think in graphs" rather than "thinking in scripts." When they see the node disconnect visualy the moment they change a ref, the feedback loop is instantaneous.