Why Analysts Are Moving Exploratory Work Into SQL Notebooks

Analysts are increasingly starting their work in notebook-style environments that interleave SQL, exploration, and visualization in one document, and the default workflow is now "explore in a notebook first, build a dashboard second." The catch is that all of that exploratory value evaporates unless the work stays reproducible, which is the part most teams get wrong.

This is a quiet but real shift in how exploratory data analysis happens. The lone SQL tab is giving way to the SQL notebook, and understanding why tells you something important about what makes data work durable instead of disposable.

From ad-hoc query to durable analysis

Think about how an analysis used to start. Someone has a question, opens a SQL client, writes a query, eyeballs the result, tweaks it, runs it again, copies the output into a spreadsheet, makes a chart, pastes the chart into a Slack message or a deck, and moves on. The answer gets delivered. The work that produced it disappears. A week later someone asks "how did you calculate that," and the honest answer is "I do not remember, let me redo it."

That pattern was fine when analytics was a side activity. It stopped being fine when data became central to how companies make decisions, because the same questions keep coming back and the same analysts keep redoing the same work from scratch. The cost of disposable analysis is not one wasted afternoon. It is the same afternoon, wasted repeatedly, forever.

The notebook is the response. Instead of a transient SQL tab, an analyst works in a document where each step (a query, a transformation, a chart, a note explaining what they found) is a cell that persists. The analysis becomes an artifact, not an event. It can be reopened, re-run, handed to a teammate, and built upon. The unit of work shifts from "the answer I delivered" to "the analysis that produced it," and that is a much more valuable thing to own.

Why notebooks beat a lone SQL tab

A SQL tab gives you one thing: the ability to run a query. A notebook gives you the thing analysts actually need, which is the ability to think in steps and keep the thinking attached to the result.

Narrative and logic stay together. In a notebook, the markdown cell explaining why you filtered out test accounts sits right next to the query that does it. The reasoning does not live in your head or in a separate doc that goes stale. Anyone reading the notebook understands not just what you computed but why.

Exploration is iterative by design. Real analysis is not one query. It is a query that raises a question that prompts the next query. A notebook captures that chain, so the dead ends and the breakthroughs are both visible. The next person does not have to rediscover which approaches did not work.

SQL and visualization live in one place. The best notebook tools (Hex, Mode, and others in the category) let you write a SQL cell, get a result table, and chart it without leaving the document or exporting anything. The friction between "I have the numbers" and "I can see the shape of them" drops to zero, which is exactly when good exploration happens.

The lone SQL tab optimizes for running a query fast. The notebook optimizes for understanding a problem completely, and understanding is the actual job.

Reproducibility is the hard part

Here is where it gets uncomfortable. A notebook makes exploration persistent, but persistent is not the same as reproducible, and the gap between the two is where notebooks earn their bad reputation.

The classic notebook failure is the out-of-order execution mess. Cells get run top to bottom, then a cell in the middle gets edited and re-run, then another, and the visible state of the notebook no longer corresponds to any order you could actually re-execute. You hand it to a teammate, they hit "run all," and it breaks or, worse, produces a different number. The notebook looked reproducible. It was not.

The deeper issue is that exploration touches things that move. The underlying table gets new rows. A column gets renamed upstream. The definition of a metric you hand-coded in a cell quietly diverges from the one the rest of the company uses. A notebook that hardcodes its own version of "active user" is a notebook that will eventually disagree with every dashboard, and nobody will know which is right.

So the value of notebook-style exploration is entirely conditional. It depends on two things: that the analysis runs deterministically the same way every time, and that it sits on immutable, shared definitions rather than re-inventing them in a cell. Get those right and a notebook is a durable asset. Get them wrong and it is a confident-looking lie that breaks the moment someone trusts it.

The path from exploration to dashboard

Exploration should not be the end state. The whole point of exploring is to find something worth monitoring, and the things worth monitoring deserve to graduate into a maintained artifact (a dashboard) rather than dying in a notebook nobody reopens.

The healthy lifecycle looks like this. An analyst explores a question in a notebook, iterating freely. They find a real insight: a metric that matters, a segmentation that explains something, a trend worth watching. At that point the exploration has done its job, and the insight needs to move into a durable, governed home where it gets the metric defined once, the chart maintained, and the result trusted over time.

The broken lifecycle is the one where exploration and dashboarding are two disconnected worlds. The analyst explores in a notebook, then rebuilds everything from scratch in a separate BI tool, re-deriving the same metric in a different syntax, introducing a chance for the two to disagree. That rebuild is pure waste, and it is where definitions drift. The exploration should flow into the dashboard, carrying its definitions with it, not get thrown away and re-implemented.

This is the same single-source-of-truth principle that the whole 2026 stack is converging on, which I wrote about in where the BI layer goes next. A notebook that explores against the same semantic layer the dashboard will use is a notebook whose findings transfer cleanly, with no re-derivation and no drift.

Keeping notebooks honest with version control

The thing that makes exploration trustworthy is the same thing that makes any other code trustworthy: version control. A notebook is honest when it is text, in a repository, with a history.

When an analysis lives in Git, three problems solve themselves. You can see what changed and when, so "why does this number look different than last month" has an answer in the diff. You can review an analysis before anyone trusts its conclusion, the same way you review code before shipping it. And you have a permanent record, so the work survives the analyst leaving, the laptop dying, and the year passing.

Version control also enforces the reproducibility discipline that notebooks otherwise lack. If the analysis is text and it lives next to the metric definitions it depends on, then re-running it is deterministic and the definitions it uses are the shared, reviewed ones rather than a private copy. The notebook stops being a personal scratchpad and becomes a contribution to the team's body of knowledge, which is the entire promise of a code-first data workflow extended to the exploratory stage.

The principle is simple: exploration that cannot be reproduced is entertainment, not analysis. Version control is what turns one into the other.

A look at notebook-style exploration in Visivo

This is the gap Visivo is building toward closing. The exploration tooling (an Explorer for working through questions in a notebook-like flow) is designed to sit on the same code-defined semantic layer that the dashboards do, so the metrics and dimensions you explore with are the exact ones your Insights will reference.

The intent is to make the path from exploration to dashboard a continuation rather than a rebuild. You explore against defined metrics, and when you find something worth keeping, the definitions you used carry straight into a code-defined Insight with no re-implementation:

insights:
  - name: weekly-active-by-plan
    props:
      type: line
      x: ?{ ${ref(events).activity_week} }
      y: ?{ ${ref(events).active_users} }
    interactions:
      - split: ?{ ${ref(events).plan} }

Because everything lives in version-controlled YAML, the exploration that produced an Insight is reviewable and reproducible by construction, and the metric you explored with is the same one the whole team shares. That is the shape of honest exploration: durable, reproducible, and continuous with the dashboard it feeds. The examples gallery shows the dashboard end of that flow, and /get-started is the fastest way to try the model yourself.

Previously in Visivo

This continues the thread from the modern data stack in 2026: if BI is becoming the final code-defined layer, then the exploration that feeds BI has to be code-defined and reproducible too, or the gains stop at the dashboard's edge. For the foundational argument that data work belongs in your repository, start with what BI-as-code is and why it matters.