SUPPORTED DATABASES
DVT speaks to eighteen database engines, and one rule covers them all: every engine works as a federation source, a federation target, and a seed target, with full dbt compatibility on your default target. During federation, Sling moves the data and DuckDB does the joining — the federation engine page explains that machinery.
This page is the overview. Every engine in the table links to its own page — connection fields, profiles.yml and sources.yml examples, least-privilege grants, and known limitations — so once you know your engine is here, click through and set it up.
FULL ADAPTER SUPPORT (PUSHDOWN + EXTRACTION + TARGET)
✓ verified means tested live against a real instance in DVT's verification suite. Eleven of these engines have gone further: every ordered pair among them — all 110 engine-to-engine transitions, both directions — has been walked live under a 27-command battery (flip, parse, seed, double build, snapshots, idempotence, row counts and named values against canonical truth, docs, sources, metadata, base views, native execution, zero-residual retract), with a green gate on every hop. The 0.2.52 release notes tell that campaign's story.
| DATABASE | TYPE | STATUS |
|---|---|---|
| PostgreSQL | postgres | ✓ verified |
| Snowflake | snowflake | ✓ verified |
| BigQuery | bigquery | supported |
| Redshift | redshift | supported |
| Databricks | databricks | ✓ verified |
| SQL Server | sqlserver | ✓ verified |
| Oracle | oracle | ✓ verified |
| MySQL | mysql | supported |
| MySQL 5.7 | mysql5 | supported |
| MariaDB | mariadb | supported |
| DuckDB | duckdb | ✓ verified |
| Microsoft Fabric | fabric | supported |
| ClickHouse | clickhouse | ✓ verified |
| StarRocks | starrocks | supported |
| Trino | trino | ✓ verified |
| Exasol | exasol | supported |
| SQLite | sqlite | ✓ verified |
| Amazon Athena | athena | supported |
PYTHON MODEL SOURCES
No native adapter, no problem — Python models run locally and land their results in your DAG like any other model. That is how DVT reaches these systems: Python models guide.
SLING-ONLY CONNECTORS (SOURCE + FILE TARGET)
No SQL engine behind them — these work as extraction sources for federated models, and as bucket-style targets (results land as files).
BUCKET STORAGES (SOURCE + TARGET)
Cloud buckets and the local filesystem work as extraction sources or materialization targets. Data moves via Sling, compute runs in DuckDB.
| STORAGE | TYPE | KEY FIELDS |
|---|---|---|
| Amazon S3 | s3 | bucket, region, access_key_id, secret_access_key |
| Google Cloud Storage | gcs | bucket, project_id, keyfile |
| Azure Blob Storage | azure | account, container, access_key |
| SFTP | sftp | host, user, password / private_key, path |
| Local Filesystem | filesystem | path |
Full bucket storages guide — profiles.yml setup, source/target examples, incremental extraction, supported formats.
FILE FORMATS
| FORMAT | READ | WRITE |
|---|---|---|
| CSV | ✓ | ✓ |
| Parquet | ✓ | ✓ |
| JSON | ✓ | ✓ |
| JSONL | ✓ | ✓ |
These four formats are the whole file surface — the same list applies to bucket reads, bucket writes, and seeds, so a bucket source and a seed of the same file give the same columns. Anything else is refused by name. Table formats such as Iceberg or Delta are engine configurations, not file formats.