One of DuckLake's core value propositions is data ownership — including ownership of your own catalog. We'd like the ability to create and manage a DuckLake backed by our own compute and catalog infrastructure, while still being able to register and use it within MotherDuck when needed (e.g. for MotherDuck compute or sharing features).

Use case

We run internal pipelines on self-managed compute. Being able to define a self-hosted DuckLake catalog in MotherDuck would let us share those databases with non-technical users via MotherDuck's existing sharing features, without giving up ownership of the underlying data or catalog.

Pain point

When the catalog lives on a MotherDuck service account, any internal process using its own compute is subject to the 1-minute cooldown on Standard+ instances — creating a meaningful latency penalty just to access the catalog. Ideally, catalog access alone should only require a pulse instance. But if the service account hosting the catalog is also used for heavier workloads that require a larger instance, there's no way to right-size for catalog-only access, and every internal catalog read pays that cost.

Ask

Allow a self-managed DuckLake catalog to be registered in MotherDuck and used alongside MotherDuck compute/sharing

Or, decouple catalog instance sizing from workload instance sizing so catalog-only access can run on a pulse instance regardless of what else lives on that service account