[docs] Document COMPACTED table format

[Priyamanjare54]

Purpose

Linked issue: closes #2256

This pull request adds documentation for the COMPACTED table format on the Fluss
website to help users understand what it is, how to configure it, and when it
should be used.

Brief change log

• Added documentation for the COMPACTED table format under table design
• Explained supported table types (Log and KV tables)
• Documented usage with table.changelog.image=WAL and its performance benefits
• Added guidance on recommended use cases and limitations

Tests

Not applicable. This change only affects documentation.

API and Format

No. This change does not affect any public API or storage format.

Documentation

Yes. This PR introduces new user-facing documentation for the COMPACTED table
format on the Fluss website.

[wuchong]

Hi @Priyamanjare54 , it seems this change is empty.

[wuchong]

Thanks @Priyamanjare54 , could you update the pull request according to the discussion and proposed structure in #2256 (comment)?

[Priyamanjare54]

Thanks for the feedback!
I’ve updated the PR to introduce a dedicated Data Encodings page and moved the COMPACTED documentation under it as discussed in #2256.
The earlier standalone COMPACTED page has been removed accordingly.

Please let me know if you’d like any further adjustments.

[wuchong]

@polyzos could you help to review this doc?

[polyzos]

@wuchong Regarding the Indexed format, is it going to be deprecated, or should we document it as well?
@Priyamanjare54 Thank you for your contribution.
It’s great documenting, however we want to make it as simple as possible, so every user can easily understand the formats and when they should use each and with a current approach, I’m cautious that less technical users might find it a bit harder to understand.

For example we can say that the arrow format is the default one, its benefits and that it allows operations such as column pruning and predicate push down.

However for tables that don’t have such requirements, such as large vector tables maybe, aggregates and joined tables that we select all columns a compacted format might be a better fit for disk and CPU efficiency.

WDYT? If you need more context I can help craft this

[Priyamanjare54]

Thanks for the feedback @polyzos! I appreciate the guidance on making this more accessible. I agree that simplifying the explanation will help users better understand when to use each format.

Regarding the Indexed format - could you clarify if this should be included or if it's being deprecated? I want to make sure I'm documenting the right formats @wuchong .
I'll work on a revision based on your suggestions.

[Priyamanjare54]

Hi @polyzos @wuchong, just following up on my question from 2 days ago could you please confirm the status of the Indexed format so I can proceed with the revision? Thanks!

[wuchong]

+1 to remove the indexed format from the doc.

[Priyamanjare54]

Thanks for confirming! I’ll proceed with removing the Indexed format from the documentation and update the PR accordingly.

[polyzos]

@Priyamanjare54 this is great work 👌 I think before merging we can just a few things as “summaries”, like in the beginning add a quick section in terms of “of how to think about encodings”:

How to Think About Encodings in Fluss

In Fluss, a data encoding primarily determines:

• How data is laid out on disk (columnar vs row-oriented)
• How efficiently data can be filtered, projected, and scanned
• Whether the encoding is optimized for streaming scans or key-based access

Encodings in Fluss determine:

• CPU vs IO tradeoffs
• Scan-heavy vs lookup-heavy workloads
• Analytical vs operational access patterns

And then we can add a table with the exact tradeoffs maybe in the bottom of the page.

ARROW vs COMPACTED

Encoding	ARROW	COMPACTED
Physical layout	Columnar	Row-oriented
Typical access pattern	Scans with projection & filters	Full-row reads or key lookups
Column pruning	✅ Yes	❌ No
Predicate pushdown	✅ Yes	❌ No
Storage efficiency	Good	Excellent
CPU efficiency	Better for selective reads	Better for full-row reads
Log encoding	✅ Yes	✅ Yes
KV encoding	❌ No	✅ Yes
Best suited for	Analytics, streaming analytics	State tables, materialized views

WDYT?

[Priyamanjare54]

Thanks for the suggestions! I’ve added a short “How to Think About Encodings in Fluss” section near the top and included an ARROW vs COMPACTED comparison table summarizing the trade-offs.