hello 👋 according to the official doc, latest Airbyte version is

2.1

from 03/04/2026, and still marked as

Experimental version release

:

This version of Airbyte is experimental. Airbyte changed the way we assemble new versions and haven't tested every feature and Helm chart configuration in version 2.1.0. If stability is your primary concern, you may elect to skip this version.

👉 do you plan to release a new official stable version ? NB: interested by some feedbacks regarding stack Airbyte on GKE + Cloud SQL + GCS if someone upgraded to latest version 🙏

We align with the stack you mentioned, but I haven't made the jump yet. So interested in hearing from others as well

Hi there, We upgraded our self-managed deployment to version 2.1 back in April, running a stack that includes GKE + Cloud SQL (PostgreSQL), replicating MySQL tables to BigQuery. Regarding your question and our hands-on feedback: 1. The "Experimental" Label vs. Real Stability > Despite the warning in the release notes about the new assembly process, version 2.1 has been overall very stable for us in production. Performance is solid, and the platform handles the core replication tasks beautifully. 2. Our GKE + Cloud SQL Feedback (The one major caveat) > There is one specific open issue you should be aware of if you run on GKE with cluster autoscaling: Issue #77624. > When the GKE autoscaler decides to evict or scale down the Temporal or Workload API pods mid-sync (especially during CDC syncs), the replication jobs can get stuck indefinitely in an inconsistent state. The orchestrator doesn't catch the pod eviction properly, so the job never fails or times out naturally. Our Workaround 🛠️ > Since this bug is still open, we mitigated it marginally by setting up a custom script that leverages the Airbyte API. It periodically checks for running jobs and forcefully terminates any sync that has been stuck for more than 30 minutes (since our normal syncs take much less time). This prevents our queue from clogging up. Summary 📝 > If you have a way to handle or monitor stuck jobs (or if your GKE cluster doesn't have aggressive node autoscaling/evictions during sync windows), we definitely recommend the upgrade. The new features are worth it.

Thank you @Fabrizio Spini for interesting answer 🔥 Do you have an ETA for a new bugfix release including this issue fix ?

@Fabrizio Spini I'm also curious if you're using Pod Disruption Budgets currently and if so what they look like

Hi Kevin. No imminent plan for another OSS release in the next month or two, but I'd like to do another one as soon as it's practical. Re: the experimental label: we had a perfect storm of an unusually massive release mixed with a completely rebuilt process for assembling that release. It was my call to label it as experimental. We had to pick our battles when testing and I didn't want to disappoint people who already had a stable 2.0 deployment. That said, for most people 2.1 has been running fine. There are just going to be little things like what Fabrizio describes above that we couldn't foresee at the time we were testing it.

Hey @Justin Beasley , we're not using pdb.

Hi @Ian Alton , @Justin Beasley , @Fabrizio Spini , we identified another blocking point regarding the last version : https://github.com/airbytehq/airbyte/issues/77876 Please could you consider a fast bug fix for this or propose an easy workaround ? 🙏 Thank you a lot.

@Kevin Lefevre Looks like Ian answered in this thread and recommended staying on 2.0 for now: https://airbytehq.slack.com/archives/C023W76QGE4/p1782138298593279

Ian at Airbyte

The fix will require a new OSS release, which isn't scheduled imminently, although I'd like to do another one when practical. For the time being please stay on 2.0, but I will put this issue on the list to fix with the next release.

we already upgraded to v2.1 as @Ian Alton mentioned "for most people 2.1 has been running fine" (and I agree, everything else look fine for now 🙏)

Thanks Kevin. My apologies for this. This is a current bug in 2.1. It's on the list to fix with the next release and I should have mentioned it. Unfortunately the workaround for the moment is to run 2.0. It's a platform code bug without a corresponding setting in the helm chart.

Do you know if downgrading from chart

2.1.0

(app

2.1.0

) to

2.0.19

(app

2.0.1

) is risky ? any experience feedbacks on this ?

@Kevin Lefevre in my opinion and in my case it's better (for performance and other bugs that I found on 2.0 like record lost on mysql-->bigquery replication) to stay on 2.1.0, but this is my opinion as a consumer... In any case on gke (or any other system you're using) you can deploy another airbyte instance (on a new namespace fro gke) to deal with the 100 connections bug. @Ian Alton is there a public place where I could check the bugs listed for a fix in the next release?

FYI a workaround is to manually create the Connection from the UI, then import the generated UUID in Terraform then apply => no issue

@Kevin Lefevre we generally discourage downgrades within the same deployment because we don't track DB migrations, which means they won't be undone and stability could suffer. However it sounds like you found a workaround. We discussed getting an open source release together in the most recent planning sync so I'm hoping we'll be able to address this soon. Thanks for your patience. @Fabrizio Spini unfortunately we don't have this right now.