Data handling
This page describes the data Zingle AI reads, processes, and stores.
What Zingle reads
| Data | Source | Purpose |
|---|---|---|
| Repository code | Your Git repository | Cloned into a workspace so agents can read and modify dbt models. |
| dbt metadata | Parsed dbt manifest | Models, columns, tests, and the semantic layer. |
| Warehouse metadata | Warehouse information schema | Databases, schemas, tables, and columns. |
| Warehouse statistics | Warehouse | Model/source stats used for cost and optimization. |
| Query results | Warehouse | Rows returned by SQL run to preview data, validate models, and answer questions. |
What Zingle stores
Zingle stores the following in its metadata store:
- dbt catalog - models, columns, lineage, and semantic-layer definitions synced from your repository.
- Sessions & messages - the history of your Studio conversations, including the SQL that was generated.
- Cached query results - rows returned by queries are cached with the session, capped per query.
- Configuration - connections, environments, agents, and settings.
Query results are stored
Query result rows (capped per query) are cached in the metadata store alongside the session that produced them. They are removed when the parent session is deleted.
Row limits
SQL run by Zingle is capped per query (currently 1,000 rows maximum, with a default of 100). This limits how much warehouse data is returned into a session at once.
What Zingle does not store
- Zingle does not perform bulk extraction of your warehouse tables. It reads metadata and the capped query results described above - not full table copies.
Where data lives
- In the Customer VPC model, all of the above is stored inside your environment.
- In the Zingle-managed model, it is stored in the managed metadata store, isolated per organization.