@kapa.ai After upgrading from 1.4 to 2.0.1, the syncs that took 1-2 minutes now take 30minutes minimum with 0 bytes

The behavior you describe (very long syncs that report

0 bytes / 0 records

) after an upgrade is consistent with a few known issues and patterns in the docs and GitHub issues, but there is no single, explicit “1.4 → 2.0.1 causes 30‑minute empty syncs” bug documented. Here’s what we can say from the sources: 1. Platform upgrade can change connector behavior/performance Multiple users report that after platform or connector upgrades, syncs become significantly slower, even when they move 0‑small amounts of data. In some cases, this is due to connector changes that trade speed for stability, or regressions in connector implementations (e.g., Mongo, BigQuery, ASP, DB connectors). [[Mongo performance](https://discuss.airbyte.io/t/1011); [Speed after 1.x](https://discuss.airbyte.io/t/2416); [BigQuery regression](https://github.com/airbytehq/airbyte/issues/64902)] 2. Very long “empty” syncs can be caused by platform components not being on the correct version In the Helm deployment case, after upgrading the chart, one component (

airbyte-workload-api-server

) stayed on an old version and caused every sync to effectively “stall” and then auto‑heal after ~15 minutes, making all syncs take at least that long. Manually updating that deployment to the new tag fixed the issue. [[Helm 1.4.0 performance](https://github.com/airbytehq/airbyte/issues/53180)] Even though this example is for Helm 1.4.0, the pattern is important: if one or more platform services didn’t upgrade cleanly, job orchestration can hang while reporting 0 bytes. 3. Jobs can sit “doing nothing” if the platform is waiting for resources or stuck before launching job pods There are reports where syncs with tiny data (~20KB) take many minutes because the platform is waiting for free workers / pods; tuning

MAX_SYNC_WORKERS

helped in Kubernetes deployments. [[Slow small syncs](https://discuss.airbyte.io/t/3780)] Separately, there’s an open issue where Airbyte services get stuck and “no new job pods are launched”, resulting in jobs that technically start but never really run (sometimes showing

0 bytes / no records

). [[Stuck jobs, no pods](https://github.com/airbytehq/airbyte/issues/68115)] 4. 0‑byte syncs after upgrade are also mentioned in the context of 2.0 A contributor notes that after upgrading to Airbyte 2.0 on EKS, some jobs start correctly while others report `Sync Succeeded 0 bytes|no records loaded`; in those failing cases, orchestrator/source/destination pods are not launched even though the job enters a running state. [[Stuck jobs, no pods](https://github.com/airbytehq/airbyte/issues/68115)] 5. 2.0.1 changed the job heartbeat mechanism, but docs do not state a known regression The 2.0.1 notes say the heartbeat mechanism was optimized to reduce unnecessary DB writes and improve performance, but there is no documented bug about it causing 30‑minute empty syncs. [[2.0.1 release](https://docs.airbyte.com/release_notes/v-2.0#version-201)] Given all this, the knowledge sources suggest these concrete checks: - Verify all platform services actually upgraded to 2.0.1 If you’re on Kubernetes/Helm, check that every Airbyte deployment (including workload API / orchestrator-style services) is on the same tag/image and none are still running 1.4.x. A mismatch is a known cause of “every sync takes ~15 minutes” behavior. [[Helm 1.4.0 performance](https://github.com/airbytehq/airbyte/issues/53180)] - Confirm job pods are being launched for failing syncs For a sync that shows 30 minutes and 0 bytes, inspect whether source/destination/orchestrator job pods were ever created. If they are not, you may be hitting the “services stuck / no new job pods” issue seen on 2.0, where jobs enter a state but never really run. [[Stuck jobs, no pods](https://github.com/airbytehq/airbyte/issues/68115)] - Check worker concurrency / MAX_SYNC_WORKERS (Kubernetes) If you have many connections, your jobs may be waiting in queue. Increasing

MAX_SYNC_WORKERS

and ensuring enough worker replicas helped at least one user reduce multi‑minute waits for tiny jobs. [[Slow small syncs](https://discuss.airbyte.io/t/3780)] - Look for connector‑specific regressions For any connector where you know the data should change, but you still see 0 bytes plus a long run time, check whether that connector version has a known performance or “empty output” regression (examples exist for BigQuery destination, Amazon Selling Partner, Mongo, etc.). [[ASP empty reports](https://discuss.airbyte.io/t/3845); [Mongo performance](https://discuss.airbyte.io/t/1011); [BigQuery regression](https://github.com/airbytehq/airbyte/issues/64902)] The sources do not contain a documented, confirmed bug that upgrading the core platform from 1.4 to 2.0.1 alone will always turn 1–2 minute syncs into 30‑minute 0‑byte runs, so I cannot assert that as a known regression. To move forward, based strictly on these sources, the most likely angles are: 1. A partial/misaligned upgrade where one of the services is still on 1.x and holding jobs in a long “waiting” state. [[Helm 1.4.0 performance](https://github.com/airbytehq/airbyte/issues/53180)] 2. The “stuck services / no job pods” behavior reported on 2.0 deployments. [[Stuck jobs, no pods](https://github.com/airbytehq/airbyte/issues/68115)] If you can share (in GitHub or the forum) whether: - all your Airbyte services are on 2.0.1, and - for a given 30‑minute / 0‑byte sync, whether any job pods get created, you’ll be aligned with how similar issues are being debugged in the references above.