+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://github.com/apache/airflow/pull/59218 > > > > *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 > > >
