[GSoC 2026] Flink connector for IoTDB table mode – prospective contributor

[anukalp2804]

Hello,

I’m Anukalp, a CS undergraduate with a strong interest in Java-based backend and data integration systems. I’ve been going through the GSoC idea around building a Flink connector for Apache IoTDB 2.X table mode, and the scope and motivation behind the project are very clear and interesting.

From my understanding, the existing Flink connectors mainly focus on the tree mode, and this project aims to provide first-class support for IoTDB’s table mode through Flink’s DataStream and Table APIs, including schema mapping, read/write support, and fault tolerance.

I’m preparing for GSoC 2026 and plan to start by exploring the existing flink-iotdb-connector, the table-mode SQL features in IoTDB 2.X, and Flink’s connector architecture. I had a couple of questions:

• Are there specific modules or existing connectors you would recommend focusing on first to better understand the current limitations around table mode?
• For the initial implementation, do you see it leaning more toward the Flink Table API, or should both the Table and DataStream APIs be considered from the beginning?

I’d appreciate any guidance on how to prepare effectively and where early exploratory contributions would be most useful.

Thank you for your time.

[JackieTien97]

Thank you for your strong interest in the Apache IoTDB Flink connector project. We are impressed with your thorough preparation and understanding of the project's goals.

Regarding your questions, here is some guidance:
Research Focus: We recommend you start by delving into the Source and Sink implementations for the Tree Mode within the existing flink-iotdb-connector[1]. This will provide you with a solid understanding of the current data flow and architecture, which is key to identifying the refactoring or challenges required to properly adapt it for Table Mode. Your plan to explore Table Mode SQL features is also excellent.
API Prioritization: Given that the Flink Table API is the primary integration path for many users, I suggest focusing your initial proposal and implementation on strong Table API support to quickly achieve a Minimal Viable Product (MVP) for core read/write functionality. However, the DataStream API is the underlying foundation, and a complete connector should ideally support both, so please keep it in mind for the overall design.
Your initial steps are sound. We encourage you to share your exploratory findings or any preliminary design ideas with us, perhaps as a Pull Request (PR) or another Discussion thread, so we can provide more specific feedback.

[1] https://github.com/apache/iotdb-extras/tree/master/connectors/flink-iotdb-connector

[anukalp2804]

Thank you for the detailed guidance and encouragement.

I’ll start by studying the Source and Sink implementations for Tree Mode in the existing flink-iotdb-connector to better understand the current data flow and architecture. In parallel, I’ll continue exploring IoTDB’s table-mode SQL features to identify where adaptations may be needed.

I’ll keep the Flink Table API as the primary focus for an initial MVP while keeping the DataStream API in mind for the overall design. Once I have some exploratory findings or early design thoughts, I’ll be happy to share them in a follow-up discussion or small PR for feedback.

Thanks again for your guidance.

Sincerely,
Anukalp Pandey

[anukalp2804]

Hello ,

Following our previous discussion, I wanted to share a quick update on my progress with the IoTDB 2.0 Table Model integration.

To better understand the new API, I built a functional Proof of Concept (PoC) that successfully connects Flink 1.18 to IoTDB in Table Mode.

Key Findings: During implementation, I confirmed that the standard Session class defaults to the legacy Tree Model, which caused syntax errors when executing SQL (e.g., CREATE TABLE). I resolved this by switching to the TableSessionBuilder, which explicitly initializes the connection with the correct SQL dialect.

I have implemented a custom Flink SourceFunction that executes SQL queries and streams the result rows into Flink. You can review the prototype code and execution logs here:

https://github.com/anukalp2804/flink-iotdb-table-connector

Next Steps for GSoC Proposal: Based on this PoC, my plan for the official proposal is to:

1. Upgrade from SourceFunction to the new FLIP-27 Source API to support parallelism.
2. Implement a Type Mapping utility to convert IoTDB types (INT32, FLOAT) to Flink RowData.
3. Develop the corresponding Sink for writing data back to IoTDB.

I would love to hear your thoughts on this approach. Does this align with the project's vision?

Thank you for your time.

Sincerely,
Anukalp Pandey

[HTHou]

Hi Anukalp,

Thank you for your enthusiasm and for already starting on the code — Really appreciate it!

A gentle note: the GSoC project approvals are still pending, so we don’t know yet if it will be accepted. See [1].

For now, it might be best to wait for the official results. If you're interested, we could explore some other IoTDB-related tasks or contributions.

We’ll let you know as soon as we hear anything. Feel free to reach out if you have any questions.

[1] https://developers.google.com/open-source/gsoc/timeline

Warm regards,
Haonan

[anukalp2804]

Hi Haonan,

Thank you for the kind words and the heads-up regarding the GSoC organization acceptance status. I completely understand that the official results are pending.

Regardless of the GSoC outcome, building this prototype was a great way for me to understand the internal changes in IoTDB 2.0. I am definitely interested in contributing to the project in the meantime to get more familiar with the codebase.

You mentioned exploring other IoTDB-related tasks—are there any specific modules, 'good first issues,' or documentation updates you would recommend I look into? I have my environment set up and ready to go.

Best regards,
Anukalp Pandey