it seems to request too many resources:

2026-07-02 17:02:23 platform INFO APPLY Stage: BUILD — (workloadId=33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync)
2026-07-02 17:02:23 platform INFO APPLY Stage: CLAIM — (workloadId=33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync)
2026-07-02 17:02:23 platform INFO Claimed: true for workload 33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync via API in dataplane AUTO288e28ef-3ab6-4f21-8320-a8a6a5e1c6b1 (6da21b32-9c6d-4ab5-9f69-1654d4807217)
2026-07-02 17:02:23 platform INFO APPLY Stage: LOAD_SHED — (workloadId=33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync)
2026-07-02 17:02:23 platform INFO APPLY Stage: CHECK_STATUS — (workloadId=33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync)
2026-07-02 17:02:23 platform INFO No pod found running for workload 33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync
2026-07-02 17:02:23 platform INFO APPLY Stage: MUTEX — (workloadId=33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync)
2026-07-02 17:02:23 platform INFO Mutex key: 33191d40-281b-4d8a-b2c2-f72f425242a3 specified for workload: 33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync. Attempting to delete existing pods...
2026-07-02 17:02:23 platform INFO Mutex key: 33191d40-281b-4d8a-b2c2-f72f425242a3 specified for workload: 33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync found no existing pods. Continuing...
2026-07-02 17:02:23 platform INFO APPLY Stage: ARCHITECTURE — (workloadId=33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync)
2026-07-02 17:02:23 platform INFO APPLY Stage: LAUNCH — (workloadId=33191d40-281b-4d8a-b2c2-f72f425242a3_203810_0_sync)
2026-07-02 17:02:23 platform INFO [initContainer] image: airbyte/workload-init-container:1.8.5 resources: ResourceRequirements(claims=[], limits={memory=20Gi, cpu=1.5}, requests={memory=13Gi, cpu=1.0}, additionalProperties={})
2026-07-02 17:02:23 platform INFO Launching replication pod: replication-job-203810-attempt-0 (selectors = {}) with containers:
2026-07-02 17:02:23 platform INFO [source] image: airbyte/source-mysql:3.1.1 resources: ResourceRequirements(claims=[], limits={memory=20Gi, cpu=1.5}, requests={memory=13Gi, cpu=1.0}, additionalProperties={})
2026-07-02 17:02:23 platform INFO [destination] image: airbyte/destination-snowflake:3.15.4 resources: ResourceRequirements(claims=[], limits={memory=20Gi, cpu=1.5}, requests={memory=13Gi, cpu=1.0}, additionalProperties={})
2026-07-02 17:02:23 platform INFO [orchestrator] image: airbyte/container-orchestrator:1.8.5 resources: ResourceRequirements(claims=[], limits={memory=20Gi, cpu=1.5}, requests={memory=13Gi, cpu=1.0}, additionalProperties={})

Your logs show all containers (initContainer, source, destination, orchestrator) being assigned very high resource limits (

memory=20Gi, cpu=1.5

, requests

memory=13Gi, cpu=1.0

). This is a known issue where persisted actor-specific resource requirements in the Airbyte database override your Helm/env var settings. Why This Happens The workload-launcher resolves resource requirements from multiple sources, and actor definitions stored in the database can take precedence over global

workloads.resources

Helm values and environment variables — even when

useConnectorResourceDefaults: false

is set. [workload resource issue] Workarounds 1. Set resources via Helm values (try this first)

global:
  jobs:
    resources:
      requests:
        cpu: "1"
        memory: "2Gi"
      limits:
        cpu: "2"
        memory: "4Gi"

After applying, force a recreation of the workload-launcher pod. [workload resource issue] 2. Set env vars directly on the workload-launcher

workloadLauncher:
  extraEnv:
    - name: JOB_MAIN_CONTAINER_CPU_LIMIT
      value: "2"
    - name: JOB_MAIN_CONTAINER_CPU_REQUEST
      value: "1"
    - name: JOB_MAIN_CONTAINER_MEMORY_LIMIT
      value: "4Gi"
    - name: JOB_MAIN_CONTAINER_MEMORY_REQUEST
      value: "2Gi"

> ⚠️ Important: Use whole numbers (e.g.,

"2"

) rather than millicore notation (e.g.,

"2000m"

) — there is a known bug where millicore values are misparsed by the workload-launcher. [millicore bug] 3. Override directly in the database (nuclear option) If the above don't work, you can set

resource_requirements

directly at the connection level:

UPDATE connection
SET resource_requirements = jsonb_build_object(
  'cpu_request', '1',
  'cpu_limit',   '2',
  'memory_request', '2Gi',
  'memory_limit',   '4Gi'
)
WHERE id = '<your-connection-id>';

This has been confirmed to work by multiple users when Helm/env var approaches fail. [workload resource issue] Note that there is currently no direct database-level override specifically for the orchestrator container — the

connection.resource_requirements

setting applies to source/destination containers. The orchestrator resource issue is tracked as an open bug. [container orchestrator issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.