Customer-Facing Analytics Guide

Customer-Facing Analytics (CFA) presents unique challenges that traditional data architectures struggle to solve. Unlike internal BI systems, CFA requires sub-second response times, per-customer data isolation, and seamless integration with operational applications - all while serving analytics to many parallel end users.

MotherDuck's architecture solves these challenges through two key innovations:

• 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 ultra-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 explores how MotherDuck's architecture addresses the core CFA challenges and provides pragmatic implementation patterns and production-ready recommendations.

What is Customer-Facing Analytics?

Customer-Facing Analytics (CFA) is the practice of embedding data analytics and visualizations directly into operational applications to serve external users—customers, partners, or end-users—rather than internal stakeholders. Business Intelligence (BI) is traditionally built for internal stakeholders—it runs on batch-processed data models, serves a small number of users, and tolerates high-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 architecture - with per-user tenancy and dual execution—makes it well-suited for building AI-driven analytics solutions. Learn how to build analytics agents with MotherDuck.

The CFA Challenge

Building effective customer-facing analytics systems presents three core challenges:

Challenge 1: Technology Stack Mismatch

For many types of 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 fine until things break down at scale. Row-based storage and transactional databases simply aren't designed for efficient analytical querying.

Your operational application often lives in JavaScript/TypeScript, but traditional data tools are Python-centric. Operational teams work with OLTP databases (Postgres, MySQL) designed for transactional workloads, while data teams use OLAP systems that excel at analytics but present their own challenges. Furthermore, analytical workloads tend to be very spiky (based on user activity) while transactional loads always need some base-level of compute at all times.

Challenge 2: Latency Requirements

Users expect sub-second response times — typical performance of OLTP systems. Anything slower degrades the application experience and feels sluggish compared to the rest of your app. Classic OLAP systems (BigQuery, Snowflake, Databricks), due to their distributed engine architecture and often long cold start times, can hardly achieve these response times, even for small datasets.

The common middle-ground solution is to add a caching layer or refresh pipelines between the two systems, which introduces additional complexity and another potential point of failure. It also adds latency between the data generation and data serving layer.

Challenge 3: Multi-Tenancy at Scale

Switching to a database and query engine designed for analytics is the first step. However, many legacy OLAP engines were designed with only the internal analytics/BI use case in mind. They are provisioned as a single instance (or cluster) for all customer data, leading to a series of downstream complexities and issues:

• 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 is designed for the unique requirements of Customer-Facing Analytics. Two key architectural advantages set it apart:

1. Per-User Tenancy Model

MotherDuck provisions a Duckling (DuckDB instance) for each of your customers (or even for each of your customers' users). This per-user tenancy model isolates customer data and provides the same great DuckDB-powered experience for each individual user.

Why single-node beats distributed compute cluster for CFA ?

Traditional data warehouses use distributed computing with coordination overhead, data shuffling, and network latency. Even a "fast" query typically takes a second minimum due to this overhead.

DuckDB and MotherDuck take a radically different approach with single-node, optimized columnar execution:

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

For CFA workloads where you're querying one customer's data at a time, single-node is almost always faster than distributed, and with MotherDuck you can reach subsecond performance.

Scaling Analytics Up and Out

Each of your customers (and possibly each of their users) has their own MotherDuck Duckling (DuckDB instance). This means that one account could run several hundred or thousands of Ducklings at a given time, or none at all. This type of serverless model is at the heart of MotherDuck's advantage versus other engines.

MotherDuck's cold start time is nearly instantaneous(~1 second), and with per-second billing (1-second minimum), each query becomes extremely cost-efficient.

note

While MotherDuck's architecture supports provisioning one Duckling per user, we recommend starting with a simpler approach. Begin with a single Duckling and only introduce per-user isolation and dedicated read scaling tokens as your user base grows beyond 100 users or when specific performance requirements emerge.

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

You can scale vertically by upgrading (or downgrading) the instance size your application uses for each customer, enabling you to provide more power for more important customers. This is likely all you need to scale your application for customers, but if you need even more compute or the ability to handle high concurrency, you can launch read scaling Ducklings for your compute-hungry customers.

MotherDuck has several instance sizes to scale up for even larger workloads.

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

2. Dual Execution for Zero-Latency Exploration

As you're building Customer-Facing Analytics into your product, you want to provide an experience that wows your customers. Legacy data warehouses rarely provide sub-second response times, making it difficult to enable your customers to quickly explore their data.

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

This enables "dual execution": seamlessly combining local data and compute with cloud data and compute in a single query, giving you the 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 some data processing to their laptops and provide instant data exploration, filtering, sorting, etc using SQL queries. Customers don't even need to install anything on their computers as DuckDB runs inside the web browser using Web Assembly (Wasm).

You can see examples of the experience enabled by this architecture by checking out 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, complex 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

1.5-Tier Architecture (DuckDB-Wasm)

Best for: Read-heavy dashboards with <1GB data per user, maximum performance requirements.

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 will be 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. Choose your architecture pattern based on your requirements
3. Clone the example that matches your chosen pattern
4. Follow the implementation guide for detailed setup

Additional Resources

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