The text-to-SQL demo takes an afternoon. The other 90% is why you should buy it.

Originally published at nlqdb.com/blog

The demo really is an afternoon. Pull the table definitions out of information_schema, template them into a prompt with the user's question, call a model, run whatever SQL comes back, render the rows. Every stack has a tutorial for this now, and they all work — "let our users ask their data in English" goes from ticket to working prototype before the day ends. That's the 10%.

The other 90% shows up after the first real user

The prototype's job was to produce SQL. The feature's job is to run model-authored SQL against your production database, on your users' behalf, unattended. Those are different jobs, and the gap between them is a stack of infrastructure the tutorial never mentions:

A validator that fails closed. The model will eventually emit a write — a DELETE inside a CTE, a DROP behind a comment, a join onto a table the asker should never see. You need a parser-level allow-list that rejects everything except the reads you meant to permit, and rejects anything it can't parse. A regex denylist is the bug report you haven't received yet.