Skip to content

CONCEPT Cited by 1 source

Text-to-SQL

Text-to-SQL is the task of generating an executable SQL query from a natural-language question, given a specific database schema (and, in practice, a mass of surrounding context: table docs, glossary terms, metric definitions, historical queries, freshness/quality signals).

Why the naive recipe breaks at production scale

The textbook shape — "give an LLM the question plus a table dump of the schema" — works for toy benchmarks but breaks on real warehouses. Pinterest names four failure modes at 100,000+ analytical tables and 2,500+ analysts scale (sources/2026-03-06-pinterest-unified-context-intent-embeddings-for-scalable-text-to-sql):

  1. Vocabulary mismatch. The analytical question does not match any table description's wording.
  2. Multiple candidate tables, one right join path. Many tables could answer the question, but only specific join patterns work.
  3. Company-specific metric conventions. The "right" way to compute a metric involves Pinterest-specific domain logic not visible in the schema.
  4. Split sources of truth. Quality signals (tiering), authoritative schemas, and established query patterns live in different systems — no single retrieval pulls all the context needed.

Two production shapes documented on the wiki

Shape A: unified context-intent embeddings over query history (Pinterest)

Pinterest's production answer (sources/2026-03-06-pinterest-unified-context-intent-embeddings-for-scalable-text-to-sql):

  • Encode historical SQL queries through a three-step pipeline (domain context injection → SQL-to-text → text-to-embedding).
  • Retrieve by analytical intent, not by table description.
  • Rank with governance-aware fusion over tier / freshness / ownership.
  • Generate SQL that reuses validated join keys + filters from the retrieved historical patterns, then EXPLAIN-validate before EXECUTE.

Thesis: "your analysts already wrote the perfect prompt." Query history is a knowledge base of expert- authored analytical solutions.

Shape B: graph-walk SQL generation (Netflix UDA / Sphere)

Netflix's contrasting answer (sources/2025-06-14-netflix-model-once-represent-everywhere-uda; patterns/graph-walk-sql-generation):

  • Model business concepts + data containers as nodes in a knowledge graph; mappings are edges.
  • User picks concept endpoints; graph-walk produces the JOIN specification.
  • SQL is compiled from the walk, not generated by an LLM.

The two shapes are not competitors so much as different stances on where the domain knowledge lives: Pinterest treats query history as the knowledge substrate; Netflix treats the curated knowledge graph as the substrate.

What production Text-to-SQL needs beyond "LLM + schema"

Pinterest explicitly names the infrastructure surfaces required:

  • Governance + tiering to separate production-grade tables from staging/legacy.
  • Glossary terms + lineage- based propagation for column-level semantic unification.
  • Rich documentation — maintained at scale via AI-generated docs with a human-review ladder.
  • Query-history indexing — turn accumulated analyst queries into a searchable library.
  • Vector DB platform — an internal substrate so every LLM feature isn't reinventing its own index.
  • Validation — EXPLAIN-before-EXECUTE, bounded retry, conservative LIMIT.
  • Asset-first design — surface existing curated assets before generating new SQL.

Seen in

Last updated · 319 distilled / 1,201 read