Hello Arpit, Thanks for initiating this.
I checked the PR briefly and the first qn that pops to my head is what Elad also commented on the PR about using the existing provider itself (I understand the incompatibility that you have mentioned fwiw) For maintainability purposes, I still wonder if there is a way to use the existing provider itself. Like I think postgres provider is a decent example for this. It supports both psycopg2 AND psycopg3 via runtime detection: https://github.com/apache/airflow/blob/f386dd99ceed54e86ff3f84ef91d4bb320b148a8/providers/postgres/src/airflow/providers/postgres/hooks/postgres.py#L40 This is not blocking but something worth evaluating before creating a new provider in my opinion. Thanks & Regards, Amogh Desai On Tue, Mar 17, 2026 at 6:26 PM Arpit Rathore <[email protected]> wrote: > Hi Airflow community, > > I have been working on a new provider to support InfluxDB 3.x > (Core/Enterprise/Cloud Dedicated): > https://github.com/apache/airflow/pull/58929 > > InfluxDB 3.x uses a completely different Python client (influxdb3-python), > SQL queries (vs Flux > in 2.x), and a different connection model (database instead of > org+bucket). There is no shared > code with the existing influxdb provider - these are distinct integrations > targeting different > products. > > Per AIP-95, I am looking for: > > 1. A second steward - someone willing to co-maintain the provider through > incubation > 2. A committer sponsor - a committer willing to guide the provider through > the incubation process > > I am committed to being the primary steward. The implementation is > complete (hooks, operators, > tests, docs). The main remaining work is rebasing and aligning with the > latest CI/tooling setup. > > Would anyone be willing to step into either role? Happy to discuss further > here or on Slack. > > Thanks,Arpit
