Hi all, Thank you, Xuan, for providing detailed information about the client’s compatibility scope, code provenance, dependency licenses, maintenance plan, and API coverage. Thanks also to Haonan for outlining the proposed donation path.
Based on the information provided, I support accepting the Rust client as a code donation to Apache IoTDB and developing it into an official client. The existing functionality, tests, and CI foundation already demonstrate its practical value. I also agree that full feature parity with the Java client should not be a prerequisite for accepting the donation. I have two suggestions, but I do not consider either of them a blocker for the donation or the VOTE: 1. Before the first official release, it would be helpful to formalize the compatibility and release policy. For example, each crate version could document the IoTDB IDL and Thrift compiler versions it uses; CI could continuously test against both the oldest supported and latest stable IoTDB versions; and the documentation could describe the SemVer policy, deprecation policy, and client/server compatibility matrix. 2. After the migration to Apache, I suggest ensuring that the crates.io publishing permissions and release process are managed by the project community, with reproducible release steps and review by multiple maintainers. This would reduce the risks associated with relying on a single maintainer and help grow the maintainer community over time. These items can be tracked as public issues or roadmap tasks after the code is accepted. Based on the information currently available, I do not see any issue preventing the proposal from moving forward. I support starting the formal VOTE after leaving the DISCUSS thread open for a short feedback period. Best regards, Yuan Tian On Wed, Jul 15, 2026 at 11:50 AM 王旋 <[email protected]> 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 >
