Hi Xuan, The vote passed and the repo has been created. https://github.com/apache/iotdb-client-rust
Thanks, Haonan On 2026/07/17 03:57:02 王旋 wrote: > Hi Yuan, > > Thank you for the suggestions. Status on both: > > 1. Compatibility & release policy -- now landed in the repository as > COMPATIBILITY.md <http://compatibility.md/> [1]: > > - IoTDB server compatibility matrix: 2.0.1-2.0.8, 2.0.10 and master are > listed; 2.0.6 and 2.0.10 are tested (CI live suite / full benchmark + > data-correctness verification respectively), the other versions are > explicitly marked as untested. > - A per-release protocol toolchain table recording, for each crate > version, the exact IDL source (currently apache/iotdb master, > iotdb-protocol/ @ 2fedd8a395) and the Thrift compiler version (0.23.0, > as pinned by the IoTDB pom), plus the thrift crate version. > - A SemVer policy (Cargo semantics, 0.x pre-1.0 rules), a deprecation > policy (#[deprecated] for at least one minor release before removal), > and a release checklist that updates the toolchain table on every > release. > > CI now runs the live integration suite and examples against both the > oldest tested and the latest stable IoTDB (2.0.6 and 2.0.10) as a build > matrix [2]. > > 2. crates.io publishing permissions and a community-managed release > process -- fully agreed. Since this depends on the Apache repository and > community processes existing first, I will file it as a roadmap issue in > apache/iotdb-client-rust once the repository is created, covering > community-owned crates.io ownership, reproducible release steps, and > review by multiple maintainers. > > [1] > https://github.com/CritasWang/iotdb-client-rust/blob/main/COMPATIBILITY.md > [2] > https://github.com/CritasWang/iotdb-client-rust/blob/main/.github/workflows/ci.yml > > Best regards, > Xuan Wang > > zerolbsony <[email protected]> 于2026年7月16日周四 20:58写道： > > > Hi, Xuan Wang > > It’s hard to believe that Rust has overtaken Go and become so popular. > > The top 10 programming languages in the July 2026 TIOBE rankings are as > > follows: > > Python – 18.94% > > C – 10.86% > > C++ – 9.12% > > Java – 8.03% > > C# – 4.49% > > JavaScript – 2.72% > > Visual Basic – 2.48% > > SQL – 1.71% > > R – 1.69% > > Rust – 1.34% > > > > > > I’ve noticed that starting from 2024, the Linux kernel has allowed certain > > modules, primarily device drivers, to be written in Rust. > > > > > > Rust can be used to write Linux kernel modules, which means you can run > > Rust code directly at the kernel level. This is extremely useful for > > scenarios that demand high performance and low-level hardware operations. > > Have you considered invoking certain IoTDB functionalities directly via the > > Linux kernel to boost performance? > > Best regards, > > Bo Li > > > > > > >Hi, > > > > > >Thank you very much for the supportive and detailed reply. The suggested > > >route (code donation to the existing TLP + ASF IP clearance, rather than > > >incubation) makes sense to me, and I'm glad full Java-parity is not a > > >prerequisite — an incremental, roadmap-tracked approach matches how the > > >client was built. > > > > > >Below are the five items requested before a vote. > > > > > >## 1. Supported IoTDB version matrix > > > > > >| IoTDB version | Status | Evidence | > > >|---|---|---| > > >| 2.0.6 | Supported | CI integration job runs the full live test suite + 3 > > >examples against apache/iotdb:2.0.6-standalone on every push | > > >| 2.0.10 | Supported | Full benchmark + data-correctness verification (all > > >10 data types, tree & table, nulls) against a 2.0.10 standalone > > deployment | > > >| 2.0.x (general) | Expected to work | Thrift IDL is synced from > > >iotdb-protocol/ master; protocol version V3; no version-specific branching > > >in the client | > > >| 1.x | Not targeted | Table model and several data types > > >(TIMESTAMP/DATE/BLOB/STRING) assume 2.x; no plan to support 1.x | > > > > > >TLS was verified end-to-end against 2.0.6 with enable_thrift_ssl (TLSv1.3, > > >full certificate verification). RPC compression (compact protocol) > > verified > > >against a server with dn_rpc_thrift_compression_enable=true. > > > > > >## 2. Contributors and provenance > > > > > >The entire git history has a single author — myself (Wang Xuan / > > CritasWang > > ><[email protected]>). I am an existing Apache IoTDB committer with an > > ICLA > > >already on file, and I hold full ownership of this work, so the provenance > > >chain is straightforward. Two categories of code in the repo: > > > > > >- Hand-written code: 100% original work, written for this project, > > >Apache-2.0 headers on every file. > > >- Generated code (src/protocol/): produced by the Apache Thrift compiler > > >from the Apache IoTDB project's own IDL files (iotdb-protocol/, ALv2); the > > >generation pipeline (tools/generate-thrift.sh) is documented and > > >reproducible. > > > > > >No code was copied from other client SDKs; the Java/C#/Node.js clients > > were > > >used as behavioral references only (wire-protocol semantics), which is > > also > > >how the cross-client protocol issues (e.g. the Node.js DATE encoding bug) > > >were found. > > > > > >## 3. Dependency and license inventory > > > > > >Runtime dependencies (4 + 1 optional): > > > > > >| Crate | Version | License | Purpose | > > >|---|---|---|---| > > >| thrift | 0.23 | Apache-2.0 | RPC (matches the compiler version pinned by > > >the IoTDB pom) | > > >| byteorder | 1.5 | Unlicense OR MIT | Big-endian encoding | > > >| chrono | 0.4 | MIT OR Apache-2.0 | DATE handling | > > >| log | 0.4 | MIT OR Apache-2.0 | Logging facade | > > >| native-tls (optional, feature "tls") | 0.2 | MIT OR Apache-2.0 | TLS | > > > > > >Dev-dependency: env_logger (MIT OR Apache-2.0). Full transitive closure: > > 74 > > >packages, machine-checked — every one is MIT / Apache-2.0 / Unlicense / > > BSD > > >/ Zlib dual-or-multi licensed, i.e. 100% ASF Category-A. Zero > > Category-B/X, > > >zero unknown-license packages. The full inventory (cargo metadata) can be > > >attached to the IP-clearance checklist. > > > > > >## 4. Proposed initial maintainers and maintenance plan > > > > > >- Initial maintainer: myself (CritasWang — existing IoTDB committer). I > > >commit to maintaining the client — issue triage, protocol-sync with > > >iotdb-protocol changes, and regular releases through the normal IoTDB > > >community process — and to growing co-maintainers from the community; > > >review bandwidth from other committers/PMC members on client-facing > > changes > > >would be welcome. > > >- The repo already carries the practices expected for handover: CI (fmt / > > >clippy -D warnings / license check / unit tests / live integration against > > >a service container), bilingual READMEs, runnable examples, a > > >statistics-aligned benchmark, and a documented codegen pipeline. Nothing > > >depends on my personal infrastructure. > > > > > >## 5. API support matrix (vs Java client) and near-term roadmap > > > > > >Supported today (feature → Java-client equivalent): > > > > > >| Area | Rust today | Java client | > > >|---|---|---| > > >| Session lifecycle, multi-node URLs, failover, auto-reconnect | ✅ | ✅ | > > >| insertTablet / insertTablets | ✅ | ✅ | > > >| insertRecord(s) / insertRecordsOfOneDevice (+ aligned variants) | ✅ | ✅ > > | > > >| Table model (TableSession/Pool, TAG/FIELD/ATTRIBUTE) | ✅ | ✅ | > > >| SessionPool / TableSessionPool (idle eviction, redirection cache) | ✅ | > > ✅ > > >| > > >| Query + paging iteration (TsBlock, fetchResultsV2) | ✅ | ✅ | > > >| All data types incl. TIMESTAMP/DATE/BLOB/STRING | ✅ | ✅ | > > >| TLS (incl. client identity) / RPC compression | ✅ | ✅ | > > >| deleteData / deleteTimeseries / DDL helpers | SQL only | ✅ dedicated > > APIs > > >| > > >| Schema templates | ❌ | ✅ | > > >| executeRawDataQuery / executeLastDataQuery / aggregation APIs | ❌ | ✅ | > > >| Per-type encoding tuning (RPC compression V2) | ❌ | ✅ | > > > > > >Near-term roadmap (order negotiable with the community): > > > > > >1. async (tokio) API layer — most-requested Rust-ecosystem feature, kept > > >out of v0.1 to keep the sync core small > > >2. crates.io releases under the Apache project > > > > > >I'll keep this thread open for feedback on maintenance ownership and API > > >scope as suggested. Since I'm an existing committer with an ICLA on file > > >and the sole author, the IP-clearance paperwork should be light — I'm > > happy > > >to prepare whatever the PMC deems necessary (software grant if required > > for > > >the pre-existing external history, plus the dependency inventory above) > > >whenever the community feels ready to move to a VOTE. > > > > > >Best regards, > > >Xuan Wang > > > > > >Haonan Hou <[email protected]> 于2026年7月15日周三 15:06写道： > > > > > >> 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 > > >> > > > >> > > >
