Hi Yang, Thanks for driving this. I'd like to bring this discussion back, as we are seeing a concrete need for it on the lake tiering side.
Today the tiering state lives inside LakeTableTieringManager and is only observable through metrics, which makes it hard to answer per-table questions such as which tables are pending and how long they have been waiting. A read-only system view would give operators a straightforward SQL entry point for this, and it has also been asked for in the community [1]. One thing that may be worth aligning on is the naming of the tiering view, which appears as lake_tiering_status in one place and lake_tiering_service in another. The concrete schema could be left to the follow-up FIP-30 [2] work. Looking forward to your further feedback. [1] https://github.com/apache/fluss/issues/2362 [2] https://cwiki.apache.org/confluence/spaces/FLUSS/pages/406620906/FIP-30+Support+tracking+the+tiering+status+of+a+tiering+table Best regards, Junbo Wang > On 22 Apr 2026, at 21:12, Yang Guo <[email protected]> wrote: > > Hi community, > > I'd like to start a discussion on a new feature proposal: introducing > "system tables" to Fluss.[1] > > System tables are tables managed by the cluster itself that reflect > internal cluster state and bookkeeping information. This concept is now > well established across streaming and storage systems, like Kafka internal > topics, PostgreSQL System Catalog[2] and System Views[3], StarRocks > information_schema[4] and so on. It helps those systems in many aspects > including metadata management, operations, and maintenance. > > This proposal is to introduce system tables into Fluss, like other > systems already did. It may benefit our project in three key ways: > 1. Durable storage for system-critical metadata — preparing for more > features. such as consumer group offsets and capture DDL change events, > persisted through Fluss's own log storage (LogTablet / KvTablet). > 2. Operational visibility — exposing cluster runtime state (tablet server > registrations, bucket ISR, tiering status) via standard SQL query > interfaces for operators and downstream applications. > 3. Future ZooKeeper migration — laying the groundwork to move > ZooKeeper-held metadata into Fluss itself, reducing external dependencies. > > For more details, the full draft is available here: FIP-39 > https://cwiki.apache.org/confluence/display/FLUSS/FIP-39%3A+Introduce+System+Tables > > I'd really look forward to any of your thoughts and suggestions. Any > feedback is welcome. > > Links: > [1] FIP-39 Introduce System Tables: > https://cwiki.apache.org/confluence/display/FLUSS/FIP-39%3A+Introduce+System+Tables > [2] PostgresSQL System Catalog doc: > https://www.postgresql.org/docs/current/catalogs.html > [3] PostgresSQL System View doc: > https://www.postgresql.org/docs/current/views.html > [4] StarRocks Information Schema doc: > https://docs.starrocks.io/docs/sql-reference/information_schema/ > > Best Regards, > Yang Guo
