SQL Schema to Prompt Context
Turn CREATE TABLE statements into a compact schema description a model can write SQL against, and see what it costs on every request.
3 tables, 16 columns, 473 characters. You pay this on every question you ask about this database, not once.
- Characters of DDL pasted in
- 870
- Characters of schema context out
- 473
- Reduction
- 46%
- Estimated tokens of the original DDL
- ≈ 218
- Tables described
- 3
- orders: internal_note (excluded by name)
- Line 19: "CREATE INDEX…" is not a CREATE TABLE, so it contributed nothing. Indexes, views, triggers and grants are not part of a schema description.
public.orders becomes orders — because the prefix is the same on every line and buys the model nothing. Token figures are characters ÷ 4 and are estimates. Everything on this page runs in your browser. Nothing you paste is uploaded, logged or sent anywhere.Asking a model to write SQL against your database means putting the schema in the prompt, and the naive way to do that is to paste the output of pg_dump --schema-only. That file is written for another database to read: it is full of sequences, index definitions, grants, storage parameters and schema qualifiers, none of which help a model write a SELECT, all of which you pay for on every request.
What actually helps
Three things, in order. The column names, because they are what the query is made of. The foreign keys, because they are the joins — a model that can see orders.customer_id → customers.id will write the join; one that cannot will invent a plausible-looking one. And the types, mainly so it does not compare a timestamp to a string. Nullability and defaults are worth having when the model is writing INSERTs and mostly not otherwise, which is why they are separate toggles.
The columns to leave out
Not every column belongs in a prompt. Internal notes, audit blobs, soft-delete flags nobody remembers and the forty columns of a wide reporting table are cost with no benefit, and one of them may hold personal data you would rather not have in a request at all. Both filters above list what they removed instead of hiding it, because a schema that quietly lost a column is worse than one that never had it: you will spend an afternoon wondering why the model refuses to use a table it cannot see.
Read the skipped list
If a table you expected is missing, the reason is almost always in that list — a CREATE TABLE the parser could not close, a dialect quirk, or a statement that turned out to be a view. Nothing here is dropped silently, so the list is the first place to look rather than the last.