Visivo v1.0.80: A SQL Editor, Pivotable Tables, and Insight-Driven Tables

Visivo v1.0.80 turns the new Explorer into a real analysis surface. This release adds a SQL editor inside the Explorer, drag-and-drop pivotable tables for on-the-fly summarization, a store-backed project view that keeps the workspace in sync, and the ability for Insights to drive tables directly. Together they close the gap between exploring data and shipping a defined artifact.

Here is what shipped, why each piece matters, and what the combination unlocks.

What shipped in v1.0.80

Four changes anchor this release, and they reinforce each other rather than standing alone:

• A SQL editor in the new Explorer, so you can write raw SQL against your governed source without leaving the tool.
• Pivotable tables with drag-and-drop summarization, so you can reshape a result into a pivot interactively.
• A store-backed project view, so the Explorer reads from a single, consistent representation of your project state.
• Insights driving tables directly, so a defined Insight can render as a table, not only a chart.

The theme tying them together is that the Explorer is graduating from a viewer into a workshop. You can now explore in raw SQL, reshape the result, and promote it into a defined, reusable artifact, all in one place.

A SQL editor in the new Explorer

The headline addition is a SQL editor built into the new Explorer. Until now, when a question fell outside the curated models and Insights, the honest answer was to drop out to a separate SQL client. That break in the workflow is exactly the kind of escape hatch we argued for in give power users a SQL editor, and v1.0.80 brings it inside the tool.

The editor runs against the same governed source your project already uses. You are not copying a connection string into a notebook or exporting a CSV to analyze elsewhere. You write SQL, you run it, and you see the result on the same surface where your models and Insights live. That keeps the ad hoc query in the same governed environment as everything else, which is the whole point: the answer you compute by hand draws on the same source, and stays discoverable, rather than fragmenting into a private file.

The deeper benefit is continuity. An exploratory query in the editor is a starting point, not a dead end. Because it lives next to your project's defined objects, the path from "I just proved this in SQL" to "this is now a defined Insight" is short, which is what the rest of this release is built to support.

Pivotable tables with drag-and-drop summarization

The second change is pivotable tables. A flat result set is often not the shape you want to read. You want to summarize it: group by one field, break out another across columns, aggregate a measure in the cells. That is a pivot, and v1.0.80 makes it a direct-manipulation action in the Explorer.

Drag-and-drop summarization means you reshape the table by moving fields, not by rewriting the query. Drag a field to rows to group by it, drag another to columns to spread it across, drop a measure into the values and pick the aggregation. The table re-summarizes as you go. This is the interactive, analyst-driven reshaping we covered in pivot tables in the modern data stack, now available right in the Explorer.

What this buys you is iteration speed on the table itself. Instead of editing SQL and re-running every time you want a different cut, you rearrange the pivot and read the new shape immediately. For the kind of quick "show me revenue by region across months" question that comes up constantly, the pivot is faster than a query rewrite and lets you try several framings in the time one query edit would take.

A store-backed project view

The third change is more architectural, but it is what makes the other features feel coherent: the Explorer now reads from a store-backed project view. Rather than each part of the interface holding its own copy of the project state, the Explorer renders from a single, consistent store that represents what is actually in your project.

The practical effect is consistency across the surface. When something in the project changes, the views that depend on it reflect the same underlying state instead of drifting out of sync with each other. The SQL editor, the pivot table, and the Insights you have defined are all reading from one representation, so what you see in one place agrees with what you see in another.

This is the kind of foundation work that does not have a flashy demo but pays off everywhere. A single source of project state in the client is what lets the editor, the tables, and the Insights compose cleanly rather than each maintaining a slightly different picture of the world. It is the plumbing that makes the workshop feel like one tool instead of several bolted together.

Insights can now drive tables

The fourth change closes the loop: Insights can drive tables directly. An Insight is Visivo's central visualization object, a defined connection between a model and how its data is presented, with client-side filters, splits, and sorts. Until now you would naturally think of an Insight as backing a chart. In v1.0.80, an Insight can render as a table just as readily.

That matters because it unifies how defined artifacts are presented. The same Insight definition can be a chart in one place and a table in another, drawing on the same model and the same governed metrics and dimensions. You define the logic once, the way the semantic layer intends, and choose the presentation per context.

insights:
  - name: revenue-by-region
    description: "Revenue by region, rendered as a table"
    model: ${ref(orders)}
    props:
      type: table
    interactions:
      - split: ?{ ${ref(orders).region} }
      - sort: ?{ ${ref(orders).total_revenue} DESC }

Because the table is driven by an Insight, it inherits the same governed definitions and the same client-side interactions as a chart would. A table is no longer a separate, lesser construct you configure by hand. It is one more way to render a defined Insight.

What it unlocks

Read the four changes together and the picture is clear: the Explorer is now a place where the whole builder loop happens. You explore a question in the SQL editor against your governed source. You reshape the result with a drag-and-drop pivot until you can read it. The store-backed view keeps everything you are doing consistent across the surface. And when the question turns out to matter, you promote it into an Insight that can render as a chart or a table, reusing your governed metrics and dimensions.

That is the path from ad hoc to governed, compressed into one tool. The exploratory query does not get stranded in a notebook, and the table you build by hand is not disconnected from your definitions. Exploration and definition live on the same surface, which is exactly what the redesign has been building toward, as we discussed in redesigning BI for analysts.

To try v1.0.80, get started with a local project, or browse the examples to see Insights, tables, and the semantic layer working together. For the full workflow from definition to dashboard, see from YAML to dashboard.

Previously in Visivo

This recap follows directly from redesigning BI for analysts, not executives, where we made the case for building BI around the analyst's iteration loop. v1.0.80 is that philosophy shipping in code: a SQL editor, drag-and-drop pivots, a consistent project view, and Insight-driven tables, all aimed at making the build loop fast inside the new Explorer.