Hypertenancy

MotherDuck implements a unique tenancy model called hypertenancy: every user or service account gets their own dedicated DuckDB compute instance, called a Duckling. Unlike traditional data warehouses where all users share a single cluster, hypertenancy provides full compute isolation at the individual user level.

The Problem with Traditional Multi-Tenancy

Traditional data warehouses and OLAP systems use a shared-compute model:

This shared model creates several challenges:

• Noisy neighbors: One user's expensive query affects everyone else's performance
• Resource contention: Concurrency limits apply across all users
• Unpredictable performance: Query times vary based on overall system load
• Overprovisioning: Resources must be sized for peak aggregate load, sitting idle most of the time
• Difficult cost attribution: Hard to track compute costs per user or customer

How Hypertenancy Works

With hypertenancy, MotherDuck provisions a separate Duckling for each user:

Each Duckling is a complete DuckDB instance with dedicated CPU, memory, and fast SSD spill space. This architecture delivers:

• Perfect isolation: No noisy neighbors—one user's workload never impacts another
• Predictable performance: Dedicated resources mean consistent query times
• Independent scaling: Each user's compute can be sized to their specific needs
• Per-user billing: Compute costs directly attributable to individual users
• Fast cold starts: Ducklings start in approximately 1 second

Scaling with Hypertenancy

Hypertenancy supports both vertical and horizontal scaling, letting you match compute resources to actual demand.

Vertical Scaling: Duckling Sizes

Each user's Duckling can be configured to different sizes based on their workload requirements:

Duckling Size	Best For
Pulse	Ad-hoc queries, read-heavy workloads, high-concurrency analytics
Standard	Core analytical workflows, ETL/ELT pipelines
Jumbo	Large-scale batch processing, complex joins
Mega	Demanding jobs with high data volumes
Giga	Largest and toughest batch workloads

You can adjust Duckling size per user through the MotherDuck UI or REST API.

For example, in a customer-facing analytics scenario, you might provision:

• Pulse Ducklings for most customers running standard dashboards
• Standard or Jumbo Ducklings for enterprise customers with heavier workloads
• Mega or Giga Ducklings for batch data loading jobs

Horizontal Scaling: Read Scaling

When a single user needs to handle many concurrent queries—such as a service account powering a customer-facing application—you can enable read scaling. Read scaling provisions additional read-only Ducklings that share the same data but distribute query load:

Read scaling lets you serve hundreds or thousands of concurrent end users through a single service account while maintaining predictable performance.

Hypertenancy Use Cases

Customer-Facing Analytics

Hypertenancy is particularly powerful for customer-facing analytics. Each of your customers can have their own service account with isolated Ducklings:

• Data isolation: Each customer's data stays in their own database
• Compute isolation: One customer's workload never impacts another
• Cache isolation: Each customer's Duckling maintains its own cache, so cached query results and data remain private and predictable
• Independent sizing: Scale resources per customer based on their tier or needs
• Predictable costs: Bill customers accurately based on their actual compute usage

For a hands-on guide to building customer-facing analytics with per-customer service accounts, see the Builder's Guide.

Development and Production Pipelines

Service accounts enable clean separation between deployment environments. Each environment gets its own isolated compute:

Environment	Service Account	Duckling Size	Purpose
Local/Dev	dev-pipeline	Pulse	Interactive development and testing
Staging	staging-pipeline	Standard	Pre-production validation
Production	prod-pipeline	Standard/Jumbo/...	Production workloads

This separation ensures:

• Development experiments never impact production performance
• Each environment has appropriately sized compute
• Clear cost attribution per environment
• Easy rollback by switching service account credentials

Data Warehouse & Data Pipeline Workloads

For data pipelines, you can assign dedicated service accounts to different stages of your data workflow. If you're using dbt you can run dbt models with different duckling sizes.

Pipeline Stage	Service Account	Duckling Size	Workload Pattern
Ingestion	ingest-service	Jumbo/Mega	Bulk data loading, high I/O
Transformation	transform-service-standard / transform-service-jumbo /	Standard/Jumbo	dbt models, ETL jobs
Reporting	reporting-service	Pulse (read scaling)	Dashboard queries, read-heavy

This pattern provides:

• Workload isolation: Heavy batch ingestion jobs won't slow down interactive reporting queries
• Right-sized compute: Each stage gets the Duckling size optimized for its workload
• Cost visibility: Track compute costs per pipeline stage
• Independent scheduling: Run ingestion during off-peak hours without affecting daytime analysts

Analytics & Data Science

For internal analytics teams, hypertenancy means analysts and data scientists each get their own compute. A data scientist running a complex ML feature extraction job won't slow down an analyst building a quick dashboard.

Why Single-Node Beats Distributed for Per-User Compute

Traditional distributed data warehouses use clusters with multiple nodes that coordinate to execute queries. This architecture introduces:

• Network latency between nodes
• Coordination overhead
• Data shuffling costs

For queries that operate on one user's data at a time (the common pattern in hypertenancy), single-node execution on a Duckling eliminates this overhead entirely. The result is often faster query performance and lower costs compared to distributed systems, especially for interactive analytics workloads.

DuckDB's efficient columnar execution, combined with MotherDuck's fast storage architecture, means queries can handle datasets larger than memory with minimal performance impact.

Related Content

• Learn about Duckling sizes: Duckling Sizes
• Configure read scaling: Read Scaling
• Build customer-facing analytics: Customer-Facing Analytics Overview
• Set up per-customer service accounts: Service Accounts Guide