Awesome job on the PR! +1 for me too on switching to SQLA 2 On 2025/12/29 14:04:18 Rahul Vats wrote: > +1 for SQLA v2 in Airflow 3.2. > > Regards, > Rahul Vats > > On Mon, 29 Dec 2025 at 03:34, Blain David <[email protected]> wrote: > > > Also +1 to SQLA v2. > > > > If all tests in core are green, I don't any reason why not to do it. I > > suppose we will be able to test is through an alpha/beta release? Always > > willing to test it once a release is available. > > > > -----Original Message----- > > From: Amogh Desai <[email protected]> > > Sent: 28 December 2025 15:10 > > To: [email protected] > > Subject: Re: [DISCUSS] Moving to SQLAlchemy 2.0 for Airflow 3.2 > > > > EXTERNAL MAIL: Indien je de afzender van deze e-mail niet kent en deze > > niet vertrouwt, klik niet op een link of open geen bijlages. Bij twijfel, > > stuur deze e-mail als bijlage naar [email protected]<mailto: > > [email protected]>. > > > > +1 to SQLA v2. > > > > In terms of timeline also, 3.2 doesn't sound too crazy too especially > > because we will likely complete task sdk efforts or take it pretty close to > > the targeted split. And if user's timely upgrade and use latest versions, > > SQLA 2 should just work out of box. > > > > One other place that SQLA models are used is likely plugins? Although I do > > not see those to be heavily affected. > > > > Thanks & Regards, > > Amogh Desai > > > > > > On Fri, Dec 26, 2025 at 8:24 PM Shahar Epstein <[email protected]> wrote: > > > > > +1 for dropping SQLA v1 support and hard switching to v2 in Airflow v3.2. > > > Considering the statements that were raised in this discussion plus > > > the fact that SQLA 1.X was released last year, I don't think that it's > > > worth it to keep this maintenance burden. > > > > > > > > > Shahar > > > > > > On Thu, Dec 25, 2025 at 9:01 PM Dev iL <[email protected]> wrote: > > > > > > > Dear Community, > > > > > > > > I’d like to start a discussion regarding a proposal to *migrate > > > > Airflow > > > to > > > > SQLAlchemy 2.0* for the upcoming *v3.2* feature release. > > > > The Problem: Maintenance Overhead and Locked Ecosystem > > > > > > > > As many of you know, there is a massive ongoing effort by community > > > members > > > > to improve and upgrade type hints across the entire codebase. > > > > However, because our CI currently runs on SQLAlchemy 1.4, *Mypy does > > not "protect" > > > > us* against introducing new violations that would be caught in a 2.0 > > > > environment. This creates a significant maintenance burden where > > > > contributors and reviewers must manually account for type safety > > > > that the CI is unable to enforce. Moving to 2.0 provides native PEP > > > > 484 support, which will drastically improve ORM class coverage and > > > > allow us to catch bugs during development rather than at runtime. > > > > > > > > Staying on 1.4 has created a "dependency ceiling." Migrating to > > > SQLAlchemy > > > > 2.0 will finally allow us to upgrade several key libraries that the > > > > community has been asking for, including: > > > > > > > > - > > > > > > > > *pandas* >= 2.2 (released on Jan 2024) > > > > - > > > > > > > > *numpy* >= 2 (released on Jun 2024) > > > > - > > > > > > > > *flask-sqlalchemy* >= 3.1 (released on Sep 2023) > > > > - > > > > > > > > *sqlmodel* >= 0.12 (released on Nov 2023) > > > > > > > > Current Progress > > > > > > > > We already have a functional path forward. There is an outstanding > > > > PR > > > that > > > > implements this transition: > > > > > > > > - > > > > > > > > *PR:* > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > > > > thub.com%2Fapache%2Fairflow%2Fpull%2F59218&data=05%7C02%7Cdavid.blai > > > > n%40infrabel.be%7C5b83432679b0448bd59e08de461ae245%7Cb82bc314ab8e4d6 > > > > fb18946f02e1f27f2%7C0%7C0%7C639025278444015346%7CUnknown%7CTWFpbGZsb > > > > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOI > > > > joiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xjA39BkkeyGUOAJG4MLNC > > > > fc%2BaEOyt5UhZEx1za6MYLw%3D&reserved=0 > > > > > > > > *Note:* This PR is currently *green* (passing all CI checks), > > > demonstrating > > > > that the core functional changes are stable and do not break our > > > > existing test suite. > > > > Seeking Community Feedback > > > > > > > > We want to ensure this transition is as smooth as possible for all > > > > stakeholders. We are particularly interested in your views on: > > > > > > > > 1. > > > > > > > > *Custom Providers/Plugins:* Are there concerns regarding plugins > > that > > > > rely heavily on SQLAlchemy 1.4 internals? > > > > 2. > > > > > > > > *Database Backends:* Does anyone foresee specific issues with our > > > > supported versions of Postgres, MySQL, or SQLite during this jump? > > > > 3. > > > > > > > > *General Timeline:* Does the community feel Airflow 3.2 is the right > > > > target for this breaking internal change? Should we aim for > > > > official dual > > > > support for a period of time? > > > > > > > > Please share your thoughts, concerns, or support for this move. If > > > > there > > > is > > > > a general consensus, we plan to proceed with the review and merge of > > > > the > > > PR > > > > in the near future. > > > > > > > > Best regards, > > > > > > > > Dev-iL > > > > > > > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
