Apache-2.0 dbt engine for transforming warehouse data with SQL models, Jinja, YAML configs, tests, documentation, lineage, metadata, and build artifacts.
Open the source and read safety notes before installing.
Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.
Decision playbook
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
0
78
—
No baseline selected
No major trust-signal divergence detected in the current selection.
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Source provenance statusRequired
Marked as source-backed.
Metadata reviewed
Registry metadata indicates a reviewed listing.
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Trust level risk gateRequired
Trust level does not block evaluation.
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Package verification flag
No package verification flag provided.
Checksum metadata
No checksum provided for downloaded artifact.
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Baseline comparison available
No baseline peer selected yet.
Diverging trust signals identified
No major trust-signal divergence found.
Setup at a glance
Copy-ready — paste the snippet to get started.
Adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Confirm metadata review state
Listing has review metadata.
Verify install payload
Install/config payload exists and can be inspected.
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Review privacy notesRequired
Privacy notes are present.
Verify package integrity metadata
No package verification/checksum metadata.
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Evidence readiness
Required evidence gates are covered (5/6 signals complete).
Source repository/provenance is listed.
Required in this preset
Review metadata is present.
Required in this preset
Safety notes are present.
Required in this preset
Privacy notes are present.
Optional in this preset
Package integrity metadata is missing.
Optional in this preset
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
5/6 steps complete with no blocking gaps for this preset.
triage
Source/provenance metadata is available.
triage
Review metadata is available.
verify
Safety notes are available.
verify
Privacy notes are available.
verify
Package integrity metadata is missing.
rollout
Install payload is available.
No required blockers for this timeline preset.
Prerequisite readiness
5 prerequisites to line up before setup. Have accounts and credentials ready first. Includes a review or approval gate.
Safety & privacy surface
6 safety and 5 privacy notes across 6 risk areas. Review closely: credentials & tokens, permissions & scopes.
Disclosure: editorial
## Editorial notes
dbt Core is useful when Claude-adjacent teams need repeatable analytics engineering workflows around warehouse transformations, model dependencies, tests, documentation, metadata artifacts, source freshness, and CI-reviewed SQL changes. It gives data teams a code-first way to build trusted data products from SQL select statements while keeping transformations versioned, testable, reviewable, and documented.
This is distinct from Apache Airflow and Dagster. Airflow schedules and monitors workflow DAGs. Dagster orchestrates assets and operational metadata. dbt Core is the data transformation engine and project framework that compiles, tests, documents, and runs SQL-based transformation graphs in a data platform. It is also distinct from the hosted dbt platform and from optional AI or Fusion workflows, which may have separate product terms.
## Source notes
- The official repository says dbt enables data analysts and engineers to transform data using the same practices that software engineers use to build applications.
- The official docs say dbt transforms raw warehouse data into trusted data products by letting users write SQL select statements while dbt creates modular, maintainable data models.
- The docs say dbt projects create structured context such as lineage, tests, contracts, metrics, and governance.
- The docs describe the dbt framework as a language and engine, with SQL select statements, Jinja templating, YAML configs, tests, and metadata.
- The docs describe dbt Core v1 as the open-source Python-based engine and dbt Core v2 as the open-source foundation for the Fusion engine that is currently in alpha.
- The current repository README warns that dbt Core v1 development has moved to the `1.latest` branch and that `main` hosts dbt Core v2.0 alpha.
- The README says dbt Core v2.0 is Apache-2.0 licensed, built for performance at scale, produces Parquet artifacts, and is distributed as a self-contained binary.
- The `1.latest` README describes dbt models as SQL select statements that build on one another, with relationship management, visualization, and testing.
- The installation docs describe dbt Core as the open-source engine for running dbt locally and distinguish dbt Core v1 from dbt Core v2 alpha.
- The profiles docs say command-line dbt uses `profiles.yml` for data-platform connection details, target definitions, execution parameters, and credential separation.
- The artifact docs describe manifests, run results, catalogs, source freshness, semantic manifests, target-directory output, invocation metadata, adapter type, and environment metadata.
- The events and logs docs describe command-line output and `logs/dbt.log` debug logs with runtime context.
- The usage-stats docs describe default telemetry, stated exclusions for credentials, raw model contents, and model names, and dbt Core opt-out paths.
- The repository is `dbt-labs/dbt-core`, is Apache-2.0 licensed, and is active.
## Duplicate check
Checked current `content/tools/`, `content/mcp/`, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for `dbt Core`, `dbt`, `dbt-labs/dbt-core`, `github.com/dbt-labs/dbt-core`, `docs.getdbt.com`, `analytics engineering`, and `SQL models`. No dedicated dbt Core tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.
## Disclosure
Editorial listing. No paid placement or affiliate link is used. dbt Core is Apache-2.0 open-source software; dbt platform, dbt Fusion engine, dbt Wizard, dbt Copilot, data platforms, adapters, packages, cloud warehouses, CI systems, and downstream analytics tools may have separate licenses, billing, terms, privacy obligations, and access controls.dbt Core is useful when Claude-adjacent teams need repeatable analytics engineering workflows around warehouse transformations, model dependencies, tests, documentation, metadata artifacts, source freshness, and CI-reviewed SQL changes. It gives data teams a code-first way to build trusted data products from SQL select statements while keeping transformations versioned, testable, reviewable, and documented.
This is distinct from Apache Airflow and Dagster. Airflow schedules and monitors workflow DAGs. Dagster orchestrates assets and operational metadata. dbt Core is the data transformation engine and project framework that compiles, tests, documents, and runs SQL-based transformation graphs in a data platform. It is also distinct from the hosted dbt platform and from optional AI or Fusion workflows, which may have separate product terms.
1.latest branch and that main hosts dbt Core v2.0 alpha.1.latest README describes dbt models as SQL select statements that build on one another, with relationship management, visualization, and testing.profiles.yml for data-platform connection details, target definitions, execution parameters, and credential separation.logs/dbt.log debug logs with runtime context.dbt-labs/dbt-core, is Apache-2.0 licensed, and is active.Checked current content/tools/, content/mcp/, agents, hooks, rules, skills, commands, guides, collections, open pull requests, live issue state, and repository-wide content for dbt Core, dbt, dbt-labs/dbt-core, github.com/dbt-labs/dbt-core, docs.getdbt.com, analytics engineering, and SQL models. No dedicated dbt Core tools entry, source URL duplicate, target file, issue duplicate, or open duplicate PR was found.
Editorial listing. No paid placement or affiliate link is used. dbt Core is Apache-2.0 open-source software; dbt platform, dbt Fusion engine, dbt Wizard, dbt Copilot, data platforms, adapters, packages, cloud warehouses, CI systems, and downstream analytics tools may have separate licenses, billing, terms, privacy obligations, and access controls.
Show that dbt Core is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/tools/dbt-core)dbt Core side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
| Field | Apache-2.0 dbt engine for transforming warehouse data with SQL models, Jinja, YAML configs, tests, documentation, lineage, metadata, and build artifacts. Open dossier | MIT-licensed embedded analytical SQL database for local OLAP workloads, data files, notebooks, Python and R clients, extensions, and single-file analytics workflows. Open dossier | Apache-2.0 GX Core Python library for data quality Expectations, validation definitions, checkpoints, Data Docs, metadata stores, and pipeline quality checks. Open dossier | Apache-2.0 reactive Python notebook stored as pure Python for reproducible experiments, SQL-backed data workflows, script execution, app deployment, and AI-assisted editing. Open dossier |
|---|---|---|---|---|
| Next steps | ||||
| Trust | ||||
| Review status | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed | ReviewedMaintainer reviewed |
| Package trust | Package not verified | Package not verified | Package not verified | Package not verified |
| Source provenance | Source-backed | Source-backed | Source-backed | Source-backed |
| Submitter | oktofeesh1 | oktofeesh1 | oktofeesh1 | oktofeesh1 |
| Install risk | Review first | Review first | Review first | Review first |
| Notes | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ | Safety ✓ Privacy ✓ |
| Brand | ||||
| Category | tools | tools | tools | tools |
| Source | Source-backed | Source-backed | Source-backed | Source-backed |
| Author | dbt Labs | DuckDB Foundation | Great Expectations | Marimo Team |
| Added | 2026-06-04 | 2026-06-04 | 2026-06-04 | 2026-06-04 |
| Platforms | ||||
| Harness | ||||
| Source repo | — | — | — | — |
| Safety notes | ✓dbt runs transformation SQL against a data platform and can create, replace, or mutate warehouse objects, so development and production targets should be separated and permissioned carefully. The current `dbt-labs/dbt-core` README warns that `main` hosts dbt Core v2.0 alpha, that behavior, APIs, and on-disk formats may change, and that dbt Core v1 development has moved to `1.latest`. Version, adapter, package, and artifact compatibility should be pinned and tested before upgrading shared projects or production jobs. Model tests, contracts, lineage, and documentation improve confidence, but they do not replace data review, access controls, warehouse governance, freshness checks, or incident response. Threads, full refreshes, incremental logic, and CI jobs can consume warehouse budget or lock shared resources; teams should set concurrency, timeout, and rollback expectations before broad automation. Profile files and environment variables can contain sensitive warehouse credentials, so `profiles.yml` should stay out of git, logs, generated docs, screenshots, and shared support artifacts. | ✓DuckDB SQL should be treated like executable code because queries can read and write files, access network resources through extensions, load extensions, consume system resources, and mutate attached databases. Applications that accept user-controlled SQL, file paths, table names, filter expressions, or data-source settings need sandboxing and allowlists rather than passing those values directly into DuckDB operations. Extensions run with the same privileges as the DuckDB process, and community extensions should only be installed from trusted sources after reviewing their maintenance and distribution path. Statements such as `ATTACH`, `COPY`, `EXPORT DATABASE`, `CREATE SECRET`, `INSERT`, `UPDATE`, and `DELETE` can change local files, databases, or connected services when permissions allow it. Analytical queries can use substantial CPU, memory, temporary disk, and object-store bandwidth, so shared automations should configure memory, thread, timeout, temp-directory, and retry expectations. Persistent database files and write-ahead logs need backups, file permissions, and recovery procedures before DuckDB is used for durable or production-adjacent analytical state. | ✓GX Core validations can query databases, scan files, evaluate DataFrames, and compute metrics over real datasets, so production runs should use scoped credentials, tested queries, and bounded resources. Checkpoints can trigger Actions such as updating Data Docs, sending notifications, or running custom logic based on Validation Results; notification endpoints and custom Actions should be reviewed before automation. Data Docs generate static human-readable documentation from Expectations, Validation Results, and metadata, so hosted sites and generated folders need access controls before they include sensitive details. Result formats and unexpected-row retrieval can expose row-level failures or sample values; teams should tune result verbosity before publishing results to logs, tickets, chat, or docs sites. Custom Expectations, custom Actions, SQL-based custom Expectations, and orchestration integrations run team-provided code or queries and should be treated as trusted project code. GX Core compatibility depends on Python, data source, integration, and optional dependency support, so upgrades should be tested against the compatibility reference and existing validation suites. | ✓Marimo notebooks execute Python and SQL, can write files, query databases, call APIs, access object storage, install packages, and start web servers, so notebooks should be treated as trusted project code. Reactive execution automatically tracks variable dependencies and can run downstream cells after upstream changes; expensive, destructive, or side-effectful cells need lazy runtime, disabled cells, startup autorun, and manual-run policies. The docs note that Marimo tracks variable definitions and references statically, not arbitrary mutations across cells, so mutable shared state should be designed carefully to avoid misleading results. App mode uses `marimo run` to serve notebooks as web apps with code hidden by default, but public deployments still need authentication, authorization, rate limiting, reverse proxy policy, and traceback disclosure review. Disabling token protection, passing access tokens in URLs, or exposing edit servers can give unauthorized users access to notebook execution and should be avoided outside controlled environments. SQL cells can interpolate Python values, query local files and remote databases, and use engines or extensions such as DuckDB, so SQL strings, credentials, object paths, and output destinations should be reviewed before automation. Built-in AI and copilot features may inspect notebook code, prompts, tool context, and referenced variable values; provider selection, API keys, local model behavior, and cost controls should be configured deliberately. Package-management features can serialize requirements and auto-install dependencies into notebook-specific environments, so teams should pin, review, and scan packages before sharing or deploying notebooks. |
| Privacy notes | ✓dbt workflows can process SQL models, Jinja macros, YAML configs, sources, tests, seeds, snapshots, metrics, exposures, connection profiles, warehouse relation names, logs, and generated artifacts. Command output and `logs/dbt.log` can include invocation arguments, runtime context, thread names, node metadata, warehouse relation identifiers, errors, and other debugging details. dbt artifacts are written to the project's `target/` directory by default and may include manifests, run results, catalogs, source freshness output, semantic manifests, invocation IDs, adapter types, project metadata, and selected environment metadata. The artifacts docs say environment variables prefixed with `DBT_ENV_CUSTOM_ENV_` can be included in artifact metadata, so teams should avoid placing secrets in those variables. The usage-stats docs say dbt telemetry is enabled by default and does not track credentials, raw model contents, or model names; dbt Core users can opt out by setting `send_anonymous_usage_stats` to false or `DO_NOT_TRACK=1`. | ✓DuckDB workflows can process local files, database files, notebooks, query text, table names, column names, object-store paths, data-frame contents, connection strings, secrets, extensions, and generated result sets. The files-created docs describe global files such as `~/.duckdb_history`, extension directories, and stored persistent secrets, so users should avoid typing credentials or sensitive data into ad hoc SQL history. Persistent secrets are stored under DuckDB's configured secret directory, and `duckdb_secrets()` redacts sensitive fields by default; enabling unredacted secret output is unsafe with untrusted SQL. On-disk databases can create database files, write-ahead logs, and temporary directories next to the database file or working directory, depending on connection mode and configuration. HTTP, S3, and other external-data workflows can expose object-store identifiers, paths, credentials, request metadata, and result data to the connected service and any configured logs or monitoring. | ✓GX Core workflows can process source data, schemas, table names, file paths, SQL queries, Batch metadata, Expectation Suites, Validation Results, Checkpoints, Actions, Data Docs, and generated stores. The credentials docs say tokens and connection strings should be stored securely outside version control, using environment variables, uncommitted config files, or supported secrets managers. File Data Context Stores can persist Expectation Suites, Validation Definitions, Checkpoints, Validation Results, and Suite Parameters in project folders or configured backends. Data Docs are static web pages generated from Expectations, Validation Results, and metadata; publishing them can disclose validation outcomes, column names, dataset structure, and failing examples. GX Core tracks analytics events by default, including feature usage, operating system, and Python version, and the docs describe disabling collection with `GX_ANALYTICS_ENABLED` or `analytics_enabled`. | ✓Marimo workflows can process notebook source code, cell outputs, variable values, DataFrames, SQL queries, schemas, database rows, object-store paths, generated apps, CLI arguments, logs, and exported artifacts. User configuration can store runtime, server, completion, and AI-provider settings, while app configuration can live inside notebook files; secrets should stay in environment variables or secret stores rather than committed notebooks. AI-assisted editing can send prompts, notebook context, code, schemas, and referenced in-memory values to configured hosted providers, or to local model services when those are selected. Database and remote-storage workflows can expose connection strings, credentials, table names, bucket names, object keys, query text, sample rows, and download paths to notebooks, logs, cloud services, and deployed apps. Token login, query-parameter access tokens, Basic auth headers, reverse-proxy headers, and server logs should be handled as sensitive operational data. |
| Prerequisites |
|
|
|
|
| Install | — | — | — | — |
| Config | — | — | — | — |
| Citations | ||||
| Claim | Unclaimed | Unclaimed | Unclaimed | Unclaimed |
Run embedded analytical SQL over local files, data frames, and DuckDB databases.
Define, run, document, and automate data quality validations with GX Core.
Loading live community signals…
A short, calm digest of reviewed Claude resources. Unsubscribe any time.