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
