[Roadmap] Planning 1.1 Release

[wuchong]

Timeline Plan

• Feature Freeze: Dec 1, 2026
• Release: Dec 15, 2026

(under discussion)

Milestone Board

https://github.com/apache/fluss/milestone/9

Planned Features and Improvements

🚨 marks high-priority items. All other items have normal priority. The scope remains open for community discussion.

Connectivity and Gateway

• 🚨 High priority: Kafka Producer Protocol Compatibility — Basic Produce (FIP-55). Enable standard Kafka producers to discover pre-created Fluss tables and write records. Kafka consumer compatibility is outside this milestone.
• REST Gateway Follow-ups (FIP-49): batched primary-key and prefix lookups, HTTP authentication, TLS, and principal propagation.

Log Tables and Streaming Consumption

• 🚨 High priority: Consumer Offsets and Groups (FIP-53). Persist consumer offsets and support consumer groups and group management. Depends on System Tables (FIP-39).
• Rescale Buckets for Log Tables without Bucket Keys (FIP-14). @LiebingYu

Primary Key Tables

• 🚨 High priority: Global Secondary Index (FIP-38). Enable lookups on non-primary-key columns. @platinumhamburg (Reviewers @polyzos)
• 🚨 High priority: Standby Replicas to accelerate primary-key table failover recovery.
• Bulk Loading for Primary Key Tables: efficient initial loading and backfills, and a foundation for promoting existing lake data into Fluss's real-time KV layer.

Lakestream

• 🚨 High priority: In-Place Lakehouse Table Upgrades (FIP-25: Existing Paimon Tables). Enable Fluss on existing Paimon tables while reusing their historical data. @luoyuxia
• 🚨 High priority: Deletion Vectors for Paimon and Iceberg Union Read (FIP-47: Paimon, FIP-31: Iceberg). Accelerate primary-key table union reads. FIP-47 provides the shared foundation for FIP-31. (FIP-31 Reviewers: @polyzos @luoyuxia)

Storage and Data Types

• Variant / JSON Support (FIP-36): complete native Variant support and shredding.
• Multi-Location Remote Storage (FIP-25: Remote Storage): complete the remaining TabletServer, cleanup, and independent authentication work. @LiebingYu

System Metadata and Observability

• 🚨 High priority: System Tables and Views (FIP-39). Provide system-managed state storage and queryable cluster metadata, including the foundation for consumer offsets and groups.
• Unified Client Metrics (FIP-56): improve operation coverage and align metric semantics across clients.

Flink and Spark Connectors

• Flink Connector Production Readiness Follow-ups: remaining improvements to batch reads, lookups, metrics, and batch writes.
• Spark Connector: Scan Optimization and DSv2 Capabilities, focusing on remaining scan, column-pruning, batch-read, and DSv2 improvements.

Clients and Stability

• Metadata Cache, Async Refresh, and Retry Improvements. @wuchong
• Bounded Write Delivery (FIP-54): add an overall delivery timeout to prevent writes from waiting indefinitely through retries.
• Leader-Epoch-Based Log Truncation.
• Reduce Server MetadataCache Footprint by Removing TableInfo.

Security

• 🚨 High priority: (m)TLS Support (FIP-29).
• Kerberos Authentication via SASL/GSSAPI (FIP-7).

[Yohahaha]

I propose releasing Spark tiering (FIP-42) as an experimental feature in version 1.1, enabling users in the Spark ecosystem to take fuller advantage of Fluss.

[fresh-borzoni]

• union read kernel(FIP-48)
• datafusion query engine(FIP-50)

[fresh-borzoni]

• Trino connector
• StarRocks native C++ integration instead of JNI one for CN nodes

[affo]

I would like to see:

• TLS (@morazow and I can own that, we just need reviewers)
• metadata observability track towards completion
• FIP-39 (already in roadmap now)

For the metadata observability, I sent already on Slack a bit of a PR tree the community generated:

We have 1 PR for supporting fetching server tags: #1410.
We have another 1 for supporting per-tablet health: #3743.
In the issue for the first PR a discussion raised about the performance of the per-tablet health,
I came up with a contribution to put that computation off-loop via a ClusterHealthCache: #4061.
The cache can be used by both per-tablet and cluster-wide health computation.

Reference: https://apache-fluss.slack.com/archives/C08EQ64K600/p1790088465293969

From @morazow

Both add APIs to read state from the cluster that today they can only get from logs or from the operator.
#4037 - Admin#getClusterVersion() (fixes #3966)
A client cannot currently ask a running cluster which Fluss version it runs. The apiVersions() returns only protocol numbers. PR adds one read-only RPC that returns the version from the server's build metadata. There's no config and no change to existing APIs.

#3985 - Admin#listRebalances() and rebalance timestamps (closes #3965)
Rebalance progress is only visible while a rebalance is running, and no records about when it started or finished. So it enables answering "when did the cluster last rebalance?" or "how long did it take?" questions without reading server logs.

Reference: https://apache-fluss.slack.com/archives/C08EQ64K600/p1790163194397839