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
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
| 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
| 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
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
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 para lo que
informa effectiveMode.
Añadir una conexión
- Abre la aplicación en cloud.vibedasher.com y ve a Conexiones.
- Elige el tipo de fuente y rellena los detalles de la conexión — o sube tu archivo.
- Ejecuta Probar conexión. Esto abre la conexión de verdad; no es una comprobación de formato de campos.
- Guarda. Vibedasher introspecciona el esquema para que los agentes y el motor de consultas sepan qué tablas y columnas existen.
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.
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é para el resto del modelo de permisos.
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
Apunta tu agente al conjunto de datos — Construir con tu agente (MCP) — o apunta tu agente a él. Luego configura las actualizaciones para que se mantenga fiel.