dbt Core

Same as dbt Cloud — execution speed is determined by the warehouse, not dbt itself. dbt orchestration overhead is tens of milliseconds per model; the actual SELECT or CREATE TABLE runs at warehouse speed. Cap rule N/A. Compilation is fast (sub-second for typical projects), and parallel execution via --threads scales linearly to warehouse-cluster limits.

Jinja + SQL templates are the well-known mental model for data transformation. {{ ref('upstream_model') }}, {{ source('schema', 'table') }}, {{ var('environment') }} feel natural to anyone who's written SQL. macros provide reusable abstractions without leaving the SQL paradigm. Cap rule N/A — Jinja is a standard templating language, not a 'proprietary query language' in the methodology sense.

RBAC at warehouse level (Snowflake roles, BigQuery IAM, Postgres GRANT); dbt orchestrates but doesn't enforce its own permission model. Cap rule applied: 'RBAC-only without ABAC -> cap at 3.' For ABAC over transformed data, push policy enforcement to L5 (OPA, Cedar) or use warehouse RLS at L1 (e.g., Postgres RLS, Snowflake row access policies).

Runs on any orchestrator: GitHub Actions for CI/CD, Airflow for production scheduling, Dagster for asset-aware orchestration, Prefect for workflow management, Kubernetes CronJobs for simple cases, even cron + bash. Cap rule N/A. dbt Cloud (A=4) pins you to their managed runtime — dbt Core gives you orchestration sovereignty.

Many warehouse adapters: Snowflake, BigQuery, Redshift, Postgres, Spark, Databricks, DuckDB, Trino, MS SQL Server, Synapse, Materialize, dozens more via community packages. Cross-warehouse models work. Cap rule N/A.

Run results metadata is comprehensive (every model run logs duration, rows affected, errors, dependencies), and dbt's lineage graph provides full transformation transparency. But no native cost attribution — dbt doesn't know how much each model run costs. Cap rule N/A. For cost transparency, integrate with warehouse-side accounting (Snowflake QUERY_HISTORY, BigQuery INFORMATION_SCHEMA) or a layer like SELECT.dev.

G1=N (no runtime ABAC — dbt is build-time only, runtime authorization is the warehouse's responsibility), G2=Y (run logs cover every transformation execution with full input/output metadata), G3=Y (PR review IS HITL — dbt's Git-first workflow means every transformation change goes through human review before merge), G4=Y (dbt is built around model versioning — sources, exposures, packages all carry semantic versioning), G5=N (no AI threat modeling in transformation scope), G6=Y (deployment-mapped compliance via the warehouse — Snowflake's SOC 2 covers transformation outputs, Postgres on RDS covers HIPAA via BAA). 4/6 -> 4.

O1=Y (run metrics: rows, duration, success rates exposed via run_results.json), O2=N (no native distributed tracing — though manifest.json + run_results.json give run-level visibility), O3=N (LLM cost tracking N/A; warehouse query cost is the analog and isn't tracked natively), O4=Y (run failures detected immediately via dbt run --status; integrates with PagerDuty, Slack, etc.), O5=Y (freshness checks built-in via dbt source freshness — explicit drift detection at the data layer), O6=Y (lineage graph IS explainability — every column in every model can be traced back through dependencies). dbt Core lacks Cloud's enhanced observability suite (continuous CI metadata, semantic layer telemetry). 4/6 -> 4.

A1=Y (sub-2s p95 — dbt operational metadata commands are fast), A2=Y (freshness checks built-in for data freshness SLA enforcement), A3=Y (warehouse cache: Snowflake, BigQuery materialized views, etc., reduce repeat-query costs), A4=Y (CI/CD reliability — dbt Core in GitHub Actions or equivalent achieves >99.9% pipeline reliability with proper testing), A5=N (rarely 10x-load-tested by most teams — capacity planning is the warehouse's responsibility), A6=Y (--threads parallel execution scales linearly to warehouse cluster limits). 5/6 -> 4.

L1=Y (dbt models normalize entities — same customer across silos becomes one canonical model), L2=Y (sources + exposures + tests document the data dictionary, lenient interp — sources file IS the glossary), L3=N (no NL disambiguation — dbt is SQL-first, not natural-language-first), L4=N (no continuous learning — dbt is rule-based transformation), L5=Y (dbt enforces canonical naming via project conventions, schema YAML, naming patterns), L6=Y (PR review IS human evaluation of every transformation change). dbt Core lacks the Semantic Layer (Cloud+ tier feature) — that's the 1-point gap to dbt Cloud's L=5. 4/6 -> 4.

S1=Y (dbt tests assert accuracy: not_null, unique, accepted_values, custom assertions), S2=Y (dbt tests check completeness via not_null and source freshness), S3=Y (cross-system consistency enforced via ref() and source() — single source of truth per model), S4=Y (schema tests + dbt-expectations + dbt-utils provide schema validation), S5=Y (dbt's test framework as 3-stage gate: source tests + intermediate model tests + final mart tests), S6=N (anomaly detection via integrations like dbt-expectations or external tools, not native). 5/6 -> 4.