static by default. live when needed.

I wrote how the dashboards work on May 11 and pre-published it for May 12 with a lot of ideas about how I’d support remote data: I was using SQLite, Turso, Postgres, DataFusion, and more as I explored options. DuckDB Quack launched on May 12 and changed everything: I’m all-in on DuckDB, once again! I’m restarting with a small useful dashboard: metadata about this website itself, exposed as site analytics. I also redid website search off a .ddb instead of .db file.

The current path stays static:

flowchart TB
    sources["source layer<br/>content markdown + git history<br/>local/public sources"] --> data["bin/build-data"]

    data --> ddbAssets["static DuckDB assets<br/>site.ddb today<br/>future /data/other.ddb + /assets/foo.ddb"]
    data --> zorto["zorto build"]

    ddbAssets --> assets["static asset host<br/>HTML + one or many .ddb files"]
    zorto --> assets

    assets --> dashClick["dashboard click"]
    dashClick --> loader["tiny loader script"]
    loader --> wasm["DuckDB-Wasm"]
    assets -->|fetch + attach static .ddb files| wasm
    loader --> plotly["Plotly"]
    wasm --> sql["dashboard module SQL"]
    sql --> view["charts + tables"]

    quack["optional DuckDB + Quack surfaces<br/>localhost admin<br/>private network<br/>VPS / personal ops"] -.-> auth["TLS + authn/authz<br/>read-only policy"]
    auth -.->|controlled build ingest| data
    auth -.->|authenticated runtime attach/query| wasm

For public pages, the default is a checked-in .ddb file. That surface can be plural: one site database today, more static .ddb assets later. Quack is an optional input path: useful at build time, on a private network, or behind an authenticated runtime surface.

A dashboard (or really any application) is data plus frontend. Python is good for source pulls, transforms, validation, and local orchestration. The browser is still HTML, CSS, and JavaScript. Zorto should keep those layers separate:

  • build data locally
  • emit a DuckDB file
  • render static HTML
  • load analytical JavaScript only on demand

Here is that shape in miniature: click once, load the runtime, run SQL against site.ddb, draw a chart inline.

inline demo

query the post graph

idle

Quack adds another path, not a new default. It lets one DuckDB instance expose a remote protocol over HTTP so another DuckDB client can query it or attach it as a catalog. That is useful for private dashboards, local networks, admin tools, and build-time ingestion.

Do not put database credentials in a public static site. A Quack server exposes the SQL surface of the underlying DuckDB session, so anything beyond localhost needs a real boundary: TLS termination, authentication, and authorization policy.

Zorto can make that boring over time by leaning into existing standards instead of inventing a new dashboard server: HTTP(S), reverse proxies, tokens and secrets, read-only query policies, DuckDB attachments, and checked-in artifacts.

The dashboard model becomes:

  • checked-in .ddb for public static dashboards
  • build-time Quack reads for controlled sources
  • runtime Quack attachments only behind an authenticated surface
  • DuckLake when the data wants lakehouse-style partitioning instead of one DuckDB file

That makes Zorto less like a dashboard framework and more like a data-app compiler for websites, presentations, and local applications.