Hi Jark, Thanks for laying out such a great vision. Regarding production stability and maintainability, I have a few considerations:
1. Multi-disk Support I’m not certain if KV clusters can transition directly from local disks to cloud-native "zero-disks" as log clusters do. The evolution path might likely be: single local disk -> multiple local disks -> zero-disk. For KV clusters, do we need to support multiple local disks to reduce costs before fully realizing the zero-disk architecture? 2. Physical Isolation at DB/Table Level This is another critical requirement for KV in production. Unlike log workloads, KV use cases are highly diverse, necessitating physical-level isolation to prevent cross-business interference (the "noisy neighbor" effect). 3. Rate Limiting We should support traffic throttling/rate limiting at both the database and table levels. Best regards, Liebing Yu On Sun, 11 Jan 2026 at 15:54, Jark Wu <[email protected]> wrote: > Hi everyone, > > As we step into 2026, I’d like to kick off a collaborative discussion > around the Fluss Roadmap for 2026 to align our community efforts, set > clear priorities, and ensure Fluss continues to evolve in a direction > that best serves real-world use cases, especially in streaming, > lakehouse, and AI workloads. > > I’ve drafted an initial set of themes and focus areas based on recent > contributions and user feedback: > > 👉 https://github.com/apache/fluss/discussions/2342 > > If you are running Fluss in production or evaluating it for your > next-gen architecture, your feedback is critical. It's very welcome to > comment here or in the GitHub Discussion thread about: > > * Blockers: What is missing that prevents you from deploying Fluss today? > * Priorities: Which feature below would provide the most immediate > value to your team? > * AI & Lakehouse: Which specific integration do you expect the most? > > > Side note: Once the 2026 roadmap is finalized, I suggest replacing the > current roadmap page on the website (https://fluss.apache.org/roadmap) > with this version by linking to the GitHub discussion link. This makes > it easier to maintain and keep up to date, as it stays naturally > synchronized with actual GitHub development progress. > > > Best, > Jark Wu >
