Spreadsheet UI Backed by Git

This points to dbt trying to make software engineering controls disappear into familiar business tools. The important idea is not spreadsheets themselves, it is that version history, testing, reviews, and rollback can sit underneath any interface people already know. In practice, an analyst could edit a table-like model, while Git keeps the change log, approvals, and recovery path that make production data safe.

• dbt’s core move was to let SQL users work like software teams. Models live as code, changes go through version control and checks, and cloud products add an IDE, CI, scheduling, and hosted docs. A spreadsheet front end would keep the same control layer, but swap the editing surface to something more familiar to non technical users.
  1 sacra 2 sacra
• There is precedent for this pattern. Hex lets teams build notebook style analysis and export projects to a Git repo. Observable offers notebook collaboration with version history and also supports GitHub connected data apps. The common theme is a friendly interface on top, with reproducibility and change tracking underneath.
  3 hex 4 hex 5 observablehq
• Strategically, this is how dbt expands beyond analytics engineers. If business users can adjust logic in a spreadsheet like UI without losing governance, dbt can become the system where companies define metrics once and expose them through many surfaces, instead of forcing every user to learn Git or raw SQL.
  1 sacra 2 sacra

The next step is data tooling that feels like Sheets on the surface and like GitLab underneath. That shifts the market from selling a tool for data specialists to selling a control plane for every workflow where business logic changes, gets reviewed, and has to stay consistent across dashboards, apps, and AI agents.