# Conectar una fuente de datos

Las conexiones son la primera pieza de estado de plataforma de la que dependen tus paneles, y la ilustración más clara de la separación: el panel es código que tu agente escribe y puede reescribir en un minuto; la conexión es una credencial, una ruta de red y un esquema introspeccionado que alguien configuró una vez y que tiene que seguir funcionando durante un año.

Configuras una conexión una vez. A partir de ahí cada superficie consulta a través de ella — tu agente vía MCP, tu código vía los SDKs, el asistente integrado, y cada panel publicado.

## Qué puedes conectar[​](#qué-puedes-conectar "Enlace directo al Qué puedes conectar")

Vibedasher tiene **20 tipos de conexión**. Diecinueve tienen una implementación de servicio funcional, y **diecinueve se ofrecen hoy en el selector de conectores de la aplicación**. La diferencia importa si estás evaluando el producto contra una fuente concreta, así que aquí está la lista completa en lugar de una cifra de marketing.

### Bases de datos y almacenes de datos[​](#bases-de-datos-y-almacenes-de-datos "Enlace directo al Bases de datos y almacenes de datos")

| Fuente             | En el selector | Cargas incrementales |
| ------------------ | -------------- | -------------------- |
| PostgreSQL         | sí             | sí                   |
| MySQL              | sí             | sí                   |
| SQL Server (MSSQL) | sí             | sí                   |
| Oracle             | sí             | sí                   |
| Redshift           | sí             | sí                   |
| Snowflake          | sí             | sí                   |
| BigQuery           | sí             | sí                   |
| Athena             | sí             | sí                   |
| MongoDB            | sí             | no                   |
| Cassandra          | sí             | no                   |
| DynamoDB           | sí             | no                   |

### SaaS y almacenes de archivos[​](#saas-y-almacenes-de-archivos "Enlace directo al SaaS y almacenes de archivos")

| Fuente               | En el selector | Cargas incrementales |
| -------------------- | -------------- | -------------------- |
| Salesforce           | sí             | no                   |
| HubSpot              | sí             | no                   |
| Marketo              | sí             | no                   |
| Mailchimp            | sí             | no                   |
| Google Sheets        | sí             | no                   |
| Google Analytics     | sí             | no                   |
| Azure Data Lake      | sí             | no                   |
| Google Cloud Storage | sí             | no                   |
| SAP                  | **no**         | no                   |

**SAP** necesita `pyrfc`, el SDK propietario NetWeaver RFC de SAP, que no está en PyPI — así que el conector no está desplegado. En algunas cuentas antiguas aún existe una fila de conexión `sap`, y la introspección de esquema contra ella responde `404`.

### Subida de archivos planos[​](#subida-de-archivos-planos "Enlace directo al Subida de archivos planos")

La subida acepta **CSV** (`.csv`) y **Excel** (`.xlsx`, `.xls`).

**Parquet no es un formato de subida.** Vibedasher almacena tus datos como Parquet internamente, pero no es algo que puedas subir. Si tus datos ya están en Parquet, aterrízalos en un almacén que Vibedasher pueda consultar, o conviértelos a CSV.

## Las cargas incrementales necesitan un dialecto SQL[​](#las-cargas-incrementales-necesitan-un-dialecto-sql "Enlace directo al Las cargas incrementales necesitan un dialecto SQL")

La columna **Cargas incrementales** de arriba no es una decisión de producto, es mecánica. Una carga incremental funciona reescribiendo tu consulta de extracción para añadir un predicado de marca de agua, y esa reescritura necesita un dialecto SQL que la plataforma pueda analizar. Ocho conectores tienen uno — PostgreSQL, MySQL, SQL Server, Oracle, Redshift, Snowflake, BigQuery y Athena.

Cualquier otro conector, incluyendo MongoDB, DynamoDB y todas las fuentes SaaS, se actualiza mediante **recarga completa**. Eso es correcto, solo que más costoso: presupuéstalo para una fuente grande, y mira [Mantén tus datos frescos](/es/guides/keep-your-data-fresh.md) para lo que informa `effectiveMode`.

## Añadir una conexión[​](#añadir-una-conexión "Enlace directo al Añadir una conexión")

1. Abre la aplicación en [cloud.vibedasher.com](https://cloud.vibedasher.com) y ve a **Conexiones**.
2. Elige el tipo de fuente y rellena los detalles de la conexión — o sube tu archivo.
3. Ejecuta **Probar conexión**. Esto abre la conexión de verdad; no es una comprobación de formato de campos.
4. Guarda. Vibedasher introspecciona el esquema para que los agentes y el motor de consultas sepan qué tablas y columnas existen.

Editar una conexión más tarde

Las credenciales guardadas están enmascaradas en la interfaz. Cuando editas una conexión, **deja un campo enmascarado sin tocar para conservar el valor existente** — la plataforma detecta la máscara al recibirla de vuelta y preserva lo que ya tiene, en lugar de sobrescribir tu contraseña con una fila de puntos.

También puedes hacer todo esto desde código:

```
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);
```

El conjunto completo — `create`, `list`, `get`, `update`, `updateMetadata`, `delete`, `test`, `getSchema`, `getTables`, `getTableSchema`, `validateQuery` — está en la **[API Reference](/es/reference/vibedasher-sdk-api.md)**.

## Quién puede gestionar una conexión[​](#quién-puede-gestionar-una-conexión "Enlace directo al Quién puede gestionar una conexión")

Las conexiones **no** están cubiertas por el modelo de derechos de acceso de carpetas — no hay una concesión por conexión. Las reglas son más simples y valen la pena decirlas claramente:

* Cualquier **creador** o **admin** puede crear una conexión. Un **visor** no puede.
* Solo el **propietario** de la conexión o un **admin** puede actualizarla o eliminarla.
* Una conexión no es visible para el resto de la cuenta como lo es una carpeta compartida.

Si necesitas una conexión que varias personas puedan gestionar, un admin debería ser su propietario. Mira [Quién puede ver qué](/es/guides/who-can-see-what.md) para el resto del modelo de permisos.

## Conjuntos de datos[​](#conjuntos-de-datos "Enlace directo al Conjuntos de datos")

Una conexión es una ruta hacia tus datos; un **conjunto de datos** es lo que los paneles realmente leen. Creas conjuntos de datos a partir de una conexión — una tabla, o el resultado de una consulta.

Cada conjunto de datos obtiene un alias `cleanSQLName`, que es el nombre de la tabla contra el que tu agente escribe SQL. Un conjunto de datos pasa por `PENDING → DOWNLOADING → PROCESSING → READY`, y un panel construido sobre uno que no haya llegado a **READY** no tendrá nada que dibujar. Espera a `READY`.

Los conjuntos de datos son estado vivo, no importaciones puntuales: dispara una **actualización** para traerlo al presente, y ejecuta **proyectos dbt** aguas abajo de él. Los paneles recogen los datos actualizados a través del mismo motor de consultas, sin reconstruir — que es la razón entera por la que la mitad de los datos vive aquí y no en la sesión de tu agente.

## Siguiente paso[​](#siguiente-paso "Enlace directo al Siguiente paso")

Apunta tu agente al conjunto de datos — **[Construir con tu agente (MCP)](/es/guides/build-with-your-agent.md)** — o **[apunta tu agente a él](/es/guides/build-with-your-agent.md)**. Luego configura las **[actualizaciones](/es/guides/keep-your-data-fresh.md)** para que se mantenga fiel.