What problem does it solve? Building embedded analytics for external customers requires strict per-tenant data isolation, sub-second query latency, and high read concurrency, and choosing the wrong serving architecture can leak data across tenants or collapse under load. ## Core Features & Use Cases - Serving Architecture Selection: Chooses between a 3-tier app (browser to backend API to MotherDuck), embedded Dives, or DuckDB-Wasm based on isolation, latency, and security requirements. - Isolation and Connection Design: Defines per-customer databases, service-account boundaries, Read Scaling versus Read/Write token usage, and PG endpoint versus native DuckDB connection paths. - Runnable Routing Artifacts: Ships Python and TypeScript examples demonstrating per-customer database routing that can be validated against temporary MotherDuck databases. - Use Case: A SaaS team embedding dashboards into their product uses this Skill to produce an API contract, tenant isolation model, and rollout plan where each customer queries only their own MotherDuck database through a backend-held token. ## Quick Start Ask the assistant to design a customer-facing analytics architecture on MotherDuck for your product, specifying your expected tenant count and concurrency.
