When Does Solid Execute SQL?
A single reference for every mode in which SQL runs somewhere in the Solid pipeline — who runs it, what comes back, and what crosses the network boundary.
Solid touches SQL execution in several different ways depending on what you're doing — ingesting a new source, building a model, running benchmarks, asking a question in Analyze, or calling the MCP server. Each mode has a different execution identity, a different executor, and a different answer to "does data leave your warehouse." This page is the single source of truth for all of them.
The Matrix
| Mode | Identity Used | SQL Executor | Data Returned | Crosses Network Boundary? | Data Persisted? | Timeout / LIMIT | Permission Model |
|---|---|---|---|---|---|---|---|
| Ingestion (schema, query logs, samples) | The connector service account/role created during setup (e.g., SOLID_DATA_ROLE on Snowflake, a service principal on BigQuery/Databricks/Synapse) | Solid's ingestion pipeline, querying system/information-schema views and sampling column values directly against your warehouse | Schema metadata, query log entries, table stats, and column-value samples (not row-level data) | Yes — metadata and samples move from your warehouse to Solid's ingestion service | Metadata and samples are persisted in Solid's store; no row-level data is ever persisted | Sampling queries use a row LIMIT (typically up to 100,000 rows per table); no correction loop involved | Read-only, schema-scoped grants defined per connector (see each Connecting Your Data guide) |
| Model Creation (Auto-Create) | N/A — no new query execution against your warehouse | None. Auto-Create reasons over metadata and certified SQL examples already collected during ingestion; it does not execute new queries | A draft semantic model | No — this step works entirely from already-ingested data | The draft model definition | N/A | N/A |
| Benchmarking (Auto-Evaluate) | Solid's connector service account — the same read-only, schema-scoped credentials used for ingestion | Solid's own data_server — executes both the generated SQL and the certified ground-truth SQL and compares the results | Result rows from both SQL executions, used transiently inside data_server to compute the accuracy score — never shown to users or the LLM, and not persisted | Yes — SQL text goes to the warehouse; result rows come back to data_server for scoring. This is the one mode where result rows cross back through Solid's system, and it is handled as internal validation data, not user-facing output | Benchmark accuracy scores and pass/fail per question are persisted; raw result rows are not | A fetch-limit is applied to execution; no LIMIT is injected into the SQL string itself | Read-only, scoped to the tables/schemas exposed to the semantic model |
| Interactive Analyze | The end-user's own mapped warehouse credentials (or a scoped service identity configured at the integration level, e.g., OAuth sub→warehouse login mapping) | Customer's data warehouse — Solid generates SQL; execution happens in the warehouse, not inside Solid | A formatted answer derived from the results; raw result rows are not displayed in Solid's UI or exposed to the LLM | Generated SQL goes to the warehouse; Solid's backend receives the query outcome to format an answer — raw rows are not surfaced in the UI | Query history and usage metrics; raw results are not persisted | Warehouse-enforced | The end-user's own warehouse credentials — Solid does not elevate or share permissions across users |
| Runtime MCP (SQL Generation tool) | The end-user's own warehouse credentials, via the calling agent | The agent that called the MCP server — never Solid | The generated SQL, plus a reasoning explanation | No — Solid returns SQL only; execution and data retrieval happen entirely between the agent and your warehouse | Nothing beyond usage/audit logs of the MCP call itself | Whatever timeout your warehouse and agent enforce — not controlled by Solid at this stage | Whatever access the end-user's own credentials already have; Solid does not elevate or replicate permissions |
| External Agents (Bedrock, Copilot, custom MCP clients, etc.) | Same as Runtime MCP — the end-user's or service's own warehouse credentials, via the calling agent | The calling agent | Same as Runtime MCP | No — same boundary as Runtime MCP | Same as Runtime MCP | Same as Runtime MCP | Same as Runtime MCP |
Two Distinct Boundaries
It's easiest to keep straight if you think of two separate boundaries:
- The DB Agent boundary (Ingestion, Benchmarking, and the correction loop inside SQL Generation): Solid's own DB Agent executes queries for validation purposes — checking that generated SQL runs, checking that it matches ground truth, sampling for profiling. This executor is Solid's, using Solid-provisioned read-only credentials. See Controls and Safeguards and SQL Generation and Grounding for how the correction loop uses this boundary.
- The agent execution boundary (Runtime MCP and External Agents): the calling agent — not Solid — executes the final SQL that produces the answer a human or downstream system actually uses, with the end-user's own credentials. See MCP Runtime Flow for the full 8-step sequence.
The confusion in past conversations has usually come from describing one boundary while a listener assumed the other. Both are true simultaneously — they just apply to different parts of the pipeline.
Benchmarking and the "zero-raw-data" boundary
Benchmarking is the one mode where result rows cross back into Solid's system — and understanding why clarifies rather than undermines the broader architecture.
Benchmarking requires comparing two SQL results to produce an accuracy score: the generated SQL and the certified ground-truth SQL must be run and their outputs compared. That comparison happens transiently in Solid's data_server. The rows are never persisted, never shown to users, and never sent to the LLM — they exist only long enough to compute a pass/fail signal for each benchmark question.
This is separate from what happens at runtime (MCP or Analyze), where Solid generates SQL and your agent or warehouse executes it with your own credentials — and result rows never enter Solid's system at all.
If your security posture requires keeping all result data within your own network perimeter even for benchmarking, see Data System Collector — the collector model runs inside your network and handles validation locally.
Updated 10 days ago