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
