There is a category of question that creates disproportionate pressure on analytics teams: questions that are conceptually simple, organizationally urgent, and technically expensive to answer given the current tooling. The questions are not hard. The pipeline to answer them is.
Here are five patterns we see repeatedly. Each one is a variation on the same underlying problem: the question is about something the warehouse knows, but extracting that answer requires specialist knowledge of where it lives and how to write the query.
The period-over-period comparison
"How did last month compare to the month before, for [metric]?" This arrives constantly: from finance before board meetings, from product managers watching feature adoption, from operations reviewing throughput. The underlying query is straightforward in concept: aggregate a metric over two time windows and divide. In practice, it requires knowing the right table, the right date column (some warehouses store event time in UTC, some in local time, some in a timestamp column named created_at and some in one named event_date), and the right filter for the metric in question.
An analyst who knows the schema writes this in three minutes. An analyst encountering the schema for the first time writes it in thirty. For anyone without SQL access, it is a request that goes into the queue and takes a day to return.
The segment breakdown
"Break that number down by [dimension]." This always follows the first question. The aggregate came back, and now someone wants to know which segment is driving it. Breakdown by product category, by channel, by geography, by acquisition cohort. Each breakdown requires knowing which dimension table to join, what the join key is, and whether the granularity of the dimension matches the granularity of the fact table.
The tricky part: the dimension that seems obvious in the question often maps to a column that is non-obviously named in the schema. "Channel" in a marketing context might be utm_source, acquisition_channel, channel_id pointing to a lookup table, or something else entirely depending on how the warehouse was built. Someone has to resolve that ambiguity.
The cohort question
"Of the users who signed up in [time window], what percentage completed [action] within [timeframe]?" Cohort analysis is one of the most common requests in product analytics and one of the most time-consuming to write correctly. It requires a self-join or a window function to define the cohort, a join to the event table to check for the action, and careful date arithmetic to define the timeframe correctly.
This is not a complex query conceptually. The logic is "users from this cohort, did they do this thing, within this window." It is, however, one of the query patterns where syntax errors are most likely to produce a result that looks plausible but is wrong. The query runs, returns numbers, and the numbers are subtly incorrect because the cohort window or the event filter was specified slightly off. These errors are hard to catch without deep schema knowledge.
The cross-table join that requires institutional knowledge
"Show me [fact A] alongside [fact B] for the same records." This one breaks immediately if the requester does not know the join key. Order data joined to customer data seems obvious until you discover that orders reference customers by an internal ID that does not match the user ID in the auth system, and there is a mapping table three hops away that no one documented. The analyst who built that mapping table is the only person who can write this query efficiently. Everyone else spends an hour in the schema trying to reconstruct the join path.
This is the class of question where the three-day answer is not because the query is slow. The query itself takes seconds. The three days is research time, figuring out what to write before running it.
The "just give me the raw records" question
"Can you pull me all the records where [condition]?" This sounds like the simplest of the five but is often among the most frustrating. The requester has a mental model of the data. The warehouse has a physical model of the data. Those two models often have subtle differences: fields are named differently, conditions require knowing about a status code lookup rather than a boolean flag, or "all records where X happened" actually requires joining across three tables to reconstruct what "X happened" means in the physical schema.
The analyst who takes this request either answers it correctly (because they know the schema) or answers it incorrectly (because they guessed). The requester usually cannot tell which, because they do not know the schema either.
The common thread
All five of these question types have the same structure: the question is conceptually clear to the person asking it, and technically answerable from data the warehouse contains, but the translation from conceptual question to executable query requires schema knowledge that most people do not have.
This is what creates the queue. Not analytical complexity. Not large datasets. Not slow infrastructure. The bottleneck is schema knowledge held by a small number of people who are therefore asked to produce every query that requires it.
We are not saying these questions need to be answered without careful data interpretation. Some of these, especially the cohort question, require verification that the result makes sense before acting on it. What we are saying is that the step of producing a syntactically correct, semantically right query for these patterns should not require a dedicated specialist. The specialist's time is better spent on interpretation, validation, and the analytical work that requires actual judgment, not transcription.
The three-second answer is not fantasy. For questions like these, where the structure is known and the schema is indexed, query generation from a natural language description is a tractable problem. The three days are the current cost of a gap that does not need to exist.