Multi-Warehouse Support
Connect to any major cloud data warehouse. One unified interface, any adapter. Switch between Snowflake, BigQuery, Redshift, Athena, Databricks, MotherDuck, Microsoft Fabric, Azure Synapse, and more without changing your workflow.
Supported Warehouses
dbdeux works with the most popular cloud data platforms:
| Warehouse | Features | Status |
|---|---|---|
| Snowflake | Full support including SnowPark, dynamic tables, RBAC-aware browsing, and password, key-pair, or programmatic access token authentication | Generally Available |
| Google BigQuery | Full support including partitioned tables, materialized views, and dataset browsing | Generally Available |
| Amazon Redshift | Full support including Redshift Serverless and Spectrum | Generally Available |
| Amazon Athena | Full support for Athena workgroups and S3 data sources | Generally Available |
| Databricks | Full support for Databricks SQL Warehouses and Unity Catalog | Generally Available |
| PostgreSQL | Full support for PostgreSQL and compatible databases | Generally Available |
| MotherDuck | Cloud-hosted DuckDB with full dbt support via dbt-duckdb adapter | Generally Available |
| Microsoft Fabric | Fabric Warehouse (T-SQL) with Entra ID service principal authentication | Generally Available |
| Azure Synapse | Synapse SQL pool (T-SQL) with SQL login or Entra ID service principal | Generally Available |
| Microsoft Fabric Lakehouse | Fabric Lakehouse via Spark/OneLake with Entra ID service principal (dbt 1.10+) | Generally Available |
| StarRocks | High-performance analytics engine support | Generally Available |
State-Aware Run Coverage
State-aware runs skip models that provably have not changed. What each warehouse can prove differs, because the check relies on warehouse metadata:
| Warehouse | Native state-aware runs |
|---|---|
| Snowflake | Any model can be proven unchanged, and a missing table is restored by zero-copy clone |
| Google BigQuery | Any model can be proven unchanged, and a missing table is restored by zero-copy clone |
| Databricks | Any model can be proven unchanged, and a missing table is restored by deep clone |
| Amazon Redshift | Models built from seeds and other models are proven and skipped. Models fed by a source rebuild |
| PostgreSQL | Models built from seeds and other models are proven and skipped. Models fed by a source rebuild |
| MotherDuck | Models built from seeds and other models are proven and skipped. Models fed by a source rebuild |
| Microsoft Fabric | Models built from seeds and other models are proven and skipped. Models fed by a source rebuild |
| Azure Synapse | Models built from seeds and other models are proven and skipped. Models fed by a source rebuild |
| Amazon Athena | Models built from seeds and other models are proven and skipped. Models fed by a source rebuild |
| Everything else | Runs normally, with no reuse and nothing to configure |
The split is about what your warehouse will tell us. The first group reports when a table's data last changed, so even a model reading a raw source can be proven unchanged. The second group can confirm a table exists but offers no trustworthy freshness signal, so source-fed models rebuild rather than being skipped on an assumption.
A warehouse without reuse support loses nothing. The job runs exactly as it would have, and reuse simply does not apply. Your environment's State tab states in one line what reuse can do on the warehouse that environment connects to, so what to expect is visible before the first run rather than inferred from a reuse rate.
One IDE, Any Warehouse
Your development experience stays the same regardless of which warehouse you connect:
- Same IDE with syntax highlighting tuned to each warehouse's SQL dialect
- Same DAG Explorer with lineage computed identically across adapters
- Same Schema Diff comparing schemas no matter where they live
- Same testing and run workflows across all warehouses
- Same autocomplete with schema-aware suggestions from your connected warehouse
Secure Connection Management
Credential Storage
All warehouse credentials are:
- Encrypted at rest using industry-standard encryption
- Never stored in plain text anywhere in the system
- Scoped per project so different projects can use different credentials
- Access-controlled by role so only authorized users can view or modify connections
Connection Testing
Before saving, every connection is validated:
- Attempt to establish a connection to the warehouse
- Run a lightweight test query to verify permissions
- Confirm the user/role has appropriate access to target schemas
- Report clear success or detailed error messages
IP Allowlisting
For warehouses behind network policies, dbdeux routes all queries through static IP addresses. See the IP Allowlist guide for setup instructions.
Adding a Connection
- Open Databases in the left navigation
- Click New Connection
- Select your warehouse type
- Enter credentials (varies by warehouse type)
- Click Test Connection to verify
- Point one or more environments at the connection
Multiple Connections
Organizations often have multiple warehouse accounts (dev, staging, production) or even different warehouse vendors for different use cases. dbdeux supports:
- Multiple connections per organization
- Different warehouses for different projects
- Environment-based routing (dev runs against Snowflake sandbox, prod against production)
→ Learn more in Environments
Multi-Version dbt Engine
dbdeux supports multiple dbt engine versions side by side. Choose which version to use per project, per scheduled job, or per ad-hoc run:
| Version | Status | Notes |
|---|---|---|
| Core 1.8 | Default | Stable, widely adopted |
| Core 1.10 | Available | Latest features and adapter improvements |
| Fusion | Preview | Next-generation engine with enhanced performance |
The dbt version is selectable from the run toolbar and configurable per scheduled job. Slimmer CI runs respect the project's pinned version for consistent builds.