# Connect a data source

Connections are the first piece of platform state your dashboards depend on, and the clearest illustration of the split: the dashboard is code your agent writes and can rewrite in a minute; the connection is a credential, a network path and an introspected schema that somebody configured once and that has to keep working for a year.

You set a connection up once. From then on every surface queries through it — your agent over MCP, your code over the SDKs, the in-app assistant, and every published dashboard.

## What you can connect[​](#what-you-can-connect "Direct link to What you can connect")

Vibedasher has **20 connection types**. Nineteen have a working service implementation, and **nineteen are offered in the app's connector picker today**. The difference matters if you are evaluating the product against a specific source, so here is the whole list rather than a marketing count.

### Databases and warehouses[​](#databases-and-warehouses "Direct link to Databases and warehouses")

| Source             | In the picker | Incremental loads |
| ------------------ | ------------- | ----------------- |
| PostgreSQL         | yes           | yes               |
| MySQL              | yes           | yes               |
| SQL Server (MSSQL) | yes           | yes               |
| Oracle             | yes           | yes               |
| Redshift           | yes           | yes               |
| Snowflake          | yes           | yes               |
| BigQuery           | yes           | yes               |
| Athena             | yes           | yes               |
| MongoDB            | yes           | no                |
| Cassandra          | yes           | no                |
| DynamoDB           | yes           | no                |

### SaaS and file stores[​](#saas-and-file-stores "Direct link to SaaS and file stores")

| Source               | In the picker | Incremental loads |
| -------------------- | ------------- | ----------------- |
| Salesforce           | yes           | no                |
| HubSpot              | yes           | no                |
| Marketo              | yes           | no                |
| Mailchimp            | yes           | no                |
| Google Sheets        | yes           | no                |
| Google Analytics     | yes           | no                |
| Azure Data Lake      | yes           | no                |
| Google Cloud Storage | yes           | no                |
| SAP                  | **no**        | no                |

**SAP** needs `pyrfc`, SAP's proprietary NetWeaver RFC SDK, which is not on PyPI — so the connector is not deployed. A legacy `sap` connection row still exists on some accounts, and schema introspection against one answers `404`.

### Flat-file upload[​](#flat-file-upload "Direct link to Flat-file upload")

Upload accepts **CSV** (`.csv`) and **Excel** (`.xlsx`, `.xls`).

**Parquet is not an upload format.** Vibedasher stores your data as Parquet internally, but it is not something you can upload. If your data is already Parquet, land it in a store Vibedasher can query, or convert it to CSV.

## Incremental loads need a SQL dialect[​](#incremental-loads-need-a-sql-dialect "Direct link to Incremental loads need a SQL dialect")

The **Incremental loads** column above is not a product decision, it is a mechanical one. An incremental load works by rewriting your extraction query to add a watermark predicate, and that rewrite needs a SQL dialect the platform can parse. Eight connectors have one — PostgreSQL, MySQL, SQL Server, Oracle, Redshift, Snowflake, BigQuery and Athena.

Every other connector, including MongoDB, DynamoDB and all the SaaS sources, refreshes by **full reload**. That is correct, just more expensive: budget for it on a large source, and see [Keep your data fresh](/guides/keep-your-data-fresh.md) for what `effectiveMode` reports back.

## Add a connection[​](#add-a-connection "Direct link to Add a connection")

1. Open the app at [cloud.vibedasher.com](https://cloud.vibedasher.com) and go to **Connections**.
2. Choose the source type and fill in the connection details — or upload your file.
3. Run **Test connection**. This actually opens the connection; it is not a field-format check.
4. Save. Vibedasher introspects the schema so agents and the query engine know which tables and columns exist.

Editing a connection later

Stored credentials are masked in the UI. When you edit a connection, **leave a masked field untouched to keep the existing value** — the platform detects the mask on the way back in and preserves what it already has, rather than overwriting your password with a row of dots.

You can also do all of this from code:

```
schema = client.connections.get_schema(connection_type, connection_id)

tables = client.connections.get_tables(connection_type, connection_id)
```

```
const schema = await client.connections.getSchema(connectionType, connectionId);

const tables = await client.connections.getTables(connectionType, connectionId);
```

The full set — `create`, `list`, `get`, `update`, `updateMetadata`, `delete`, `test`, `getSchema`, `getTables`, `getTableSchema`, `validateQuery` — is in the **[API Reference](/reference/vibedasher-sdk-api.md)**.

## Who may manage a connection[​](#who-may-manage-a-connection "Direct link to Who may manage a connection")

Connections are **not** covered by the folder access-rights model — there is no per-connection grant. The rules are simpler and worth stating plainly:

* Any **creator** or **admin** may create a connection. A **viewer** may not.
* Only the connection's **owner** or an **admin** may update or delete it.
* A connection is not visible to the rest of the account the way a shared folder is.

If you need a connection several people can manage, an admin should own it. See [Who can see what](/guides/who-can-see-what.md) for the rest of the permission model.

## Datasets[​](#datasets "Direct link to Datasets")

A connection is a route to your data; a **dataset** is the thing dashboards actually read. You create datasets from a connection — a table, or the result of a query.

Each dataset gets a `cleanSQLName` alias, which is the table name your agent writes SQL against. A dataset moves through `PENDING → DOWNLOADING → PROCESSING → READY`, and a dashboard built on one that has not reached **READY** will have nothing to draw. Wait for `READY`.

Datasets are living state, not one-off imports: trigger a **refresh** to bring one forward, and run **dbt projects** downstream of it. Dashboards pick up refreshed data through the same query engine, with no rebuild — which is the whole reason the data half lives here and not in your agent's session.

## Next step[​](#next-step "Direct link to Next step")

Point your agent at the dataset — **[Build with your agent (MCP)](/guides/build-with-your-agent.md)** — or **[point your agent at it](/guides/build-with-your-agent.md)**. Then set up **[refreshes](/guides/keep-your-data-fresh.md)** so it stays true.