Hi Xuan, Thank you for sharing this work. The implementation already covers a substantial part of the client functionality, and the test coverage, live integration testing, CI setup, and benchmark results are all encouraging.
The protocol issues and performance improvements discovered while validating against the other clients are also a good indication that this work can benefit the broader IoTDB client ecosystem. As a member of the IoTDB PMC, I support bringing a well-maintained Rust client into the Apache IoTDB project. Based on what you have presented, I believe this repository is a strong candidate for donation and for becoming an official IoTDB client. Since IoTDB is already an Apache top-level project, the appropriate route should be a code donation to the existing project, followed by the ASF IP clearance process, rather than incubation as a separate project. I suggest the following next steps: 1. Continue this DISCUSS thread to collect feedback from the community, especially regarding maintenance ownership and the initial API scope. 2. Prepare a concise compatibility and API-support matrix against the Java client, together with a near-term roadmap. 3. If there are no major concerns, start a formal PMC VOTE to accept the code donation and create the apache/iotdb-client-rust repository. 4. Complete the software grant, code provenance, dependency/license review, and ASF IP clearance. 5. Move the code to the Apache repository and continue development and releases through the normal IoTDB community process. I do not think complete Java client API parity needs to be a prerequisite for the donation. The current functionality appears sufficient to establish a useful official client. APIs such as schema-template operations and additional session-level query methods can be added incrementally and tracked through a public roadmap. Before moving to a vote, it would be helpful to provide: - The supported IoTDB version matrix. - A list of contributors and confirmation of the code’s ownership/provenance. - A dependency and license inventory. - The proposed initial maintainers and long-term maintenance plan. - An API support matrix and near-term roadmap. Overall, I am supportive of this proposal and am willing to help move the discussion and donation process forward. Best regards, Haonan Hou On 2026/07/15 03:50:24 王旋 wrote: > Hi all, > > I'd like to share a Rust client SDK for Apache IoTDB that I've been > developing, and ask for the community's feedback on whether there is > interest in bringing it into the Apache IoTDB ecosystem. > > Repository: https://github.com/CritasWang/iotdb-client-rust > > Scope & features > > Tree model (Session) and table model (TableSession / SQL dialect), > mirroring the API shape of the Java / C# / Node.js clients > Write APIs: insertTablet / insertTablets (multi-tablet batching), > insertRecord(s), insertRecordsOfOneDevice, plus aligned variants > SessionPool and TableSessionPool: RAII checkout, lazy growth, idle > eviction, dead-connection eviction, write-redirection cache (status 400 > redirect hints), automatic reconnect with endpoint failover > Full data-type coverage including TIMESTAMP / DATE / BLOB / STRING; TsBlock > decoding with logical-type re-tagging (the TsBlock header carries physical > types — DATE arrives as INT32, BLOB as TEXT) > TLS (feature-gated, incl. client identity) — verified end-to-end against a > real IoTDB with enable_thrift_ssl; RPC compression (compact protocol) > Thrift codegen pipeline sources the IDL from iotdb-protocol/ and uses the > thrift compiler fetched by the IoTDB Maven build, so the stubs stay in > lockstep with the server > > Quality > > 113 unit tests (124 with TLS) + live integration tests that skip gracefully > without a server; CI on GitHub Actions runs fmt / clippy -D warnings / > license checks plus an integration job against an IoTDB 2.0.6 service > container — green > Statistics-aligned benchmark (measurement semantics mirror iot-benchmark: > prep inside the timed span, failures excluded from latency, Result/Latency > Matrix output). On a 16-core server writing 2B points per run (table model, > 100 devices x 20 DOUBLE sensors, 1000-row tablets, 20 sessions), the Rust > client sustains ~46-47M points/s — statistically tied with iot-benchmark's > Java Session path on the same box, where the server, not the client, is the > ceiling > Every file carries the ASF Apache 2.0 header > > Side effects the community already received > > Cross-validating the wire protocol against the Java / C# / Node.js > implementations surfaced two upstream issues in the Node.js client, both > now addressed: the DATE wire-encoding fix (apache/iotdb-client-nodejs#14, > PR #15, merged) and a write-path serialization optimization (+52% > throughput, PR #16, under review). > > Questions for the community > > Is there interest in an official Rust client under the Apache IoTDB > umbrella (e.g., apache/iotdb-client-rust), following the path of the > Node.js / C# clients? > If so, what would the preferred route be — code donation via the incubator > process for client SDKs, or starting a repo under the existing project and > iterating there? > Any API-surface expectations from the PMC side before such a move (e.g., > schema-template APIs, session-level query APIs like executeRawDataQuery)? > I'm happy to keep maintaining it either way, and to align the roadmap with > the community's priorities. > > 大家好 > > 我想向社区分享一个我一直在开发的 Apache IoTDB Rust 客户端 SDK，并征求大家的意见：社区是否有兴趣将它纳入 Apache > IoTDB 生态。 > > 仓库地址：https://github.com/CritasWang/iotdb-client-rust > > 范围与功能 > > 树模型（Session）与表模型（TableSession / SQL 方言），API 形态与 Java / C# / Node.js 客户端对齐 > 写入 API：insertTablet / insertTablets（多 tablet > 批量）、insertRecord(s)、insertRecordsOfOneDevice，以及 aligned 变体 > SessionPool 与 TableSessionPool：RAII 借还、惰性增长、空闲回收、死连接剔除、写重定向缓存（status 400 > 重定向提示）、带端点故障转移的自动重连 > 完整数据类型覆盖，包括 TIMESTAMP / DATE / BLOB / STRING；TsBlock 解码带逻辑类型重标记（TsBlock > 头携带的是物理类型——DATE 以 INT32 到达、BLOB 以 TEXT 到达） > TLS（feature 门控，含客户端证书）——已对开启 enable_thrift_ssl 的真实 IoTDB 完成端到端验证；RPC > 压缩（compact 协议） > Thrift 代码生成流水线：IDL 取自 iotdb-protocol/，编译器使用 IoTDB Maven 构建拉取的版本，确保 stub > 与服务端严格同步 > > 质量 > > 113 个单元测试（含 TLS 为 124 个）+ 无服务器时优雅跳过的 live 集成测试；GitHub Actions CI 运行 fmt / > clippy -D warnings / license 检查，另有针对 IoTDB 2.0.6 service container 的集成 > job——全绿 > 统计口径对齐的基准测试（测量语义对齐 iot-benchmark：批准备计入计时段、失败不计入延迟、Result/Latency Matrix > 输出）。在 16 核服务器上每轮写入 20 亿点（表模型、100 设备 x 20 个 DOUBLE 测点、1000 行/tablet、20 > 会话），Rust 客户端持续吞吐约 4600-4700 万点/秒——与同机 iot-benchmark 的 Java Session > 路径统计学持平，此时瓶颈在服务端而非客户端 > 所有文件均带 ASF Apache 2.0 头 > > 社区已经收到的副产品 > > 在与 Java / C# / Node.js 实现交叉验证线上协议的过程中，发现了 Node.js 客户端的两个上游问题，目前均已处理：DATE > 线上编码修复（apache/iotdb-client-nodejs#14，PR #15，已合并）以及写路径序列化优化（吞吐 +52%，PR > #16，评审中）。 > > 想请教社区的问题 > > 社区是否有兴趣在 Apache IoTDB 旗下提供官方 Rust 客户端（例如 apache/iotdb-client-rust），沿用 > Node.js / C# 客户端的路径？ > 如果有，倾向的路线是什么——通过客户端 SDK 的代码捐赠流程，还是先在现有项目下建仓库迭代？ > 在此之前，PMC 对 API 面是否有预期要求（例如 schema 模板 API、executeRawDataQuery 等会话级查询 API）？ > 无论结果如何，我都会继续维护它，并愿意将路线图与社区的优先级对齐。 > > Best regards, > Xuan Wang >
