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