Multi-Turn Conversational Text-to-SQL Data

Why single-turn pairs fail conversational analytics assistants

Single-turn pairs fail because the hardest part of a chat session is context carryover, and a standalone pair has no context to carry. Public text-to-SQL resources are dominated by single-turn data: BIRD, for example, has 12,751 question-SQL pairs aimed at dirty values, external knowledge and efficiency, but each question stands alone [1]. Spider 2.0 moves toward realistic enterprise workflows with 632 problems on databases from real applications, yet it evaluates task completion, not a back-and-forth with a business user [3]. Both are useful for the base skill covered in our guide to text-to-SQL training data from real enterprise schemas; neither teaches follow-up behavior.

Academic multi-turn sets such as SParC and CoSQL exist, but they were built over public cross-domain databases rather than enterprise warehouses with metric definitions, fiscal calendars and dirty values. The failure mode buyers are paying to close is lost context: a model that gets turn one right and drops a filter at turn three produces a wrong chart with a confident answer.

Enterprise-style multi-turn data is scarcer still. One public enterprise-style set, SCM-SQL, includes 50 multi-turn refinement items among 500 execution-verified items [2]. That is a useful signal of demand, not a training corpus.

The turn types a session dataset must cover

A usable dataset labels each turn by how it depends on prior context, because each dependency type fails differently. The taxonomy below is a working buyer's model, not a published standard; adjust names to your evaluation harness.

Ask suppliers for the distribution of turn types per session, not just the count of sessions. A set that is 90% refinements will overstate readiness for pivots and coreference.

What each turn record should contain

Each turn needs its own gold SQL, its execution result and an explicit pointer to the context it depends on. Without per-turn execution results you cannot score coreference to results, because "the top one" is defined by the rows a user saw, not by the query text.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "session_id": "s-000412",
  "dialect": "snowflake",
  "schema_snapshot_id": "crm_wh_2026_06_30",
  "metric_glossary_ref": "glossary_v14#net_revenue",
  "turns": [
    {
      "turn": 1,
      "turn_type": "initial",
      "utterance": "Net revenue by region for Q2",
      "gold_sql": "SELECT region, SUM(net_amount) FROM fct_invoices WHERE fiscal_qtr = '2026-Q2' GROUP BY region",
      "result_hash": "sha256:9f2c...",
      "result_preview_rows": 6,
      "depends_on": []
    },
    {
      "turn": 2,
      "turn_type": "refinement",
      "utterance": "just enterprise",
      "gold_sql": "SELECT region, SUM(net_amount) FROM fct_invoices WHERE fiscal_qtr = '2026-Q2' AND segment = 'ENT' GROUP BY region",
      "result_hash": "sha256:41ab...",
      "depends_on": [1]
    },
    {
      "turn": 3,
      "turn_type": "clarification_request",
      "utterance": "which accounts churned?",
      "gold_system_action": "ask_clarification",
      "gold_clarification": "Churned in Q2, or churned at any time among Q2 enterprise accounts?",
      "depends_on": [2]
    }
  ],
  "session_label": {"goal_reached": true, "turns_to_goal": 5, "turns_shown": 3},
  "provenance": "annotated_bi_session",
  "pii_treatment": "account names replaced with stable pseudonyms"
}

Fields buyers most often forget: the schema snapshot ID (gold SQL is only valid against the schema version it was written for), a dialect tag, a metric glossary reference so "revenue" has one definition, and a result hash so you can re-execute and detect drift. Grounding documents such as metric definitions are a separate asset; see data dictionaries and schema docs as grounding data.

Where real multi-turn SQL sessions come from

Real sessions come from systems where analysts already iterate on questions, and each source carries different noise. Synthetic generation can fill gaps, but it inherits whatever turn patterns its prompts imagine.

• BI-tool query histories. Warehouse query logs and BI session logs show successive queries from one user minutes apart, which approximates refinement chains. They usually lack the natural-language utterance, so annotators must write it after the fact, and abandoned or erroring queries must be labeled rather than dropped.
• Analyst request threads. Ticketing and chat threads where business users ask a data team for numbers contain real follow-ups and clarification requests in natural language. The SQL that answered them often lives in a separate notebook or dashboard and must be linked. For chat transcripts as a separate asset class, see our page on licensing chat logs for AI training.
• Annotated sessions. Recruited analysts work a goal on a real or mirrored schema while annotators record utterances, gold SQL and results. Academic multi-turn sets were collected through controlled user interactions in this spirit, and human-in-the-loop systems such as BenchPress show how annotation tooling speeds benchmark curation from real query workloads [4].
• Synthetic expansion. Pipelines such as NVIDIA's NeMo Data Designer write-up generate text-to-SQL records per dialect, validate them against MySQL, PostgreSQL and SQLite, and inject distractor tables and columns [5]. Use synthetic turns to balance rare types, and hold out real sessions for evaluation.

Session logs from analytics tools contain customer names, account numbers and free-text notes in both utterances and result rows. Plan de-identification for result previews, not only for utterances; our privacy guide for de-identified training data covers the methods.

How to evaluate turn-level and session-level success

Evaluate at two levels, because per-turn accuracy can look acceptable while sessions fail. One drifted predicate at turn two can make every later turn wrong even if each query is well formed.

• Turn-level execution accuracy. Execute predicted and gold SQL against the same schema snapshot and compare result sets, order-insensitive unless ORDER BY is required. Exact-match on SQL text punishes valid rewrites.
• Context-carry accuracy. For each refinement or pivot, check that predicates and groupings from earlier turns survive unless the user removed them.
• Clarification precision and recall. Score whether the system asked when the gold says ask, and did not ask when the question was unambiguous. Over-asking is a product failure too.
• Session success. Did the user reach the goal, and in how many turns? This needs a session-level label written by the annotator or inferred from the original analyst's final query.
• Error recovery. Insert a deliberately wrong system turn and score whether the model accepts the user's correction.

Keep evaluation sessions separate from training sessions at the schema level, not just the session level, or the model memorizes table names. Our guide to private text-to-SQL evaluation sets on enterprise databases covers holdout design, and the training data quality assessment guide covers contamination checks.

Buyer checklist for a multi-turn text-to-SQL request

Write the request around sessions, schemas and labels, so suppliers can tell you quickly whether they hold anything close.

Illustrative example: invented to show structure; it does not describe an available dataset.

• Unit: one session = ordered turns sharing one user goal; state minimum and target turns per session.
• Turn-type mix: target shares for refinement, pivot, coreference, comparison, clarification, correction and reset.
• Gold per turn: SQL, dialect, schema snapshot ID and result hash; clarification turns carry gold clarification text instead.
• Schema context: DDL, foreign keys, column descriptions and metric glossary at the snapshot date.
• Provenance tag per session: BI log, analyst thread, annotated session or synthetic.
• Session labels: goal reached, turns to goal, abandonment reason.
• Privacy: de-identification of utterances and result previews, with the method documented.
• Documentation: a data card covering sources, annotation process, intended use and known gaps [6].
• Validation sample: a small set of sessions you can re-execute end to end before committing.

For a broader view of table grain, keys and history requirements, see what to specify when licensing tabular data. If you are also fine-tuning general dialogue behavior, multi-turn conversation data for chat fine-tuning covers non-SQL sessions.

How SourceX approaches conversational analytics data

SourceX sources operational datasets from US companies on request, including support and sales histories, engineering records, documents and finance workflows, and manages the licensing process; nothing is held in stock and a request does not guarantee a match. Buyers describe the data they need, such as analyst request threads with linked queries, and SourceX looks for US businesses that hold it, with every release approved by the supplying company. You can describe your requirement on the SourceX buyers page.

Each dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery. Personal details such as names, emails, phones and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. More options across the cluster are in the tabular, time-series and transactional data hub.

Request conversational text-to-SQL session data

If your assistant needs real follow-up, refinement and clarification turns from business users, describe the sessions, schemas and labels you need. SourceX looks for US companies holding that data and runs the process from assessment through licensing, and nothing is contracted until a supplier agrees. Describe your multi-turn SQL data need.