Customer-Facing Analytics for SaaS | Embedded Analytics Guide

Challenge 1: Technology Stack Mismatch

Most SaaS applications are built with JavaScript/TypeScript. Traditional analytical databases weren't designed for this ecosystem—they require complex drivers, connection pooling, and infrastructure that doesn't fit modern web development patterns.

Challenge 2: Latency Requirements

Internal analysts tolerate slow dashboards. Customers don't. Every extra second of load time increases bounce rates and support tickets. You need fast query response times, not the multi-second latencies typical of distributed warehouses.

Challenge 3: Multi-Tenancy at Scale

Each customer must only see their own data. But shared infrastructure creates "noisy neighbor" problems—one customer's heavy query slows down everyone else. Traditional solutions require overprovisioning or complex query management.

Per-Customer Isolation with Ducklings

Each customer gets their own dedicated DuckDB instance called a Duckling. This provides:

• Full compute isolation — No noisy neighbor problems
• Independent scaling — Heavy users get more resources without affecting others
• Data separation — Each customer has their own database(s)

Ducklings have a cold start time of approximately one second. See pricing for billing details.

Two Architecture Patterns

MotherDuck supports two approaches depending on your latency and data size requirements:

3-Tier is the standard pattern: your app server authenticates users, queries MotherDuck, and returns results. Query latency is approximately 50-100ms.

1.5-Tier uses DuckDB-Wasm—a WebAssembly build of DuckDB that runs directly in the browser. After initial data load, queries execute locally at 5-20ms. Users can even explore data offline.

You can combine both: use 3-tier for complex queries and authentication, 1.5-tier for fast interactive exploration.

Read Scaling for High Concurrency

When you need to serve many concurrent users, MotherDuck's read scaling provisions additional Ducklings to distribute query volume. You don't manage load balancers or connection pools—MotherDuck handles it.

Pattern 1: Per-Customer Service Accounts

Each customer company gets:

• Their own MotherDuck service account
• Dedicated database(s) for their analytics data
• Isolated compute (Ducklings) for queries and data loading

This is the recommended pattern for strong isolation. Your app server authenticates users, looks up their read token, and executes queries against their specific database.

Pattern 2: Shared Database with Row-Level Filtering

For simpler setups or smaller tenants:

Copy code
motherduck://analytics_db
├── events (tenant_id, event_type, timestamp, ...)
├── metrics (tenant_id, metric_name, value, ...)

Filter every query by tenant_id and use single attach mode to restrict users to their designated database.

Pattern 3: Hybrid with Data Lake

Use MotherDuck to query data directly from S3 or GCS while keeping frequently-accessed data in managed storage for faster performance.