dbt Python models run remotely on your data platform, not locally. dbt compiles and submits the code, and the platform executes it, using packages available to its Python runtime. That means a Python model adds a second dependency tree that your SQL only project never had, with its own review needs.
What the docs say
The dbt documentation states that in a Python model, all code is executed remotely on the platform and none of it is run by dbt locally. A model is a file defining a function that receives dbt and a session, and returns a single DataFrame, which is saved as a table. It supports table and incremental materializations, but not view or ephemeral.
Python models are supported on Snowflake, BigQuery and Databricks in dbt v2, according to the same page.
How packages are declared
You list third party packages in the model's configuration, for example numpy pinned to a version and scikit-learn unpinned. The docs say this declaration is required on some platforms and lets dbt track the packages in project metadata. They also say the packages must be installed and available to the Python runtime on the platform.
Notice the example in the docs: one package is pinned, the other is not. That is fine for a tutorial, and a gap in production.
Why this matters for supply chain
| Question | SQL model | Python model |
|---|---|---|
| Where does code run? | In the warehouse | On the platform's Python runtime |
| Third party code? | Macros from dbt packages | Macros plus PyPI style packages |
| Where is it logged? | dbt logs | Platform logs (print output is not shown in dbt logs, per the docs) |
The last row is a quiet one. The docs say the platform runs the model without dbt's oversight, so print output does not appear in dbt logs. If a package behaves oddly, you look in the platform logs.
Practical steps
- Pin every package in the config. Use exact versions, as you would in a requirements file.
- Find out how the platform resolves them. Which index does it use, and can it be restricted to an approved source?
- Inventory them. Include Python model packages in your SBOM next to dbt packages and Airflow providers.
- Keep the role narrow. Code in a Python model runs with the permissions the platform gives that job.
- Ask whether SQL would do. The docs say that well written SQL is preferable when a transformation could be written equally well in either.
If you pin the packages in the model, also remember the version rules in pinning Python dependencies in data projects.
Quick check
Does dbt execute Python models on my machine?
No. The docs say all Python code is executed remotely on the data platform.
Do I still need to declare packages?
Yes. The docs say the configuration is required on some platforms, and the packages must exist in the platform's runtime.
Safeguard dependency scanning covers Python packages, so those named in model configs can be inventoried and checked. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
