Add Quack protocol support for remote DuckDB connections (beta)

[VahOkan]

Summary

Adds native support for connecting dbt-duckdb to remote DuckDB servers via the Quack protocol (DuckDB v1.5.2+, beta).

• New QuackEnvironment — local in-memory DuckDB driver that ATTACHes the remote server and routes all SQL via USE
• Supported materializations: table, view, seed, incremental (append strategy only)
• Clear error gating for unsupported operations (DELETE/MERGE/ALTER RENAME) — no workarounds that would become dead code once Quack adds full DML support
• Macro adaptations for Quack beta limitations: sqlite_master for relation listing, unqualified schema names, skip DROP SCHEMA
• DuckLake-aware: partitioned_by and persist_docs work correctly when Quack targets a DuckLake catalog
• README documentation for configuration and known limitations

Configuration

default:
  outputs:
    dev:
      type: duckdb
      path: "quack:myhost:9494"
      database: quack_duckdb
      quack_token: "{{ env_var('QUACK_TOKEN') }}"
      quack_disable_ssl: false
  target: dev

Current known beta limitations (handled with errors, not workarounds)

• DELETE, UPDATE, MERGE — not yet supported by the Quack catalog proxy
• ALTER TABLE ... RENAME — not supported
• DROP SCHEMA — skipped with warning
• information_schema.tables — empty for remote tables (uses sqlite_master instead)
• duckdb_databases() — not implemented

These are Quack extension implementation gaps, not fundamental limitations. When Quack adds DML support, the gating can simply be removed and all incremental strategies will work.

[jwills]

Hey @VahOkan — thanks for the work here, Quack support is definitely something we want to add.

My hesitation is timing: Quack shipped a week ago and is targeting v2.0 stability in ~September. The bulk of this PR (the macro branches in table.sql, incremental.sql, view.sql, the sqlite_master workaround, the strategy gating) exists purely to paper over beta limitations that should be gone by then. I'd rather not carry ~600 lines of workarounds for 4 months and then delete them.

There are also a few design issues worth fixing in what would remain — the hasattr(..., "_quack_uri") type check in relation.py, the temporary creds.path mutation in _initialize_quack_db, and list_relations_without_caching missing a WHERE clause on sqlite_master.

Would you be up for revisiting this against v2.0? The permanent core (the QuackEnvironment connection setup, credential fields, render() override) is solid — it just deserves a cleaner landing once the beta dust settles.

[VahOkan]

Hey @VahOkan — thanks for the work here, Quack support is definitely something we want to add.

My hesitation is timing: Quack shipped a week ago and is targeting v2.0 stability in ~September. The bulk of this PR (the macro branches in table.sql, incremental.sql, view.sql, the sqlite_master workaround, the strategy gating) exists purely to paper over beta limitations that should be gone by then. I'd rather not carry ~600 lines of workarounds for 4 months and then delete them.

There are also a few design issues worth fixing in what would remain — the hasattr(..., "_quack_uri") type check in relation.py, the temporary creds.path mutation in _initialize_quack_db, and list_relations_without_caching missing a WHERE clause on sqlite_master.

Would you be up for revisiting this against v2.0? The permanent core (the QuackEnvironment connection setup, credential fields, render() override) is solid — it just deserves a cleaner landing once the beta dust settles.

@jwills I was also unaware of the limitations. I realized them after the tests. So, yes, I agree about the timing and the workarounds.

However, I was unsure if the limitations were solely due to the fact that it’s a beta version or if they will indeed take a long time to resolve in the future. If you have more insights or information about this, I’d be happy to freeze this PR.

[jwills]

@VahOkan yeah, not clear to me either. What would be interesting to me would be a BuenaVista-esque environment that didn't actually require a local DuckDB package to be installed to work-- like, a quack-protocol only version of this that didn't actually have DuckDB in the deps would be interesting and kind of cool