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 methodology behind each headline number.
Hardware: a single Apple-silicon MacBook. Engines: Docker-hosted PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, ClickHouse, Trino, SQLite, MinIO (S3), Azurite (Azure) 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, MySQL, MariaDB, SQL Server, Oracle, SQLite, ClickHouse, 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.