Hi Motherduck team, I hit a performance characteristic on MotherDuck that I would like your read on.
On local DuckDB, COMMENT ON COLUMN costs about the same as a trivial statement: 0.056 ms vs 0.045 ms for SELECT 1, a ratio of 1.25x, on MotherDuck the relationship inverts: 49.0 ms vs 0.71 ms, a ratio of 69x.
Relative to local DuckDB, MotherDuck's penalty on SELECT 1 is 16x (which we read as ordinary network cost), but its penalty on COMMENT ON COLUMN is 879x. Catalog DDL is being penalised roughly 55x more than an ordinary statement, and I don't think network latency explains that.
Measurements: DuckDB 1.5.5, us-east-1, 20 statements per arm, arm order alternated, first two rounds discarded as session warmup.
COMMENT ON COLUMN SELECT 1 ratio
Local DuckDB (in-process) 0.056 ms 0.045 ms 1.25x
MotherDuck 49.0 ms 0.710 ms 69x
MotherDuck / local 879x 16x
Wrapping the comments in an explicit transaction helps, but only by about 24% (median 33 ms vs 47 ms per comment, 6 of 6 paired rounds favouring the transaction). It does not collapse to a single commit, 33 ms per comment inside one transaction is still 47x a SELECT 1. The same wrapper makes no measurable difference locally (0.055 vs 0.059 ms), which suggests what it saves is a per-statement remote commit rather than any DuckDB-side work.
DBT persist_docs feature writes one COMMENT ON COLUMN per documented column on every model build (this is dbt-core's design, not adapter-specific) and it's a known pain point in other adapters too. There is no multi-column COMMENT ON form and DuckDB has no inline COMMENT in CREATE/CTAS, so one statement per column is the only way to express it.
There is anything we can do to improve the COMMENT ON COLUMN performance?
.png){kind=logo}
