motherduck-partner-delivery

Standardize multi-client MotherDuck architectures with per-client database isolation and provisioning checklists.

Updated Oct 15, 2019
One-click install
npx skills add https://github.com/kkkaoru/dotfiles --skill motherduck-partner-delivery-kkkaoru
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: motherduck-partner-delivery
Source: https://github.com/kkkaoru/dotfiles/tree/main/.agents/skills-stroage/motherduck-partner-delivery
Command: npx skills add https://github.com/kkkaoru/dotfiles --skill motherduck-partner-delivery-kkkaoru

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires duckdb, and includes references (resource) components.

What problem does it solve? Consultancies and implementation partners delivering MotherDuck across many clients need a repeatable architecture instead of reinventing isolation, provisioning, and regional deployment for every engagement. ## Core Features & Use Cases - Repeatable Delivery Pattern: Defines a default multi-client posture of one database namespace and one credential boundary per client, with explicit sharing and revocation paths. - Region-Aware Architecture: Makes region selection, residency constraints, and compliance-sensitive topics explicit parts of the delivery contract. - Runnable Validation Artifacts: Ships Python and TypeScript examples that provision per-client databases and run a validation pass across client environments. - Use Case: A partner onboarding retail and fintech clients uses the skill to standardize provisioning and validation while keeping each client's schema and metrics client-specific. ## Quick Start Ask the assistant to design a repeatable MotherDuck delivery architecture for multiple clients with per-client database isolation and a validation checklist.

Frequently Asked Questions about motherduck-partner-delivery

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a multi-client MotherDuck architecture?

Use structural isolation with one database namespace and one service account per client rather than query-time tenant filtering. Standardize the connection pattern, provisioning checklist, and sharing model while keeping schemas client-specific.

How do I provision a new client database in MotherDuck with Python?

Connect with duckdb using an md: connection string, then run CREATE DATABASE IF NOT EXISTS for a per-client name like customer_acme and create the standard tables inside it. The included artifact demonstrates this provisioning and validation flow.

When should I use MotherDuck shares versus Dives versus a full app?

Use shares when client teams query data directly, Dives when they want a live shareable visualization in the workspace, and a full customer-facing app pattern when they need embedded analytics or stricter tenant-facing UX guarantees.

Does MotherDuck support region-specific or residency-constrained deployments?

Region choice should be made explicit in the delivery contract, and current region availability must be verified against live MotherDuck documentation before committing. Residency, PrivateLink, and compliance topics are plan-sensitive and require live verification.

What are the limitations of a shared schema across MotherDuck clients?

A shared client schema is treated as a regression in this delivery model because industries differ in source systems, metrics, and data models. Standardize the architecture layer and design each client's schema separately.