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 > >> > > >> >
