BENCHMARKS
Every number we publish comes from real runs of the DVT verification project — a 67-model dbt project spanning 11 live engines — not from a synthetic benchmark rig. This page is the story behind each headline number, and how to check it yourself.
Hardware: a single Apple-silicon MacBook. Engines: Docker-hosted PostgreSQL, Oracle, ClickHouse, SQL Server, Trino and SQLite, with MinIO (S3) and Azurite (Azure) standing in for the bucket lanes, plus live Databricks and DuckDB. Your numbers will vary with network and warehouse sizing — these are honest laptop figures, not lab-tuned peaks.
2.1M ROWS / 138MB OF SEEDS, BULK-LOADED
The project's seed set — eight files including a 2.1M-row, 138MB transactions table — loads to PostgreSQL in about ten seconds with dvt seed. dbt's native seed loader handles the same files in minutes, row by row; Sling bulk-loads them. The same seeds load to Oracle, Databricks, or an S3 bucket by changing --target.
How seeds work →17 CROSS-ENGINE FEDERATED MODELS, END TO END
Seventeen f_table models reading PostgreSQL, Oracle, ClickHouse, SQL Server, SQLite, and bucket sources — decomposed, extracted with pushdown, joined in DuckDB, loaded back out — complete in roughly twenty seconds total. Extraction parallelism and per-model DuckDB compute are why the wall clock stays flat as engines are added.
The pipeline that runs this →62 FEDERATED MODELS ACROSS 11 ENGINES, ONE RUN
The full federation suite — 62 f_table/f_incremental/python models spanning every verified engine including cloud warehouses — completes in 5 minutes 18 seconds in a single dvt run. Models execute in dependency waves; within a wave everything runs concurrently. Load throughput peaked at ~25,000 rows/second into Databricks for a 1M-row model.
The materializations being run →MODELS GREEN AFTER SWITCHING THE LAKEHOUSE
We took the verification project running on a PostgreSQL default target and switched it to Databricks: 2 changed lines in profiles.yml, 1 explicit date cast (Databricks ANSI mode), 4 lines of seed column_types. Then dvt build — all 67 models passed on the first full run, and the cross-engine catalog re-stamped itself automatically. That migration is documented step by step.
The full migration walkthrough →REPRODUCE IT
Nothing here requires special builds. pip install dvt-core, point profiles.yml at your engines, and time your own runs — dvt runprints per-model timings in dbt's output format, so the numbers are in your terminal, not in our marketing.