Describe what you need and your agent builds it — on an open framework that stays fast at millions of rows, without rerunning a script on every click.
Updated just now · 8.2M rows
Revenue
$4.82M
+12.4%
Active accounts
1,284
+3.1%
Churn
2.1%
-0.4%
How it compares
| Script-based apps | Notebook tools | BI products | Vuon Data Apps | |
|---|---|---|---|---|
| Heavy compute | In the browser / per rerun | Per-cell Python | Vendor engine | Server-side DuckDB, Python when it pays |
| Incremental reruns | Whole script | Re-run cells | Vendor-managed | Graph-aware — only affected nodes |
| Custom UI | Widget set | Limited | Constrained | High-performance visual components via the SDK |
| Source of truth | App script | Notebook | Vendor project | app.toml + SQL/Python in Git |
| Portable / self-host | Varies | Implicit app shape | Rarely | Files, containers, pluggable cache |
| Agent-generatable | Partial | Partial | No | Designed for it |
A serious data app has parameters, coordinated views, and enough data that browser-only execution becomes a product bug. Today you choose between tools that don’t scale and platforms you can’t own.
Every filter change re-executes the whole script top to bottom. Fine for a demo, painful the moment real data shows up.
UI, execution, cache policy, and data lineage get tangled in one file. Great for exploring, hard to trust as a product.
Operationally mature, but not a clean standard for parameterized, app-like workflows — or for an agent to generate from scratch.
Describe the app as files. When a parameter changes, the runtime re-executes only the affected part of the graph, reuses valid cached results, and returns exactly what to render.
[param.quarter]
type = "select"
options = ["FY25Q1", "FY25Q2"]
[node.revenue]
engine = "duckdb"
sql = """
SELECT region, SUM(amount) AS net
FROM warehouse.bookings
WHERE quarter = ${param.quarter}
GROUP BY region
"""
[viz.revenue_chart]
type = "bar"
data = "node.revenue"Filters, dates, and inputs produce values that flow into the graph.
Load from your warehouse through the open connector protocol.
Join, aggregate, and materialize — server-side, on a fast engine.
Forecasts, anomaly detection, and modeling where Python earns its cost.
Charts, tables, and custom components bind to materialized outputs.
The split between a DuckDB engine for tabular work and Python for what Python is good at is what keeps a generated app interactive as data grows — instead of rerunning a script for every interaction.
Heavy joins and aggregations run on DuckDB, not in the browser. The page renders; the runtime computes.
Change one filter and only the affected nodes recompute. Valid cached results are reused automatically.
Coordinate dozens of charts, tables, and stats against the same filter without pushing the browser past its limits.
Cache policy and result descriptors are first-class, so the UI can page or fetch data deliberately.
Built for agents
Most data tools assume a human clicking through a UI. This one is plain files with a clear execution model — exactly the shape an agent generates well and a reviewer can trust.
An app is app.toml plus SQL, Python, and UI components. A model can write the whole thing — no proprietary project format to reverse-engineer.
Definitions live in version control. Diff a change, review it, roll it back. The app is the source of truth, not a hosted database.
The runtime runs on your machine and in containers. No Postgres required locally — run state lives in memory, results in a pluggable cache.
“Build a churn dashboard for FY25 with a region filter and a forecast vs. actuals chart.”
We’re releasing the runtime that builds and runs data apps as open source — so the apps you build stay portable, inspectable, and yours. Register your interest to get the launch the moment it ships.
The data-app runtime
app.toml engine, planner, and cache
Connector protocol
load any warehouse as source nodes
Visualization SDK
provider, hooks, and high-performance components
CLI
v dev, build, preview, and check
See it on your data in a quick walkthrough — or get in line for early access and the open-source launch.