Duckle's workspace version says 0.0.1 while its releases say v0.7.4

The workspace version is 0.0.1 and the tags are at v0.7.4

The workspace manifest pins every crate to the same placeholder version:

[workspace.package]
version = "0.0.1"
edition = "2021"
license = "MIT OR Apache-2.0"
rust-version = "1.80"

The same `version = "0.0.1"` string repeats in all twelve internal path dependencies under workspace.dependencies, from duckle-runtime to duckle-secrets. Meanwhile the release history runs v0.7.2 on 2026-09-07, v0.7.3 on 2026-09-16 and v0.7.4 on 2026-09-25, and the last push to main landed on 2026-10-01. Nothing in the manifest reflects those tags, so the build has no single place that records which release it corresponds to. Rust 1.80 is the declared floor, on edition 2021 with resolver 2.

Three licence signals and two licence files

The repository root holds LICENSE-APACHE and LICENSE-MIT side by side. The manifest declares `license = "MIT OR Apache-2.0"`, which is the usual dual-licence expression. The platform record for this repository reports Apache-2.0 on its own.

That is three answers to one question, and they do not agree. Anyone building a compliance checklist has to decide which of the three sources governs, and the files themselves would have to be read to settle it. Nothing in the workspace section says which crate uses which licence, and the eighteen members do not carry individual licence fields in what the manifest shows.

The manifest also stops partway through, in the middle of the errors section, on an unfinished key name beginning with `thise`. So the workspace table above is complete, and whatever follows it is not readable from here.

The component count is 350 in one description and 400 in another

The repository's own one line description advertises 350+ components and 160+ connectors. The README says 400+ components, twice: once in the numbered list of what sets the project apart, and again as a row in the comparison table, where the same row adds that each component is covered by tests.

The connector count never appears in the README text. Neither does the CDC or data quality wording from the description, though the table of contents reserves sections for Sources, Sinks, Data quality and a capabilities matrix.

So the two descriptions of the same project disagree by at least fifty components, and the README drops the more specific of the two numbers entirely. Anyone writing a requirements list against this tool should count the connectors directly in the capabilities matrix rather than trusting either figure.

The 39.9 second figure names a row count and no machine

One performance number carries the pitch: 96 million rows out of Postgres to Parquet in 39.9s. It appears once, in bold, in the opening paragraph, with no footnote and no link.

The README gives no processor, no memory, no Postgres version, no Parquet settings and no dataset description for that run. Beside it sits a scaling claim: execution uses every core given to the box, so a bigger instance is a faster pipeline. That is linear scaling asserted without a second data point at a different core count.

A benchmarks directory does exist at the repository root, so the method may well be written down somewhere in the tree. It is not in the README, which is where a reader deciding whether to trust the figure will look first.

Self-contained until the first launch, which fetches an engine

The binary is sold twice on the same numbers. One passage calls it a self-contained binary you can audit, 73 to 110 MB depending on your platform. A table row repeats the range and adds the catch: single-file binary, no bundled DB, DuckDB downloads on first launch with a guided step.

Those two claims are reconcilable but not interchangeable. The thing you download is one file; the thing you run needs a second download before it works. A first launch on an isolated machine therefore fails, and the same applies to the runner when it is deployed headless on a schedule. AI engine is opt-in per the table, which is a separate flag from the engine download.

The stated size range is also a 37 MB spread across platforms, which is what you would expect from bundling the headless runner and the MCP server into each build.

Eighteen crates and four engine backends behind one DuckDB story

The workspace has eighteen members: apps/desktop plus sixteen crates under crates/, covering the runtime, connectors, workflow engine, transform engine, stream engine, scheduler, metadata, secrets, plugin SDK and execution core, and the packaging targets.

Four of those crates are engines: duckdb-engine, slothdb-engine, duckle-gpu and duckle-lance. The README's framing is narrower, describing a single-engine alternative to hosted per-row platforms, and saying the canvas compiles the graph to SQL and executes it on a real columnar engine, with DuckDB named as that engine. The Rust tree is broader than that sentence.

The rest of the repository is equally wide: frontend, apps, branding, marketing, website, packaging, docs, samples, scripts, plus both .github and .gitlab-ci.yml, a Dockerfile.web and two compose files, one of them for Coolify. rust-toolchain.toml and the build.cmd, dev.cmd and dev.ps1 scripts cover the Windows path.

Duckie runs in-process by default on a server meant to run headless

The bundled assistant, Duckie, is described as shipping in the box: describe a pipeline in English and it writes the JSON and drops it onto the canvas. It runs wherever Duckle does, with no API key, no telemetry and no vendor round trip, and it can be pointed at your own OpenAI-compatible endpoint instead of running in process.

The default and the deployment story pull in opposite directions. The same README section that introduces headless scheduling on a server also says the assistant runs in process by default, and the table calls the AI engine opt in. So the server-side deployment has an agent-shaped component that can execute inside the runner process unless you redirect it.

The rest of the positioning is about ownership: every pipeline is one file in git, workspaces are plain files in a folder you choose, and the project states it is independent of DuckDB Labs and MotherDuck while building on the DuckDB engine.

Editorial conclusion

Duckle is a credible choice for a single machine or small team that wants pipelines as plain files in git and no per-row billing, and its own scope note is honest about not replacing a distributed warehouse. Before you commit, resolve three things the repository leaves open. The workspace version is 0.0.1 while tags are at v0.7.4, so nothing in the build records the release number. The licence is stated three different ways across the platform record, the manifest and the two files at the root. And the 39.9 second figure comes with no machine, no engine version and no dataset, so treat it as marketing until you reproduce it on your own hardware.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes