DuckLake with PostgreSQL metadata store creates file with connection string as filename

[jghoman]

Summary

When using DuckLake with a PostgreSQL metadata store, the ducklake extension creates a file-backed internal metadata catalog (__ducklake_metadata_ducklake) using the raw postgres connection string as the file path. This writes a file to the working directory named after the connection string, which may include credentials.

Reproduction

1. Configure duckgres with a DuckLake PostgreSQL metadata store:

   ducklake:
     metadata_store: "postgres:host=localhost port=5433 user=ducklake password=ducklake dbname=ducklake"
     object_store: "s3://ducklake/"

2. Connect a client. Observe files created in CWD:

   'host=localhost port=5433 user=ducklake password=ducklake dbname=ducklake'
   'host=localhost port=5433 user=ducklake password=ducklake dbname=ducklake.wal'
   

3. Query confirms the internal metadata catalog uses the connection string as its path:

   SELECT database_name, path FROM duckdb_databases();

   database_name	path
   ducklake	host=localhost port=5433 user=ducklake password=ducklake dbname=ducklake
   __ducklake_metadata_ducklake	host=localhost port=5433 user=ducklake password=ducklake dbname=ducklake

Impact

• Credential exposure: If the connection string contains a password, it appears in the filename on disk.
• Unnecessary file I/O: When the main DuckDB is :memory:, the internal metadata catalog should also be in-memory. There's no reason to persist it to disk — it's just a local cache of the postgres-hosted metadata.

Attempted workarounds

• METADATA_CATALOG ':memory:' — changes the catalog name but the path (and file) remains the connection string.

Expected behavior

For PostgreSQL-backed metadata stores, __ducklake_metadata_ducklake should be in-memory, not file-backed.

Workaround for users

Source the password from an environment variable rather than including it inline in the connection string. This avoids credentials in the filename, though the file is still created.