Visivo v1.0.79: Parquet-Backed Tables and a Smarter Explorer

Visivo v1.0.79 makes the Explorer faster and more complete: data tables are now Parquet-backed for quicker reads, a new query-profile panel shows exactly what each query did, schema introspection runs as a background job, the Explorer parses Snowflake schemas, and every object type is now editable in place. Taken together, this release is about performance and Explorer maturation on top of the semantic-layer foundation we have been building all quarter.

What shipped in v1.0.79

This is a focused, infrastructure-heavy release. The headline is that the Explorer keeps growing into a real workbench rather than a read-only previewer. Five changes drive that:

1. Parquet-backed data tables so reads stay fast as result sets grow.
2. A query-profile panel in the Explorer that surfaces timing and shape for each query you run.
3. Background schema jobs so introspection no longer blocks the UI.
4. Snowflake schema parsing inside the Explorer, extending warehouse coverage.
5. Every object type is now editable from the Explorer, not just a subset.

None of these change the way you author a project: your models, metrics, dimensions, relations, and insights are still plain YAML in version control. What changes is how quickly and confidently you can iterate on them. If you are new to the 2.0 model, the semantic layer for AI-ready analytics post is the best starting point, and automatic schema introspection for BI covers the introspection groundwork this release builds on.

Parquet-backed data tables

Data tables in the Explorer used to be backed by row-oriented storage, which is fine for small previews but slows down as you scroll, filter, or re-sort larger result sets. In v1.0.79 those tables are backed by Parquet, the columnar format that nearly every modern analytics engine reaches for.

The practical effect is simple. When you open a model preview or an insight result, the Explorer reads only the columns it needs to render the current view rather than deserializing entire rows. Sorting and column-level operations get cheaper because the data is already laid out by column. As your local result sets grow from thousands of rows to hundreds of thousands, the table stays responsive instead of stalling.

This is a quiet change with an outsized impact on the feel of the tool. You will not see a new button. You will notice that the Explorer stops getting sluggish on bigger queries. If you want the deeper story on why columnar storage is the right default here, the companion piece, why Parquet quietly became the default for analytics data, walks through the format itself.

Query-profile panel in the Explorer

When a query feels slow, the first question is always "slow where?" v1.0.79 adds a query-profile panel to the Explorer so you can answer that without leaving the tool.

After a query runs, the panel reports the essentials: how long the query took, how many rows came back, and the shape of the result. Instead of guessing whether a sluggish insight is a problem with your SQL, your source, or the rendering layer, you get a concrete profile to reason about. That matters most when you are composing insights against the semantic layer, where a single chart can fan out into joins across multiple models through relations.

The profile panel turns "this feels slow" into "this query returned 240,000 rows and took 1.8 seconds, so the bottleneck is the scan, not the render." That distinction is the difference between optimizing the right thing and chasing the wrong one. It pairs naturally with the Parquet-backed tables above: profile first, then decide whether the fix is a tighter filter, a better-shaped model, or a pushdown to the source.

Background schema jobs

Schema introspection is how Visivo learns the tables, columns, and types available in a source so it can offer them up while you build. Historically, kicking off introspection could block the interface while it ran, which was annoying against large warehouses with many schemas.

In v1.0.79 schema introspection runs as a background job. You can keep working in the Explorer while the catalog populates, and the results stream in as they become available. For anyone pointing Visivo at a sizable Snowflake or Postgres instance, this removes one of the more common "why is the UI frozen" moments.

This also sets up cleaner behavior over time. Because introspection is now a discrete background job rather than an inline, synchronous step, it can be re-run, cached, and reasoned about independently of whatever you are doing in the foreground. That is the kind of plumbing change that does not demo well but makes everything downstream feel more solid.

Snowflake schema parsing in the Explorer

Visivo has supported Snowflake as a source for a long time. What v1.0.79 adds is first-class Snowflake schema parsing inside the Explorer, so the structure of your Snowflake databases is understood and presented the same way other sources are.

In practice this means that when you connect a Snowflake source, the Explorer reads its schemas, databases, and tables and makes them browsable and selectable while you author models. You do not have to remember exact identifiers or hand-type fully qualified names from memory. The Explorer knows what is there.

Combined with the background schema jobs above, this is a meaningful quality-of-life win for warehouse-centric teams. You connect Snowflake, introspection runs out of the way in the background, and the parsed schema shows up in the Explorer ready to build against. It is the same experience teams already had with DuckDB and Postgres, now extended to one of the most common cloud warehouses.

Every object type is now editable

The Explorer started as a place to inspect and preview. Over the 2.0 line it has been turning into a place to build. v1.0.79 closes a notable gap: every object type is now editable in the Explorer, not just the handful that were editable before.

Sources, models, metrics, dimensions, relations, and insights are all part of the same project graph, and now you can edit each of them from the Explorer. That keeps the round trip tight. You see something off in a metric definition, you fix it where you are looking at it, and your change flows back into the same YAML you keep in Git. The Explorer is a faster surface for iteration, not a replacement for code: the files on disk remain the source of truth.

Here is the shape of the kind of project you are now editing end to end, expressed in the 2.0 semantic-layer and Insights model:

models:
  - name: orders
    sql: SELECT * FROM orders_table
    metrics:
      - name: total_revenue
        expression: "SUM(amount)"
        description: "Total revenue from all orders"
    dimensions:
      - name: order_month
        expression: "DATE_TRUNC('month', order_date)"
        description: "Month the order was placed"

relations:
  - name: orders_to_users
    join_type: inner
    condition: "${ref(orders).user_id} = ${ref(users).id}"
    is_default: true

insights:
  - name: revenue-by-month
    model: ${ref(orders)}
    props:
      type: scatter
      mode: lines+markers
      x: ?{ date_trunc('month', order_date) }
      y: ?{ sum(amount) }
    interactions:
      - split: ?{ region }
      - sort: ?{ date ASC }

Every object in that file is now a thing you can open, edit, and validate from the Explorer, with the query profile and Parquet-backed tables making the feedback fast.

What it unlocks

Step back and the through-line is clear. The semantic layer gave Visivo a shared, governed definition of metrics, dimensions, and relations. Relations gave it joins as a first-class part of the data model. v1.0.79 makes the surface where you exercise all of that fast and complete.

Parquet-backed tables keep big previews snappy. The query-profile panel tells you where time goes. Background schema jobs and Snowflake parsing remove the friction of connecting real warehouses. And full editability means the Explorer is now a genuine build loop rather than a read-only window. Put differently, this release is less about new capabilities and more about making the existing 2.0 model feel good to use at scale.

If you have not connected a warehouse to Visivo yet, the get started guide is the quickest path, and the examples gallery shows the kinds of dashboards the Explorer and semantic layer produce. For the conceptual backdrop on why local, columnar storage is the right foundation here, read on to the Parquet deep dive next.

Previously in Visivo

In the last release recap we shipped relations: introducing relations, joins as a data model. That post explains how Visivo treats joins as governed, reusable objects in your project graph, which is exactly the model the editable Explorer in v1.0.79 now lets you tune end to end. Read it for the data-modeling context behind everything in this release.