Hi Anton, Yes, it's JNI-based. We're planning to evaluate the C++ client and will reach out if we find any gaps. Thanks for offering to help!
Best, Qingyu Anton Borisov <[email protected]> 于2026年4月23日周四 15:22写道： > > Hi Qingyu, > > That is very nice to hear, thanks for sharing. > > Please do not hesitate to test the C++ client as well, I think it has > good potential to provide a cleaner integration path and, in the long > run, better performance. I will be very happy to help with the gaps > discovered. > > Am I right in assuming that the current integration is based on JNI? > > - Anton > > ср, 22 апр. 2026 г. в 04:59, 张庆玉 <[email protected]>: > > > > Hi, > > > > Thanks for bringing this up. I'm from the StarRocks team at Alibaba Cloud. > > > > We've already integrated Fluss with StarRocks internally and have > > production users running on it. We're currently working on upstreaming our > > integration to the StarRocks community. > > > > We also plan to continuously optimize the query performance of StarRocks on > > Fluss, including integrating the C++ client. Happy to collaborate and help > > unblock anything needed on either side. > > > > Best, > > Qingyu > > > > > > On 2026/04/21 10:57:13 Anton Borisov wrote: > > > Hi all, > > > > > > Quick interim read, based on the feedback so far - the shape of > > > 0.2.0 looks right, and priorities come through fairly clearly. Thread > > > obviously stays open for further discussions, happy to revise as more > > > voices weigh in. > > > > > > The strongest signal is to start with the repo merge. I am drafting > > > the FIP now and will post it as a separate [DISCUSS] thread this week, > > > scoped narrowly to the fluss-rust -> fluss plan. > > > > > > Observability and metrics (#390) clearly belong in the 0.2.0 must-have > > > set. The PR is already in good shape, and basic latency and throughput > > > metrics are a real production-user need. They also give us a > > > foundation for positioning each binding going forward. > > > > > > For filter pushdown in the FIP-32 Gateway, we do want it eventually, > > > but for now we treat it as a nice-to-have for this release unless > > > contributors pick it up. Thanks Yuxia - this also matches my > > > reasoning. > > > > > > Elixir parity should not be in scope for this release. If part of that > > > work arrives independently and is already in very good shape, we would > > > be happy to include that subset. Anything still in flight should move > > > to its own release. > > > > > > On bindings more broadly, I found Jark’s point persuasive that > > > TypeScript is a stronger fit than Go for AI-agent positioning, which > > > makes it the next native binding to prioritise. That said, I don't > > > feel we have enough capacity to commit release scope here unless > > > external contributors step up to help drive it. Go stays deferred > > > under the same demand-driven criterion. > > > > > > On StarRocks, following Hongshun’s point about production pressure, I > > > see it as very much a nice-to-have for 0.2.0, with the C++ client as > > > the right long-term consumer once the analytical features planned for > > > 0.2.0 are in place. After this release, the broader Rust/C++ > > > analytical story should be in much better shape. > > > > > > Some parts of the StarRocks work can start independently now. Since > > > the StarRocks FE nodes run on the JVM, catalog integration can use the > > > Java client without waiting on the C++ or Rust side. If anyone close > > > to the StarRocks side wants to help drive this, please speak up, also > > > genuinely interested in this myself and will help unblock anything > > > that requires work on the Fluss side. > > > > > > FIP thread incoming. > > > > > > Best, > > > Anton > > > > > > вт, 21 апр. 2026 г. в 03:40, Hongshun Wang <[email protected]>: > > > > > > > > Hi Anton, > > > > > > > > I'm also very interested in the Rust client and will pay more attention > > > > later. > > > > > > > > From our experience, the Java client has been battle-tested at scale in > > > > production through Flink job integration, and it was precisely that > > > > real-world production traffic that surfaced edge cases and drove > > > > continuous > > > > improvements. However, The Rust client currently lacks an equivalent > > > > production-grade scenario. > > > > > > > > I believe pushing forward integrations withStarRocks would provide > > > > exactly > > > > that kind of pressure — production workloads are the best way to expose > > > > hidden issues and drive the client toward true maturity. > > > > > > > > Best, > > > > Hongshun > > > > > > > > On Tue, Apr 21, 2026 at 12:00 AM Jark Wu <[email protected]> wrote: > > > > > > > > > Hi Anton, > > > > > > > > > > Thanks for putting together such a comprehensive and well-structured > > > > > proposal. All the roadmap items sound good to me. > > > > > > > > > > Regarding the open questions: > > > > > > > > > > > Should we prioritize fluss-rust repo merging first? > > > > > > > > > > I strongly believe we should initiate the repo merge process as soon > > > > > as possible, and it must be completed before Fluss 1.0. Here is my > > > > > reasoning: > > > > > > > > > > Fluss 1.0 should represent the complete form of the project — with the > > > > > Gateway, all language SDKs, and unified release coordination from a > > > > > single repository. This is what signals to users and the broader > > > > > ecosystem that Fluss has reached maturity. A fragmented multi-repo > > > > > layout at GA would undermine that message. > > > > > > > > > > That said, the merge itself is a significant undertaking: code > > > > > migration, CI unification, documentation restructuring, issue > > > > > migration, contributor workflow changes, etc. This will consume > > > > > non-trivial community bandwidth. > > > > > > > > > > > Go/TypeScript bindings > > > > > > > > > > Big +1 from me. > > > > > > > > > > TypeScript has become the first-choice language for AI Agent > > > > > development. Having a native Fluss TypeScript client would position > > > > > Fluss very well in the AI-native data infrastructure space. > > > > > > > > > > Best, > > > > > Jark > > > > > > > > > > On Mon, 20 Apr 2026 at 21:13, yuxia <[email protected]> wrote: > > > > > > > > > > > > Thanks Anton for putting together such a well-structured proposal. > > > > > > > > > > > > +1 on the overall tiering. Themes 1-3 as must-have and Theme 4 as > > > > > stretch feels right to me. A few comments inline: > > > > > > > > > > > > OPEN QUESTIONS > > > > > > > > > > > > > Should we prioritize fluss-rust repo merging first? > > > > > > > > > > > > I think we can pursue both in parallel. While the repo-merge > > > > > > proposal > > > > > goes through community discussion (DISCUSS / VOTE), we continue > > > > > developing > > > > > 0.2.0 features in the fluss-rust repo as usual — no need to block one > > > > > on > > > > > the other. > > > > > > > > > > > > That said, I do think we should aim to complete the merge before > > > > > > Fluss > > > > > 1.0, so that 1.0 ships both the Java server and the Rust client from a > > > > > single repository. > > > > > > A unified repo at GA gives users a clearer story and simplifies > > > > > > release > > > > > coordination going forward. > > > > > > > > > > > > > Go/TypeScript bindings > > > > > > I am open to this. It really depends on community demand — if there > > > > > > are > > > > > users or contributors who need Go or TypeScript bindings and are > > > > > willing to > > > > > help drive the effort, I think we should welcome it. > > > > > > > > > > > > > Filter pushdown for FIP-32 Gateway > > > > > > > > > > > > Maybe not a blocker for 0.2, but I think will be nice to have it. > > > > > > > > > > > > > > > > > > > Observability/metrics, TLS/mTLS, auth > > > > > > > > > > > > Observability/ Metrics (#390) would be a nice-to-have for 0.2.0 — > > > > > > even > > > > > basic operation latency and throughput counters help production users. > > > > > > IIRC, it should be in good shape to merge. > > > > > > > > > > > > > > > > > > > Elixir bindings > > > > > > > > > > > > +1 on letting this slip to its own release if needed. Feature parity > > > > > across 13+ issues is a lot of surface area and should not block the > > > > > core > > > > > release. > > > > > > > > > > > > Best regards, > > > > > > Yuxia > > > > > > > > > > > > ----- 原始邮件 ----- > > > > > > 发件人: "Anton Borisov" <[email protected]> > > > > > > 收件人: "dev" <[email protected]> > > > > > > 发送时间: 星期一, 2026年 4 月 20日 下午 6:20:13 > > > > > > 主题: [DISCUSS] fluss-rust roadmap for 0.2.0-incubating > > > > > > > > > > > > Hi all, > > > > > > > > > > > > With 0.1.0-incubating shipped, thanks to Yunhong(RM), Yuxia, > > > > > > Keith and everyone who contributed, I would like to open discussion > > > > > > on priorities for the next fluss-rust release. > > > > > > > > > > > > I propose discussing 0.2.0-incubating roadmap, with the goal of > > > > > > making > > > > > > fluss-rust production-viable for analytical consumers such as > > > > > > DataFusion, Polars, DuckDB, and CDC pipelines, while also closing > > > > > > a known correctness gaps, types support. > > > > > > > > > > > > Rather than a flat list, I grouped the items into four themes, > > > > > > plus a parallel Elixir track. I also proposed an initial tiering > > > > > > of must-have versus stretch goals. Please push back where you > > > > > > disagree. > > > > > > > > > > > > THEME 1: CORRECTNESS: SCHEMA-AWARE DECODING ON KV LOOKUP > > > > > > > > > > > > [MUST-HAVE] > > > > > > > > > > > > KV rows in Fluss carry a 2-byte schema ID prefix. The KV batch > > > > > > reader already uses this ID to select the correct decoder via > > > > > > read_context.get_row_decoder. The lookup path does not. Today, > > > > > > both Lookuper::lookup and PrefixKeyLookuper::lookup decode every > > > > > > row using the table's latest row_type, so rows written under an > > > > > > earlier schema version can be returned with incorrect field > > > > > > values. > > > > > > > > > > > > Scope: > > > > > > > > > > > > Schema-ID-aware decoding in Lookuper and PrefixKeyLookuper > > > > > > > > > > > > Client-side schema cache (fetch schema by ID, LRU). The metadata > > > > > > path may need minor work depending on what is already cached in > > > > > > TableInfo > > > > > > > > > > > > Tests covering multi-schema-version rows through both lookup paths > > > > > > > > > > > > Out of scope for this theme: > > > > > > > > > > > > The KvRecordBatch decode is already schema-ID-aware - confined to > > > > > > Lookup only. > > > > > > > > > > > > Log tables are fine as it is. > > > > > > > > > > > > Tracking: > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/508 > > > > > > > > > > > > THEME 2: UNLOCK ANALYTICAL INTEGRATIONS > > > > > > > > > > > > [MUST-HAVE] > > > > > > > > > > > > Two features that together would make Fluss a first-class source > > > > > > for the analytical ecosystem. > > > > > > > > > > > > (a) Limit scan, with full client-side support > > > > > > > > > > > > Proto and RPC plumbing already landed (PR #472 / issue #315). The > > > > > > remaining work is exposing the limit through the public scanner > > > > > > API so that limit pushdown reaches DataFusion integrations. Issue > > > > > > #311 was filed explicitly to support fluss-datafusion and is also > > > > > > useful for other analytical consumers. > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/311 > > > > > > > > > > > > (b) Changelog subscription for KV tables > > > > > > > > > > > > This would let downstream consumers stream change events out of > > > > > > primary-key tables, which is the natural companion to upsert > > > > > > writes. > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/380 > > > > > > > > > > > > THEME 3: TYPE AND BINDING COMPLETENESS > > > > > > > > > > > > [MUST-HAVE] > > > > > > > > > > > > Close the remaining gaps so that all bindings reach parity on > > > > > > primitive and composite types. > > > > > > > > > > > > Map type in Rust core (depends on array support already landed) > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/387 > > > > > > > > > > > > Array support in C++ bindings > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/468 > > > > > > > > > > > > Cross-binding integration tests for arrays > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/441 > > > > > > > > > > > > Prefix lookup exposed in Python / C++ / Elixir > > > > > > > > > > > > Rust core just landed via PR #500 / issue #499. I will file > > > > > > tracking issues for binding exposure this week. > > > > > > > > > > > > Already landed and out of scope here: > > > > > > > > > > > > Array support in Rust (#386) > > > > > > > > > > > > Array support in Python (#469) > > > > > > > > > > > > THEME 4: FOUNDATIONS FOR THE NEXT CYCLE > > > > > > > > > > > > [STRETCH] > > > > > > > > > > > > Benchmark harness producing reproducible Rust / Python / C++ > > > > > > numbers, ideally suitable for nightly regression tracking in CI. > > > > > > A separate FIP with full design will follow. I already have a raw > > > > > > prototype that I use to verify regressions locally. > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/489 > > > > > > > > > > > > ArrowWriter pooling on the write path, mirroring Java's > > > > > > ArrowWriterPool. This complements the jemalloc / pre-size work > > > > > > (#429) and null-append optimization (#470) already landed. It > > > > > > would be best to land this on top of benchmark coverage so we can > > > > > > quantify the gain. > > > > > > > > > > > > https://github.com/apache/fluss-rust/issues/444 > > > > > > > > > > > > PARALLEL TRACK: ELIXIR BINDINGS 0.1 FEATURE PARITY > > > > > > > > > > > > The Elixir bindings (initial PR #452) need a broader set of > > > > > > features to reach parity with Rust, Python and C++. > > > > > > > > > > > > Open issues: > > > > > > #457, #458, #459, #460, #461, #462, #463, #464, #465, #466, > > > > > > #467, #493, #498 > > > > > > > > > > > > I am happy for this to slip to its own release if the core team > > > > > > agrees. > > > > > > > > > > > > GOVERNANCE TRACKS: SEPARATE FIPS > > > > > > > > > > > > Flagging these so the roadmap accounts for them, but each would > > > > > > get its own DISCUSS / VOTE thread: > > > > > > > > > > > > FIP: Benchmark harness design (supports Theme 4) > > > > > > > > > > > > FIP: Consolidate apache/fluss-rust into apache/fluss > > > > > > > > > > > > OPEN QUESTIONS > > > > > > > > > > > > - Is the proposed tiering reasonable, with Themes 1-3 as must-have > > > > > > and Theme 4 as stretch? Is anything missing or mis-prioritized? > > > > > > > > > > > > - Should we prioritize fluss-rust repo merging first? > > > > > > > > > > > > - Go/Typescript bindings to consider? > > > > > > > > > > > > - FIP-32 Gateway builds on fluss-rust (projection pushdown > > > > > > already supported). Should we add filter pushdown to 0.2.0 > > > > > > to unblock it, or defer? > > > > > > > > > > > > - Are there other items the community has been asking for that > > > > > > should be considered here, such as observability/metrics(we have > > > > > > https://github.com/apache/fluss-rust/issues/390 to start work > > > > > > there), > > > > > > TLS/mTLS, or auth beyond SASL/PLAIN? > > > > > > > > > > > > Looking forward to feedback. > > > > > > > > > > > > Best, > > > > > > — Anton > > > > > > > >
