Skip to main content
The dbt importer parses your project structure—models, sources, tests, and dependencies—and materializes a Planasonix graph where each model becomes a logical node (often Custom SQL or warehouse-native SQL nodes) with edges derived from ref relationships.
Read Import and convert for wizard steps, bulk upload tips, and promotion discipline.

​
dbt project structure parsing

1

Package the project

Upload a zip of the dbt project root containing dbt_project.yml, models/, macros/, tests/, and packages.yml if you use package dependencies.
2

Select target and dialect

Choose the warehouse dialect Planasonix should assume when it normalizes SQL (Snowflake, BigQuery, Databricks SQL, and so on). Mismatched dialect produces invalid SQL in generated nodes.
3

Resolve packages

If you rely on dbt packages, include dbt deps output in the archive or vendor the dbt_packages/ tree so macros resolve during parsing.

​
Model to node mapping

dbt artifactTypical Planasonix representation
models/*.sqlSQL transform node per model
schema.yml testsData quality checks or annotations (coverage varies)
SeedsStatic file ingest nodes or manual upload steps
SnapshotsSlowly changing dimension patterns—you verify keys and strategy
Keep staging models (stg_) as separate nodes even if you later collapse them. Preserving layers speeds diffing against legacy dbt runs during validation.

​
Handling refs

The importer expands {{ ref('model_name') }} into edges between nodes so execution order mirrors the dbt DAG.
Ephemeral models inline into parents in dbt; Planasonix may merge them into dependent SQL or keep them as separate nodes depending on importer version. Read the conversion report for merges and inlining notes.

​
Handling sources

{{ source('src', 'table') }} declarations bind to logical sources. After import, map each source to a Planasonix connection and physical relation (database/schema/table or equivalent).
dbt freshness blocks become advisory metadata or scheduled checks in Planasonix where supported. You may recreate freshness as orchestration gates or observability monitors.
Custom aliases, schemas, and database overrides in dbt_project.yml must appear in the Planasonix environment configuration so runtime objects resolve correctly.

​
Macros

Jinja macros do not execute inside Planasonix the way they do in dbt run.
Simple macros that expand to static SQL may inline successfully during import. Review generated SQL for correctness.
Incremental models depend on dbt’s merge strategies and is_incremental() guards. Rebuild incremental logic explicitly in Planasonix merge/upsert patterns; do not assume identical performance or locking behavior across warehouses.

​
After import

Environments

Bind dev vs prod connections and variables.

Git integration

Track post-import changes in version control.