vscode-dbt-power-user turns VS Code into a dbt workbench

What the extension actually adds to the editor

The extension is described as making VS Code work closely with dbt, and the feature table breaks that into eleven areas. Autocomplete fills model names, macros, sources and docs, and clicking any of them jumps to the definition. Preview query results generates a model's or a query's results, which you can export as CSV or analyse by creating graphs, filters and groups. Column lineage shows model lineage and column lineage, with components including models, seeds, sources, exposures, and information about model types, tests, documentation and linkage types. There is model generation from sources defined in YAML, or conversion of existing SQL into a dbt model with references populated automatically. Documentation can be generated for models and columns or written by hand in the UI editor, with descriptions formatted and saved into YAML files. Defer to prod, a BigQuery cost estimator, a project health check, an SQL validator, and a dbt logs viewer that can force tailing. The common thread is that everything happens in the editor window, against your project, without switching to a browser tab.

The compiled query preview, and why it is the useful one

The compiled query preview and explanation feature is the one that changes how you work with dbt, and it deserves more attention than the rest. It gives a live preview of the compiled query as you write code, which means you see the SQL that dbt actually produces after Jinja templating, the ref resolution and any config overrides are applied. Writing Jinja-SQL is genuinely hard to debug, because the source you wrote is not the statement that runs, and the extension closes that gap by showing the result. The same feature generates explanations for dbt code written previously by somebody else, which is the harder half of the problem. On a project you did not write, the compiled output tells you what the model does, and the explanation turns the compiled SQL into prose you can read. For a team taking over an existing warehouse, that is a large share of the value on its own, and it is the reason the feature is listed separately from the preview results panel.

Defer to prod, and the cost of rebuilding upstream models

Defer to prod addresses a specific and expensive annoyance. When you change a model in development, dbt normally rebuilds its upstream models first, and on a large project that means a long wait for a change you did not make. The deferral feature lets you build your model in development without building the upstream models, by referencing production models instead, and the documentation points to the dbt blog post that introduces the concept. It notes that this functionality can be used in dbt Core with the extension, which matters because the feature is often assumed to require the paid hosted product. The cost of deferral is the one worth naming. The model you build is computed against production state for its parents rather than against the state you have locally, so a change that depends on a parent's changed values will not be exercised by your build. It is a development loop optimisation, not a way to model reality, and a project where several models are being changed at once needs care about which of them are deferred.

Health check and the SQL validator as two different layers

Two checking features sit at different levels and are worth separating. The project health check looks at the dbt project itself, identifying issues such as columns that are not present and models that were never built, which is a project state problem rather than a code problem. The SQL validator works on the SQL text, identifying mistyped keywords, extra or missing parentheses, and columns that are not present in the database. That distinction is the useful part. A column-not-present error caught by the validator is a syntax level mistake in one file, while a column-not-present error caught by the health check is a modelling problem where the schema and the project disagree. The health check is the one that tends to be missing from a team's own tooling, because it requires understanding the project's manifest and the warehouse together, which is exactly what an editor with both connections can do. Both are described as identifying issues rather than as passing or failing, so treat their output as a list of things to look at rather than a gate.

Where the extension runs, and what it needs

The extension is fully compatible with dev containers, code spaces and remote extension hosts, and the documentation links the VS Code Remote Containers and Remote WSL pages. That compatibility has a practical consequence for a team standardising on containers, because the extension has to run where the dbt project and the warehouse credentials are, and the documentation's claim is that it works in both places. The manifest declares the activation event in the manifest itself, a single workspaceContains pattern, which means the extension starts itself when a dbt project is present in the workspace and stays dormant otherwise.

  "activationEvents": [
    "workspaceContains:**/dbt_project.yml"
  ],

The manifest requires VS Code ^1.95.0 and Node 20 or newer, and the categories it declares are Programming Languages, Snippets, Data Science, Formatters and Testing, with hoverProvider set to true. The repository itself is a substantial TypeScript project with src/, webview_panels/, snippets/, syntaxes/ and test-fixtures/ directories, a Jest configuration, a Husky setup, a Prettier config, an rsbuild configuration, and a .claude/ directory alongside the .mcp.json file.

Installing from the marketplace, and where the setup guide lives

The extension is open source under the MIT licence and published on the Visual Studio Marketplace as Power User for dbt, with the marketplace identifier innoverio.vscode-dbt-power-user. The project is maintained under the AltimateAI organisation, and the homepage is altimate.ai. The extension is installed from the Visual Studio Marketplace, and the documentation for setup lives on docs.myaltimate.com rather than in the repository, and issues and bugs are directed to the vendor's support channel by chat or Slack rather than to a public tracker. That arrangement is worth being explicit about, because it is a common pattern in this category of extension and it affects what you can expect. The code is available to read, fork and self host under MIT, but the guidance, the support path and the surrounding product belong to the vendor. The release history shows the same split in practice, with the extension version and the bundled dbt integration version moving separately, such as 0.65.1 shipping dbt-integration 0.3.15 with Python bridge shutdown fixes, and 0.65.0 adding project governance checks.

Where the extension is the wrong tool

The boundary is around what the feature set does not cover. This is an editor integration, not a deployment tool, and the documentation lists nothing about promoting environments, managing seeds, scheduling jobs or handling the state of a dbt Cloud project. If your team's day is spent in the dbt Cloud web interface on a run history page or a deployment screen, the extension does not improve that. The BigQuery cost estimator is also narrow by construction, since it estimates data that will be processed by a dbt model in BigQuery, so a warehouse on Snowflake or Redshift gets nothing from it. And the deferral and health check features both need a live connection to the warehouse, so in an environment where analysts work against a warehouse they cannot reach, the parts of the extension that matter most degrade into the parts that still work offline, which are the autocomplete, the validator and the snippet set. The AI documentation generation and explanations are the features most likely to be worth a trial on their own.

Editorial conclusion

Adopt Power User for dbt if your analytics engineers write SQL in VS Code all day and want dbt awareness without leaving the editor, particularly the compiled query preview and the column lineage, which are the two features with no equivalent in a plain text editor. Do not adopt it if your team works in dbt Cloud's own web interface and is happy there, or if you need it to manage deployments and environments, since the documented feature set is read and analyse oriented. Verify two things first: that the extension activates in your setup, which depends on it finding a dbt_project.yml in the workspace because that is the activation event, and that your dbt version is above 1.0, which the documentation states as the supported range. The practical first step is to install it from the marketplace, open a dbt project, and confirm the compiled query preview renders for one model before enabling the rest of the panels.

Frequently asked questions

Official sources

1. AltimateAI/vscode-dbt-power-user on GitHub
2. License: MIT
3. Project website
4. README
5. Releases