Use case
I want to use a Quack server as the single process that attaches a DuckLake and
owns the object-store credentials, so that thin Quack clients can read/write the
lake without ever attaching DuckLake themselves and without holding storage
credentials. This is the "lakehouse pod" pattern described in DuckDB's own
direction for Quack + DuckLake.
Topology:
- Server: attaches a DuckLake (with
DATA_PATH + cloud credentials) and serves it over Quack.
- Client: plain
ATTACH 'quack:host' AS remote — no ducklake extension, no storage credentials.
What happens
Because the server has the lake attached as its own catalog, reaching a table
from the client requires a 4-part name (remote.<lake>.<schema>.<table>),
which the binder rejects:
-- SERVER
INSTALL ducklake; LOAD ducklake;
INSTALL quack; LOAD quack;
ATTACH 'catalog.duckdb' AS lake (TYPE DUCKLAKE, DATA_PATH 's3://bucket/lake');
CALL quack_serve('quack:localhost', token => 'asdf');
-- CLIENT (no ducklake extension, no storage creds)
INSTALL quack; LOAD quack;
CREATE SECRET (TYPE quack, TOKEN 'asdf');
ATTACH 'quack:localhost' AS remote;
FROM remote.lake.silver.accounts;
-- Parser Error: NameListToString NOT IMPLEMENTED (4 parts)Workaround (works, but insufficient)
FROM quack_query_by_name(remote, 'FROM lake.silver.accounts'); -- OK
The macro path works for hand-written reads, but it isn't usable by tools that emit standard catalog.schema.table SQL (e.g. SQLMesh), so the credential-free client concept doesn't work.
Request
Either of these would unblock the pattern:
(Preferred, Quack-side) Let a client pin a specific remote catalog as the attach root, so the server's attached DuckLake appears as a normal 3-level catalog on the client, e.g.:
ATTACH 'quack:host' AS lake (REMOTE_CATALOG 'lake');
FROM lake.silver.accounts; -- 3 levels, binds fine
(General, core-side) Support nested/N-level qualified names so remote.lake.silver.accounts resolves.
Use case
I want to use a Quack server as the single process that attaches a DuckLake and
owns the object-store credentials, so that thin Quack clients can read/write the
lake without ever attaching DuckLake themselves and without holding storage
credentials. This is the "lakehouse pod" pattern described in DuckDB's own
direction for Quack + DuckLake.
Topology:
DATA_PATH+ cloud credentials) and serves it over Quack.ATTACH 'quack:host' AS remote— noducklakeextension, no storage credentials.What happens
Because the server has the lake attached as its own catalog, reaching a table
from the client requires a 4-part name (
remote.<lake>.<schema>.<table>),which the binder rejects:
Workaround (works, but insufficient)
The macro path works for hand-written reads, but it isn't usable by tools that emit standard catalog.schema.table SQL (e.g. SQLMesh), so the credential-free client concept doesn't work.
Request
Either of these would unblock the pattern:
(Preferred, Quack-side) Let a client pin a specific remote catalog as the attach root, so the server's attached DuckLake appears as a normal 3-level catalog on the client, e.g.:
(General, core-side) Support nested/N-level qualified names so remote.lake.silver.accounts resolves.