> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/build/v1/productize/connect-engine.md).

# Connect engine

Before `vulcan plan` can run anything, Vulcan needs to know which engine to connect to and how to authenticate. An engine is where your transforms run and where your product's outputs land. Vulcan connects to 7 engines: Snowflake, Databricks, Spark, Trino, Postgres, SQL Server, and Microsoft Fabric.

These pages cover connection and configuration only: the adapter type, permissions, connection options, authentication, and an example gateway. For deep configuration, materialization internals, tuning, and failure modes, see [References → Engine guide](https://v2.dataos.info/references/engine-guide). Each page links to its own manual there, so this section doesn't repeat that detail.

## How engine selection works

Engine configuration lives in the `gateways` block of `config.yaml`. The `connection.type` field selects the adapter:

```yaml
gateways:
  default:
    connection:
      type: <engine-type>   # depot | snowflake | databricks | spark | trino | postgres | mssql | fabric
      # engine-specific fields
```

On DataOS, use `type: depot`. A depot delegates credentials, so none of them appear in `config.yaml`. Here's how the `orders-analytics` product connects to its PostgreSQL database this way:

```yaml
gateways:
  default:
    connection:
      type: depot
      address: dataos://postgresDepot
```

Working locally, connect with raw types and environment variables instead:

```yaml
gateways:
  default:
    connection:
      type: postgres
      host: "{{ env_var('PG_HOST') }}"
      database: "{{ env_var('PG_DATABASE') }}"
      user: "{{ env_var('PG_USER') }}"
      password: "{{ env_var('PG_PASSWORD') }}"
```

Never hard-code credentials. Always use `{{ env_var('VAR_NAME') }}`.

## Choose your engine

| Engine                                                                      | `type`       | Best for                                               |
| --------------------------------------------------------------------------- | ------------ | ------------------------------------------------------ |
| [Snowflake](/build/v1/productize/connect-engine/snowflake.md)               | `snowflake`  | Governed, SQL-first enterprise analytics on Snowflake  |
| [Databricks](/build/v1/productize/connect-engine/databricks.md)             | `databricks` | Delta Lake, Unity Catalog, and Spark workloads         |
| [Spark](/build/v1/productize/connect-engine/spark.md)                       | `spark`      | Iceberg, object storage, large distributed processing  |
| [Trino](/build/v1/productize/connect-engine/trino.md)                       | `trino`      | Federated SQL across catalogs and data lakes           |
| [Postgres](/build/v1/productize/connect-engine/postgres.md)                 | `postgres`   | Smaller products, prototypes, local-first work         |
| [SQL Server](/build/v1/productize/connect-engine/sql-server.md)             | `mssql`      | Existing SQL Server estates, on-premises T-SQL control |
| [Microsoft Fabric](/build/v1/productize/connect-engine/microsoft-fabric.md) | `fabric`     | Fabric Warehouse with OneLake and Entra ID auth        |

Your engine choice sets 4 things: the SQL dialect, how Vulcan materializes tables, the permissions you need, and who owns cost and tuning. Spark and Trino need more active operational ownership than Snowflake or Postgres do. Where you can, pick the engine where your data already lives. That way, you avoid moving it unnecessarily.

## Verify the connection

After you fill in the connection details, confirm Vulcan can reach the engine:

```bash
vulcan info
vulcan plan dev
```

`vulcan info` confirms 3 things: `config.yaml` is valid, the connection is reachable, and Vulcan recognizes the model directory. Fix any error it reports before you continue to [Assets](/build/v1/productize/assets.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://v2.dataos.info/build/v1/productize/connect-engine.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.