Why Every DataLens Answer Ships Its SQL

Every answer in DataLens ships with the SQL query that produced it. Not behind a toggle, not on request — attached, visible, re-runnable, every time.

Some users love this. Others have told us, reasonably, that it clutters the screen, intimidates their non-technical teammates, and makes a simple product feel like a developer tool. Both groups are describing the same decision accurately. This post is the honest account of what showing the SQL costs us, and why we pay it anyway.

The trust problem with black-box AI answers

A text-to-SQL tool that shows only a number is asking for something remarkable: that you act on a computation you cannot inspect, produced by a system that fails silently. When an AI joins on a non-unique key and inflates revenue 5x, there is no error message, no warning, no uncertainty flag. There is a beautifully formatted chart with a wrong number in it.

This is not a hypothetical failure. It is the default failure — the silent semantic kind that runs perfectly and answers a different question than asked. Against that failure, every mitigation we have (auditing the JOINs, checking the grain, confirming the filters) requires exactly one precondition: the query must be visible. A hidden query is not a simplification. It is the removal of the only evidence that could convict a wrong answer.

There is a second, quieter problem. A number without its query has no provenance. When two people quote different revenues in the same meeting — and with probabilistic generation across sessions, they will — there is nothing to compare. Two queries can be diffed in seconds; two numbers can only be argued about. Hiding the SQL does not remove disagreement. It removes the ability to resolve it.

What showing the SQL costs us — honestly

We would be lying if we presented this as a free choice. It costs us in at least four ways, and we feel all of them.

There are subtler costs too. Visible SQL constrains our design: answers must be explainable, which rules out clever-but-opaque execution tricks. It slows perceived speed, because an answer that arrives with its working invites scrutiny rather than acceptance — and scrutiny takes time. And commercially, it gives away the one artefact a competitor could mimic most easily. A black box is mysterious; a glass box can be copied.

Why we made that tradeoff anyway

Four reasons, in ascending order of importance.

Accountability has to land somewhere. When a number in a board deck is wrong, a human owns it. That ownership is only fair — and only functional — if the human could have checked. Shipping the SQL is what makes "did you check it?" a reasonable question instead of an absurd one. The tool's job is to make checking cheap, not to remove the need for it.

It makes users better, compounding. Something we did not fully predict: users who see queries learn queries. A marketer who has watched forty WHERE financial_status IN ('paid', 'partially_refunded') clauses starts writing better questions — specifying "paid only" unprompted, catching grain mismatches before asking. The visible SQL is a tutoring system disguised as an audit trail, and its graduates ask questions that fail less often.

It keeps us honest as builders. A team that must display every generated query cannot ship sloppy generation and hide behind a polished number. Every fan-out join, every missing NULL guard, every deprecated-table selection is on screen, attributable, embarrassing. That embarrassment is a quality process money cannot buy — it aligns our incentives with correctness in a way no internal metric could.

And fundamentally: the alternative is untrustworthy by construction. Not "less polished" or "harder to adopt" — untrustworthy in the precise sense that matters. A number you cannot verify is a rumour with formatting. We are building an analytics tool, and an analytics tool that asks for faith instead of offering evidence has misunderstood its own category.

None of this means the raw query is the whole interface. We work hard on the parts around it — the plain-English explanation of what the query does, the one-click re-run that confirms the number hasn't drifted, the byte estimate shown before anything executes. The goal was never "make everyone read SQL." The goal is that everyone could, and that the assumptions behind every number are one glance away instead of sealed inside a model.

Frequently asked questions

Doesn't showing SQL confuse non-technical users?

Less than expected, and we have watched this closely. Most people cannot write SQL and can still read enough of it to spot "this covers August, not September" or "there is no refund filter" — which are the errors that matter. The value is not in parsing the query; it is that the assumptions become visible at all. An English summary alongside the query covers the rest.

Why not show it only on demand, behind an expandable?

Because defaults determine behaviour. Our data and everyone's experience with expandable sections agree: anything behind a click is inspected rarely, and "rarely inspected" fails exactly when inspection mattered most — the high-stakes number, the rushed morning, the board deck. Trust infrastructure that activates only when remembered is not infrastructure.

Do your competitors do this?

Some show partial queries; most show none, and we understand why — it is prettier, it demos better, and it converts faster. We consider that a short-term advantage funding a long-term liability: every silent wrong number their users ship erodes the category's credibility, ours included. Somebody has to be checkable. We would rather it be us.

Does visible SQL slow down getting answers?

It adds roughly a minute of optional verification to an answer that arrives in seconds — against an analyst queue measured in days. The comparison that matters was never "black-box AI versus glass-box AI." It is "either AI versus waiting until Thursday." We will take the minute.

What if the generated query is long or complex?

Length is itself a signal worth seeing — a 200-line query answering a simple question deserves a raised eyebrow. We keep generated queries as readable as we can (CTEs over nesting, explicit column lists, no SELECT *), and the explanation alongside it translates the logic clause by clause. If a query is too complex to follow even roughly, that is information about the answer's risk, and hiding it would hide exactly that.

The summary

• A number without its query is a rumour with formatting — uninspectable, un-diffable, and silent when wrong.
• Showing every query costs us serenity, activation smoothness, support load, and design freedom. All real, all felt.
• We pay it for accountability (checking must be possible), compounding user skill, builder honesty, and the categorical point: an analytics tool runs on evidence, not faith.
• The friction is the feature. Verification labour pushed onto the user beats verification made impossible — especially when we keep working to make the minute cheap.