Moeve’s Shared dbt Launcher: Standardising Execution Without Centralising Every Pipeline

What happened

In a case study published on 22 September 2026, Moeve described a central service for running dbt projects across several AWS data-lake accounts.

The service uses:

• AWS Step Functions to manage the run lifecycle;
• AWS Fargate to start an isolated dbt container;
• Amazon Athena to execute the transformations;
• DynamoDB to store project configuration;
• EventBridge to publish results for downstream processes.

The container assumes an IAM role in the target data-lake account, allowing processing to remain close to the domain-owned data.

This separates the decision to run a project from the mechanics of executing it. A project can still be started by a schedule, an upstream data event or an on-demand request.

Moeve reports that onboarding a new dbt project was reduced from days to approximately 15 minutes. This is a customer-reported result rather than an independently reproduced benchmark.

Why it matters

As dbt adoption grows across an organisation, individual projects can develop different approaches to:

• execution;
• parameters;
• container configuration;
• permissions;
• retries;
• monitoring;
• result publication.

This duplication makes new projects slower to establish and increases the operational burden on the platform team.

A shared execution service can provide common controls without requiring every project to be placed in one large central pipeline.

The trade-off is that the launcher becomes an important shared dependency. Its resilience, version management, capacity and recovery procedures must therefore be treated as production concerns.

Who it affects

Analytics engineers, data-platform teams, dbt users and organisations running transformations across multiple AWS accounts or data domains.

What to do next

Identify the execution logic currently repeated across dbt projects.

Define a small standard contract covering:

• project identifier;
• target environment;
• container version;
• runtime parameters;
• credentials;
• retry rules;
• test results;
• completion and failure events.

Pilot the approach using two projects owned by different teams.

Measure onboarding time, operational effort and consistency while testing failure isolation and launcher availability.

Signal Take

Standardisation does not require one giant pipeline. A narrow shared execution service can create consistency while preserving appropriate domain ownership.

Scope and limitations

This analysis interprets the linked AWS material. Recommendations are editorial judgement, not tested implementation instructions. No independent product benchmark or deployment test was performed.