A 200-Table Schema Is a Token Budget, Not a Context Window

A post on dev.to argues that a 200-table schema does not fit usefully in a prompt even when it fits the context window, and proposes a three-part design instead: a cheap call that picks the tables, a second call that sees only those tables in detail, and a read-only guarantee that lives in the database rather than in the prompt ^[1]. That is worth reading because the failure mode being avoided is not truncation. It is a bill you pay on every question and an attention budget spent on 194 tables the answer never touches ^[7][8].

The author starts by counting. Take 200 tables averaging 15 columns, so 3,000 columns ^[2]. In compact form, roughly 5 tokens per column and 5 per table line, that is about 16,000 tokens ^[3]. In full DDL, once defaults, nullability, whitespace and constraints are counted, roughly 14 tokens per column and 40 per table, about 50,000 tokens ^[4]. A one-line-per-table catalogue at about 25 tokens each is about 5,000 ^[5]. Full DDL is therefore about 3.1 times the compact form and ten times the catalogue ^[1][2]. The author is explicit that these are estimates from typical identifier lengths on an English-trained tokenizer, and that serialising your own schema and running it through your tokenizer takes about five minutes and replaces every number above ^[6].

The interesting claim is that 16,000 tokens fitting comfortably is not a defence. You pay it per question, it is near-uniform text competing with the actual question for attention, and the tables that can answer any given question are almost always fewer than six ^[7]. Shipping the other 194 forces the model to choose between similarly named columns in tables it should never have seen ^[8].

The catalogue is the part you have to write by hand, and the author says it is worth an afternoon: "One row per customer order" beats a column list because table names lie, and in a mature schema `orders` often means order headers while a second table holds what a user would call an order ^[9]. Draft it from the schema and its comments, have someone who knows the data correct it, and keep it in the repository next to the migrations, because it goes stale exactly when they change ^[10].

Selection returns JSON: the tables, the joins, a `why` map, and a `missing` field ^[11]. The rules forbid naming a table outside the catalogue, forbid substituting the nearest table when nothing fits, forbid adding a table because it is usually joined to one already chosen, and require every selected table to appear in `why` ^[12]. The justification requirement is the cheap defence against over-selection, since "it is usually there" is not a clause anyone writes down ^[13]. The `missing` field plays the role a blessed none-of-these label plays in classification; without it, an unanswerable question yields a confident answer over the wrong tables ^[14].

The economics follow. Catalogue plus about 150 tokens of output is small enough for a fast model, and the catalogue is a fixed prefix, so only the question is uncached ^[15]. Notably, the excerpted second-stage prompt uses the compact form for the chosen tables plus explicit joins, not full DDL ^[16]. Six tables compact is roughly 480 tokens; six tables in full DDL is roughly 1,500 ^[3][5]. Either way the two passes land near 5,600 to 6,650 tokens, about 11 to 13 percent of sending everything as DDL ^[4].

What to watch: whether the catalogue actually gets updated with the migrations it sits beside ^[10], and the read-only mechanism, which this excerpt asserts belongs in the database but does not specify ^[1].