The Questions People Actually Ask Their Database
When you build a tool that lets people ask their database questions in plain English, you get a front-row seat to what people actually want to know. Not the polished analytics questions from a BI demo. The real ones, typed by a real person mid-task who needs an answer now.
I expected sophisticated analytics. What I mostly see is something more human and more revealing, and it changed how I think about what data access is for.
They're not doing analytics. They're checking on something.
The single most common shape of question isn't "analyze" anything. It's "is this one specific thing okay." Did this customer's payment go through. Why does this user show as unverified. Did the webhook for order 8841 actually fire. Is this account on the plan they think they're on.
These aren't analytics questions. They're closer to looking something up in a filing cabinet, except the filing cabinet is a production database and the person needs the answer to unblock a support ticket or a debugging session right now. The volume of "check on this one thing" questions dwarfs the volume of "show me a trend" questions, and I did not expect that.
It makes sense in retrospect. Trends are a once-a-week, once-a-month thing somebody schedules. "Did this work" is a question people have dozens of times a day, every time something looks slightly off and they want to confirm reality before they act on it.
The questions reveal who was blocked
The other thing the questions show is who in a company was previously locked out of their own data, and it's not who you'd guess.
The heaviest users of plain-English database access aren't the analysts. The analysts could already write SQL. The heavy users are the support reps, the ops people, the customer success folks, the founders' non-technical cofounders. People who had questions about production data all day long and whose only previous option was to interrupt an engineer and wait.
When you read their questions, you can feel the relief in them. They're asking things they clearly wanted to ask for months but couldn't, because the cost of each question used to be a Slack message to someone busier than them and an hour of waiting. The questions were always there. The access wasn't.
The follow-up is the real pattern
Here's the part that convinced me conversational access matters more than I first thought. The questions come in chains.
Almost nobody asks one question. They ask "how many orders failed yesterday," see the number, and immediately ask "which ones," then "what do those have in common," then "is it all one payment provider." Each answer changes the next question. It's a conversation with the data, not a query.
A dashboard can't do this. A dashboard answers the first question and has no idea about the second. The whole reason this works is that the person can follow their own curiosity one step at a time without knowing where they'll end up. The first question is rarely the one that matters. The fourth one, the one they only thought to ask after seeing the first three answers, is usually where the actual insight is.
That's an argument against the entire "pre-build the views people might want" model. You can't pre-build a chain of questions, because each link only exists because of the answer before it.
What I changed my mind about
I started out thinking the value of natural-language database access was efficiency: same questions, answered faster. Read enough real questions and you realize that's underselling it.
The value is the questions that never got asked at all. The support rep who would've just guessed instead of bugging engineering. The ops person who would've made a decision on a hunch because checking was too expensive. The founder who would've shipped without verifying because the verification required someone else's afternoon. Those questions used to die unasked, and unasked questions are invisible, so you never knew how many decisions were being made blind.
The questions people actually ask their database, it turns out, are mostly small, mostly urgent, and mostly the kind that used to not be worth the trouble. Making them worth the trouble — cheap enough to just ask — is most of what we're really doing at QueryBear. Not better analytics. More answered questions, by more people, about the small things that were quietly being guessed at before.