Virtual Workshop: Build a Serverless Lakehouse with DuckLakeDecember 17, 10am PT / 1pm ET

Skip to main content

Building your First App with Customer-Facing Analytics

To build your first application with Customer-Facing Analytics (CFA) on MotherDuck, use this overview as a starting point.

You'll know you're done when:

  • Each of your customer tenants (or organizations) has its own service account and database(s) in MotherDuck.
  • Your application can query customer-specific analytics data with predictable performance and isolation.
  • You understand which detailed guide to follow next for implementation.

Use this overview to choose a tenancy model and learn the building blocks before the step-by-step 3-tier guide.

Customer Provisioning​

Every Duckling is an isolated bucket of compute. For Customer-Facing Analytics, this usually means:

  • Each customer tenant or organization has one service account dedicated to serving analytics (and often also ingestion and transformation).
  • Your backend mediates all access; customers typically do not log into MotherDuck directly.

You manage service accounts and tokens using:

With accounts and tokens in place, you can:

  • Create databases under each service account.
  • Load data into those databases via your orchestrator.
  • Use dedicated read tokens from your application to serve analytics.

For a concrete example of this pattern in a 3-tier web app, see the CFA Guide.

Data Modeling and Loading​

One database per customer tenant or organization scales cleanly because:

  • Each database is tied to a tenant's service account.
  • Each tenant's workloads are isolated from the others.
  • You can scale Duckling (compute instance) sizes independently based on tenant needs using different sizes (Pulse, Standard, etc).

You can also:

  • Use a single "landing" service account to ingest raw data from upstream systems.
  • Use ATTACH and zero-copy cloning to fan that data out into per-customer databases owned by their respective service accounts.

High-level patterns for data pipelines:

Check out the detailed Builder's Guide for instructions on loading data into per-customer MotherDuck databases and orchestrating customer-facing analytics pipelines.

Other Considerations​

Since MotherDuck Shares are read-only, in more real-time scenarios it may make sense to use:

This pattern can help enforce consistency between writer and reader databases that power your customer-facing dashboards.

For high-scale, high-concurrency applications, MotherDuck offers Read Scaling Replicas for applications that send hundreds or thousands of queries in a few seconds, such as BI tools or busy embedded dashboards. Read replicas:

  • Can be created and modified in the UI.
  • Can be managed via the MotherDuck REST API.
  • Follow the same consistency considerations as Shares, and can be checkpointed and refreshed more frequently if needed.

When you're ready to implement a full 3-tier architecture with per-customer service accounts, scheduled data loading, and a backend API, continue to the Customer-Facing Analytics Guide.