The schema isn't the model
Dumping schemas into an LLM wasn't working at Spotify's scale. The data warehouse has thousands of tables, and the same column name in two different tables can mean entirely different things. The model needs more than a list of fields to generate SQL that returns the right answer. It needs context. Specifically, it needs context that the people who own the data have and the model doesn't.
So Spotify built Vedder, a context layer that sits between the data warehouse and the model. The interesting part of the architecture isn't the model. It's what sits behind it. The context is owned by the people who actually understand the data, and that ownership is the part that doesn't show up in a vendor's pitch deck.
Clusters, the unit of context
Spotify's data domains are called clusters. Each cluster is a slice of the warehouse that maps to a specific team, initiative, or ad-hoc interest. A cluster is owned by a named team of domain experts and has three components.
The first is Datasets: the data warehouse tables that are relevant, with full schema and profiling. The model captures column cardinality, samples of common values, and partition structure. When the model generates a WHERE clause, it helps to know that the country column has values like 'US', 'GB', 'SE' rather than guessing. The second is Pairs: vetted question-and-SQL examples. A domain expert writes or approves each pair, picking examples that teach the patterns they would want a colleague to follow. The third is Docs: additional business context, including terminology, gotchas, definitions that vary by team, and which columns to use and which to avoid.
The curation is owned by the data experts. They decide how to split their domain into clusters, which tables to include, and which examples are important. The model doesn't decide what's true about the data. The experts do.
The shortcut that didn't work
The obvious shortcut was to skip the curator. Spotify's data warehouse holds the complete query history of every data expert who has ever used it. From there, generating question-SQL pairs is straightforward: take a query, ask an LLM to infer the question it was written for, and use those pairs to teach the model how to generate the SQL. These are real queries people actually wrote for answering their domain knowledge made into data. It looks like a way to scale.
The team tested it. Domain experts accepted 12.5% of the auto-generated pairs. Most of the rest was noise. Exploratory queries, debug sessions, one-off questions that don't generalize. The signal doesn't label itself. Scaling expertise doesn't mean replacing it. It means giving the people who know the most more leverage.
What this looks like in production
Vedder now handles 13,000+ conversations a month, and more than a quarter of its users had never written SQL. The model is good enough for the work, but the work is only possible because the context is right. A team building an agent over company data should copy the ownership model, not just the prompts.
The pattern generalizes. Most of the failures of LLM-based enterprise tooling come from the same place: the model is asked to figure out the context on its own, and the context is the part of the problem that the model can't figure out. The fix is to put a human in the loop, but the right human, the one who actually knows the data, not a generic prompt engineer.