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

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

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

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

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

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 for what effectiveMode reports back.

Add a connection

1. Open the app at 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.

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 for the rest of the permission model.

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

Point your agent at the dataset — Build with your agent (MCP) — or point your agent at it. Then set up refreshes so it stays true.