hugues31/duckpad

Worth a look if you already work in DuckDB and want lineage and Git review around your pipelines; wait if you need cross-platform SQL execution or a mature ecosystem.

The problem

You want to turn a pile of CSVs, database tables and intermediate queries into a pipeline whose output numbers you can defend. Today that often means a chain of SQL scripts, a notebook and a spreadsheet, where the step from a final revenue figure back to the row that produced it is manual detective work. Duckpad changes that step: sources, joins and reusable components become nodes, and clicking a result cell shows the contributing source values. The result is a pipeline you can inspect both as a diagram and as SQL.

What's different

The core mechanism is explicit lineage tied to the SQL execution, not a documentation layer bolted on afterwards. The README points to a lineage coverage document, which suggests the project treats lineage gaps as something to measure rather than promise universally. The practical benefit is targeted: when two people disagree about a number, the visual graph and cell-level trace give a starting point for the argument.

Authoring is dual-mode. Guided forms let you wire connections and joins without writing everything by hand, while an integrated editor accepts plain SQL when the forms get in the way. Versioning is also opinionated: projects save to Git, branch, compare visually and review merges before applying. That is familiar to engineers and creates real overhead for analysts who just want to save a file.

The main trade-off is confinement. SQL execution requires Linux with Landlock enabled, so the workspace is designed around a Linux deployment rather than a laptop-first experience on other operating systems. The visual compose, lineage and Git review features are also a specific workflow choice; teams that already have a strong dbt-style transformation process may find less to gain from the visual layer.

Who should try it

A good fit is a small data team on Linux that uses DuckDB for local or departmental analytics and wants one shared place to build pipelines, inspect lineage and version changes without assembling several tools. It also suits people who want to see the shape of a pipeline first and drop into SQL second.

A poor fit is a single analyst on macOS or Windows who mainly wants a fast local query client, or a team that needs SQL execution on the developer's laptop. The Linux requirement makes the first-run environment decision consequential. A team with an existing Git-based transformation workflow should check whether the visual merge review adds enough to justify adopting another workspace.

Requirements and limitations

You need Python 3.11+ and Git, and the package ships the interface, so Node.js is only for development. The harder constraint is SQL execution: it needs Linux with Landlock ABI 2+, which the README describes as Linux 5.19+ with Landlock enabled. Installing the package is easy; running real queries depends on that kernel-level facility being available. The installation and accounts guide and quickstart are the places to check before committing a team to it.

On the operational side, the first run creates an admin sign-in from the terminal, and team use means managing project access and per-environment connections, with single sign-on documented separately. Git-backed projects require the team to understand branching and merge review, not just SQL. Beyond that, the README is a feature overview; it does not document performance characteristics, dataset-size limits or connector breadth in detail. The project also does not describe support for running SQL on non-Linux systems, so treat that as an unresolved environment question rather than a portability promise.

HotRepo's take

The repository was 2 days old at the recorded snapshot and had appeared on the NEW-REPOSITORY board for TypeScript at #12, with 267 total stars, observed 2026-10-27. That is a single dated board appearance, not a daily growth series; persistence cannot yet be judged. Before investing, verify the Landlock/Linux requirement against your actual deployment environment and confirm the connector support you need in the connectors documentation.