Built for the production stack.

Dex supports BigQuery, Snowflake, Databricks, Redshift, ClickHouse (Cloud and self-hosted), PostgreSQL, Trino, and DuckDB. Every connector has a cost guard in its own billing unit, and DuckDB is the zero-credential on-ramp: point Dex at a local file and nothing else is needed.

Yes, natively. Apache Ossie (incubating) is the vendor-neutral standard for exchanging semantic metadata, and Dex reads it as a first-class semantic layer. Install the extra with pip install 'exmergo-dex-core[ossie]', set semantic.vendor: ossie in .dex/config.yml, and list your .ossie.yaml, .ossie.yml, or .ossie.json documents under semantic.ossie.files.

Yes, natively. SLayer by Motley keeps a semantic layer as YAML model files, and Dex reads it as a first-class semantic layer. Install the extra with pip install 'exmergo-dex-core[slayer]', set semantic.vendor: slayer in .dex/config.yml, point semantic.slayer.base_dir at SLayer's storage root, and list your model files under semantic.slayer.models. Dex validates every file with SLayer's own model class from one pinned release, authors models as reviewable diffs, and detects drift against them. For a governed query, SLayer renders the SQL as a dry run and Dex runs it under its own cost guard and PII gate, so SLayer never opens a warehouse connection.

Yes, natively, each in its own format with no conversion. Cube cubes and views, Snowflake Semantic Views, and Databricks Metric Views are read from the YAML files in your repository: install exmergo-dex-core[cube], exmergo-dex-core[semantic-views], or exmergo-dex-core[metric-views], set semantic.vendor to cube, snowflake, or databricks in .dex/config.yml, and list the files under semantic.cube.files, semantic.snowflake.files, or semantic.databricks.files. Dex validates every file against its port of the vendor's rules, authors files as reviewable diffs, derives a cube, logical table, or Metric View from a declared dbt mart, and detects drift against the warehouse. It never deploys a Semantic View or Metric View for you. On Cube, a governed query is rendered by your Cube server and run by Dex under its own cost guard and PII gate.

No. Dex reads Apache Ossie documents, SLayer and Cube model files, Snowflake Semantic Views, and Databricks Metric Views natively, so a repository with no dbt project and no MetricFlow anywhere in the path still gets a governed semantic layer: set semantic.vendor to ossie, slayer, cube, snowflake, or databricks in .dex/config.yml and Dex explores, authors, and drift-checks against those files. A repository that keeps dbt for its models and declares its semantics in one of those formats beside them gets both.

No. The dbt Cloud Semantic Layer backend is opt-in and off by default. Queries sent there run on dbt Cloud, under your dbt Cloud account's own limits, so it is the one path where Dex's cost guard cannot apply, and every result on that path says so.