Motherduck Ducklake

---
name: motherduck-ducklake
description: Decide when DuckLake is the right MotherDuck storage pattern versus native MotherDuck storage (the default). Use when evaluating lakehouse or open table format storage, Iceberg-style requirements, fully managed DuckLake, BYOB buckets, own-compute DuckLake access, data inlining, time travel, object-storage layout, or file-aware compaction and maintenance.
license: MIT
---

# Use DuckLake on MotherDuck

Use this skill when the storage decision is genuinely about open table format and object-store behavior, not just about where to put another analytical table.

## Source Of Truth

- Prefer current MotherDuck DuckLake docs first.
- Use the upstream DuckLake and DuckDB extension docs only to clarify extension-level behavior that MotherDuck docs reference.
- Keep the guidance aligned with the documented product posture:
  - native MotherDuck first
  - upstream DuckLake v1.0 is production-ready, but MotherDuck's DuckLake docs define the MotherDuck product surface and preview/compatibility limits; verify the current DuckDB/DuckLake version matrix instead of assuming a pinned version
  - fully managed, BYOB, and own-compute paths are distinct
  - maintenance and compaction are explicit operations, not background magic

## Default Posture

- Start with native MotherDuck storage unless there is a concrete DuckLake requirement.
- Reach for DuckLake when you need open-table-format semantics, object storage as the source of truth, BYOB, or file-aware maintenance.
- Do not recommend DuckLake just because a workload is "large"; MotherDuck's docs explicitly note native storage is often faster for reads.