Schema Linking + RAG over the Warehouse

How to give LLMs access to large warehouse schemas: embedding table and column metadata, retrieving relevant schema context, and the schema linking problem.

Schema linking is the hardest sub-problem in text-to-SQL at scale. At five tables, you can put the entire schema in context. At fifty tables, you are at the edge. At five hundred tables -- the reality of most enterprise data warehouses -- you cannot. Schema linking is the process of identifying which tables and columns are relevant to a user's question before generating SQL. Get it wrong and the LLM generates SQL against the wrong tables. Get it right and the rest of the problem becomes tractable.

The standard approach is RAG over schema metadata: embed descriptions of every table and column, index them in a vector store, and retrieve the most relevant ones at query time. This is straightforward to build but fragile to maintain. The quality of schema linking is bounded by the quality of the metadata -- if your column descriptions are empty or wrong, retrieval fails and SQL generation fails downstream. Schema documentation is not a nice-to-have; it is the infrastructure that makes LLM warehouse access work.

Beyond simple semantic retrieval, production schema linking systems add structural signals: table relationship graphs (joins available between tables), query history (which tables appear together in past queries for similar questions), and schema popularity (frequently queried tables and columns get higher retrieval weight). These signals require the data engineer to build and maintain them as infrastructure -- they do not come from the warehouse for free. The teams getting the best results on schema linking are the ones treating it as a data product problem, not an LLM problem.

Key resources

• A Survey of Text-to-SQL with Large Language Models (arXiv)

  The most comprehensive recent survey of the field. The schema linking section (section 4) is the clearest technical treatment of the core problem: how do you identify which tables and columns are relevant to a question before generating SQL?

• Snowflake Cortex Analyst -- Enterprise Text-to-SQL

  Shows how an enterprise warehouse vendor solves schema linking at scale: a semantic model layer sits between the LLM and raw tables, reducing the schema search space to pre-approved, documented entities.

• pgvector -- Vector Search for PostgreSQL

  If you are building schema linking on your own infrastructure, embedding table and column descriptions and indexing them in pgvector is the lightest-weight path. No additional vector database required.