Quack server as shared DuckLake catalog in a multi-tenant SaaS environment — is this the right pattern?

[sachin090375]

We are evaluating the quack server as a DuckLake catalog backend for a multi-tenant environment and have run into several architectural concerns. Looking for community guidance on whether this is the intended use case and how others have approached it.

Setup:

Single quack server instance with one quack_catalog.duckdb file
Multiple tenants each with their own S3 bucket and DuckLake, all sharing the same quack catalog
Tenants connect via ATTACH 'ducklake:quack:host:port' AS tenant (DATA_PATH 's3://tenant/', OVERRIDE_DATA_PATH TRUE)
Concerns:

1. Schema namespace collision
   Since all tenants share a single catalog, schema names must be globally unique. We cannot give each tenant a clean main schema — the tenant identity has to be encoded into the schema name. Is there a way to achieve per-tenant schema isolation within a shared quack catalog?

2. WAL recovery behaviour
   On ungraceful shutdown, an orphan .wal file prevents the server from restarting. Deleting the WAL allows restart but discards uncommitted writes rather than replaying them. Is this expected? Is there a safer recovery path?

3. Reverse proxy compatibility
   Is the quack protocol designed to work through a standard HTTPS reverse proxy, or does it require direct TCP access?

4. Intended use case
   Is a single shared quack catalog the recommended pattern for multi-tenant environments, or is quack server intended for single-tenant/single-machine deployments? Would a per-tenant ducklake:postgres: catalog be more appropriate at scale?

Thanks