Customer-Facing Analytics Overview

Customer-Facing Analytics (CFA) has requirements that traditional data architectures rarely meet. CFA demands sub-second response times, per-customer isolation, and integration with operational applications while serving many concurrent end users.

MotherDuck addresses these needs through two architectural capabilities:

• Per-user tenancy model: Each customer gets their own dedicated DuckDB instance (Duckling), providing full compute isolation (so no resource contention between users), predictable performance, and the ability to scale resources independently based on individual customer needs.

• Dual execution: Enabled by DuckDB's lightweight architecture, queries can run both in the cloud and directly in the client's browser via WebAssembly, delivering near-instantaneous data exploration and filtering.

This guide explains how MotherDuck's architecture addresses the core CFA challenges and provides implementation patterns you can ship.

What is Customer-Facing Analytics?

Customer-Facing Analytics (CFA) embeds analytics directly into operational applications for external users—customers, partners, or end-users—rather than internal stakeholders. Traditional BI targets internal teams, runs on batch-processed data models, serves a small number of users, and tolerates higher-latency queries.

Dimension	Traditional BI	Customer-Facing Analytics
Audience	Internal (analysts, executives)	External (customers, partners)
Delivery	BI tools (Tableau, Looker)	Embedded in application
Latency	Seconds to minutes acceptable	Milliseconds to low seconds required
Scale	Dozens to hundreds of users	Thousands to millions of users
Isolation	Shared warehouse	Per-customer isolation needed
Tech Stack	Python, BI tools	JavaScript, embedded SDKs

info

What about AI-driven analytics? AI-driven analytics enables natural language interactions with data, allowing users to ask conversational questions like "What were our top-selling products last quarter?" and get immediate answers. MotherDuck's per-user tenancy and dual execution make it well-suited for building AI-driven analytics solutions. Learn how to build analytics agents with MotherDuck.

The CFA Challenge

Building customer-facing analytics systems presents three core challenges:

Challenge 1: Technology Stack Mismatch

For many applications, the data sits in a transactional database (OLTP database) like Postgres or MySQL. Engineers building CFA features often run analytical queries directly in a multi-tenant transactional database, which works until it fails at scale. Row-based storage and transactional databases are not designed for efficient analytical querying.

Operational applications often live in JavaScript/TypeScript, but traditional data tools are Python-centric. Operational teams work with OLTP databases built for transactions, while data teams use OLAP systems tuned for analytics but with their own challenges. Analytical workloads spike with user activity, while transactional loads need steady compute.

Challenge 2: Latency Requirements

Users expect sub-second response times—typical for OLTP systems. Anything slower degrades the application experience. Distributed OLAP systems (BigQuery, Snowflake, Databricks) often have cold starts and coordination overhead that keep them above those targets, even for small datasets.

Teams often add caching layers or refresh pipelines between OLTP and OLAP. That adds complexity, introduces another failure point, and delays data freshness.

Challenge 3: Multi-Tenancy at Scale

Switching to an analytics engine is the first step. Many legacy OLAP engines were designed for internal analytics and are provisioned as a single instance or cluster for all customer data, leading to downstream complexities:

• Overprovisioning: Resources sized for peak load sit idle most of the time
• Noisy neighbors: Large customer impacts small customers
• Resource contention: Concurrency limits affect everyone
• Unpredictable performance: Query times vary based on load
• Security concerns: All customer data in one shared system

Why MotherDuck for Customer-Facing Analytics?

MotherDuck's architecture aligns with the requirements of Customer-Facing Analytics. Two architectural advantages set it apart:

1. Per-User Tenancy Model

MotherDuck provisions a Duckling (DuckDB instance) for each customer (or even for each customer's users). This per-user tenancy model isolates customer data and delivers consistent DuckDB performance to each user.

Why single-node beats distributed compute clusters for CFA

Traditional data warehouses use distributed computing with coordination overhead, data shuffling, and network latency. Even a fast query typically takes a second or more because of this overhead.

DuckDB and MotherDuck use single-node, optimized columnar execution:

• Zero network hops
• Zero coordination overhead
• Optimized vectorized execution

For CFA workloads that query one customer's data at a time, single-node execution is usually faster than distributed, and MotherDuck can reach subsecond performance.

Scaling Analytics Up and Out

Each customer (and possibly each of their users) has their own MotherDuck Duckling (DuckDB instance). One account could run hundreds or thousands of Ducklings at a time, or none. This serverless model underpins MotherDuck's advantage versus other engines.

MotherDuck's cold start time is ~1 second, and per-second billing (1-second minimum) keeps individual queries cost-efficient.

note

While MotherDuck supports provisioning one Duckling per user, start simpler. Begin with a single Duckling and introduce per-user isolation and dedicated read scaling tokens as your user base grows beyond 100 users or when tighter performance guarantees are needed.

This isolated Duckling approach with vertical scaling delivers:

• Perfect isolation: No noisy neighbors
• Predictable performance: Dedicated resources per customer
• Cost-effective: Pay only for what each customer needs
• Easy scaling: Vertically scale individual ducklings as needed

Scale vertically by upgrading (or downgrading) the Duckling size your application uses for each customer, giving more power to higher-priority customers. If you need more compute or higher concurrency, launch read scaling Ducklings for compute-hungry customers.

MotherDuck offers several Duckling sizes for larger workloads.

For programmatic changes to user settings, refer to our API docs.

2. Dual Execution for Zero-Latency Exploration

As you build Customer-Facing Analytics into your product, you need sub-second response times so customers can explore their data quickly. Distributed data warehouses rarely meet that bar.

Because MotherDuck is built on DuckDB, you can connect from any DuckDB client. DuckDB is an in-process database, so it can run on your server (3-tier) or directly in the client's browser through WebAssembly (1.5-tier).

This enables "dual execution": combining local data and compute with cloud data and compute in a single query, giving you flexibility to optimize for performance and cost.

Traditional approach has multiple network hops:

DuckDB-Wasm enables client-side execution:

Because the same DuckDB SQL engine runs on both MotherDuck Ducklings and on your customers' machines, you can offload data processing to their laptops and provide fast data exploration, filtering, and sorting using SQL. Customers do not need to install anything because DuckDB runs inside the web browser using WebAssembly (Wasm).

You can see this experience in Column Explorer and Instant SQL in the MotherDuck UI. Here's a teaser of it in action:

Implementation Patterns

MotherDuck enables two distinct architectural patterns for customer-facing analytics:

3-Tier Architecture

Best for: Applications requiring server-side authorization, business logic, or deployments to stateful platforms.

Typical web application architecture:

Key Benefits:

• Persistent database connection (connection pooling saves ~200ms per request)
• Fast query performance (~50-100ms)
• Server-side security and authorization
• Works with any DuckDB client (Node.js, Python, Go, Rust, Java)

Performance optimizations:

1. Intermediate table results: Pre-aggregate data on MotherDuck for faster queries
2. Prefer one well-structured SQL statement that returns all needed metrics (using SELECT with multiple aggregates, CASE/FILTER, or UNION ALL).
3. For multi-step workflows, wrap statements in a BEGIN … COMMIT transaction to ensure atomicity.
4. For data movement, use bulk operations (COPY, INSERT … SELECT) instead of many row-by-row calls.
5. Application Caching: Cache rarely-changing data on your server to avoid any extra queries on MotherDuck

When to use:

• You need server-side authorization and business logic
• You want a traditional, battle-tested architecture
• You're deploying to stateful services (Cloud Run, ECS, Kubernetes)
• Your team works with multiple languages

WANT TO GET STARTED? JUMP TO THE [BUILDER'S GUIDE]

1.5-Tier Architecture (DuckDB-Wasm)

Best for: Read-heavy dashboards with <1GB data per user where you need maximum performance.

Architecture:

Key Benefits:

• Sub-10ms query latency (queries run locally in browser)
• Near-zero server costs (just data transfer)
• Offline support after initial data load
• Infinite scalability (users provide compute)

Performance optimizations:

1. Optimize Initial Load: Use Parquet compression, limit to <50MB
2. IndexedDB Persistence: Data survives page reloads
3. Incremental Sync: Only fetch new data since last sync

When to use:

• Read-heavy dashboards with frequent filtering/drilling
• Want <10ms query latency
• Data per user is <1GB
• Want to minimize server costs

info

WebAssembly applications using multi-threading (including DuckDB-Wasm) require cross-origin isolation. This means your page must be served with specific headers (Cross-Origin-Embedder-Policy: require-corp and Cross-Origin-Opener-Policy: same-origin), and resources from different origins must include a Cross-Origin-Resource-Policy: cross-origin header.

If you're building a new application, a dedicated page is easier to manage within these constraints. If you have existing dependencies (iframes, third-party scripts, etc.) and need to integrate analytics into an existing page, the 3-tier architecture is recommended.

Hands-on Example

See our 1.5-tier architecture example demonstrating best practices for building a 1.5-tier analytics application using TypeScript, React and the MotherDuck Wasm SDK.

3-Tier vs 1.5-Tier

Factor	3-Tier	1.5-Tier (DuckDB-Wasm)
Query latency	~50-100ms	~5-20ms ⚡
Server cost	$$ (per request)	$ (data transfer only)
Scalability	High (auto-scaling)	♾️ Unlimited
Data per user	Any size	<1GB optimal
Offline support	❌ No	✅ Yes
Server-side logic	✅ Yes	❌ Limited
Best for	Complex logic, auth	Read-heavy dashboards

Next Steps

1. Sign up for MotherDuck: motherduck.com
2. Follow the hands-on Builder's Guide.

Additional Resources

• Building Analytics Agents with MotherDuck
• Read Scaling Ducklings
• Ducklinig Sizes