Hi Mehul and everyone, Congratulations to the entire Fluss community on the graduation votes passing! This is a huge milestone — thanks to all the mentors, PMC members, and contributors who made this happen.
The meetup recap is excellent. A few quick notes: - +1 on proceeding to VOTE for both the TLS (FIP-29) and K8s Operator (FIP-41) FIPs — both proposals have received thorough review and are in good shape. - The narrowed scope for the Vector data type (FIP-44) makes sense — starting with a minimal FIP + POC is the right call. - The deletion-vectors benchmark for Paimon (10s → 1s drop time) is impressive. Looking forward to Yuxia's FIP. Best regards, Zhe Wang Mehul Batra <[email protected]> 于2026年7月4日周六 19:53写道： > Hi Otters, > > First and foremost, it fills me with immense pride to share that Fluss's > graduation votes have passed! This is a testament to the hard work and > dedication of our entire community. To everyone who contributed code, > discussions, reviews, or just showing up please take a moment to pat > yourselves on the back. We are what we are because of this community, and I > couldn't be more excited for what's ahead. Let's keep moving forward, > together." > > > *Fluss Community Meetup - July 3, 2026* > > Meeting recording: fathom.video/share/… > <https://fathom.video/share/KKRqB5VysjrrjwKPT5z5Gdwz7g_RK3y6> > > > 1. Fluss Rust and Gateway (Junbo) DataFusion adapter exposing Fluss tables > via SQL — PostgreSQL protocol for reads, REST for writes; supports > JSON/Arrow/OTLP. Partitioned lake tables + historical snapshots are on the > roadmap. Demo showed working unified (union) read across log/PK tables via > the thin DataFusion adapter. > > > > - Decision: Integrate as a stretch item on a separate tip, merge > gradually (Anton, team). Start a community design discussion aligned > with > the Rust roadmap (Junbo). > - Next: Harden PG-read + REST-write path, add MCP support next, publish > design doc for feedback. > > 2. 1.0 Release — TLS + K8s Operator Two FIPs targeted for 1.0: TLS (led by > Lorenzo, briefly on vacation) and Kubernetes Operator. Designs are mature, > most feedback addressed. > > > > - Open question: Repo placement for the Operator (core vs. separate) — > separate repo preferred so it can ship/fix independently of core > releases. > - Decision: Proceed to voting on both FIPs (Muhammet/Lorenzo/Jark). > Operator will live in the "Fluss extensions" org, but that can't be > created > until ~0.5 month after ASF graduation completes. > > 3. Vector Type / LanceDB Integration (Sagar) Sagar's original proposal was > deeper LanceDB integration, but that needs JNI contributions to Lance core > and a zero-copy Arrow↔️vector path to avoid serialization overhead — so > scope is narrowing to a minimal Vector data type FIP + POC branch first > (spanning Fluss + Lance changes). > > > > - Broader LanceDB integration and index-maintenance strategy > (incremental updates vs. rebuilds, compaction parallels to Iceberg) > pushed > to a follow-on. > - Next: Mehul/Jark/Giannis to review the vector-type FIP against prior > art (e.g. PyMon). Sagar to reorder work to prioritize the FIP/POC. > > 4. Deletion Vectors for Paimon/Iceberg (Yuxia) POC complete for Paimon with > a design doc; benchmark on a ~10M-row table showed drop time falling from > ~10s to ~1s using Blink Batch. Iceberg is expected to follow using the same > RPC/architecture. > > > > - Open items: Convert the Google Doc into a formal FIP (currently > informal); clarify Paimon-first scope while keeping it > Iceberg-applicable; > align on unified semantics for historical-partition write/lookup. > - Decision: Yuxia publishes the FIP and kicks off dev-list discussion → > vote. Muhammet helps with the Iceberg implementation, coordinating with > Mehul's existing seed FIP for Iceberg. > > 5. Multi-Lake Support in One Fluss Cluster Known request (e.g. from Xiaomi) > to connect a single Fluss cluster to multiple lake formats (Iceberg + > Paimon simultaneously). Architecturally feasible with code changes, but not > prioritized low internal bandwidth. > > > > - Next: Junfan to consider contributing; maintainers open to community > collaboration. > > 6. Multi-Disk Ingestion (Row-Tabular Server) Addresses a single-disk > bottleneck during ingestion. Multi-disk landing code has merged to main but > is unreleased; already running in RedBook production, though stability > hasn't been validated outside that environment. > > > > - Next: Jark/Junfan to sync offline with RedBook on real-world > stability/performance before including in a release. > > 7. Hybrid PK Table Lookup — Hot in Row-Tabular, Cold in Paimon Use case: a > very large (~600TB) PK table, cost-optimized by keeping hot data in the > Row-Tabular Server and cold data in Paimon; streaming lookups mostly hit > hot, rarely cold. Jark refers to this as "historical partition lookup." > Junfan already has an internal hybrid-lookup implementation under testing > (not yet public). > > > > - Open items: Need unified semantics for historical-partition read (and > potentially write), aligned with expiration policies. > - Next: Junfan to stabilize internally, then contribute upstream; > coordinate with Yuxia (deletion vectors work) for a unified approach; > discuss submission path offline. > > Other Notes > > > > - Rust roadmap: general consensus on process/inclusion items; Gateway > fits in as a stretch item. > - Extensions org: proposed by Wang Yang; PPMC wants to wait until ASF > graduation finishes first (~0.5 month delay expected). > - Flink Forward Shenzhen talks happened; slides being translated to > English for the website (Strech Item) > - Light banter on graduation celebrations, swag, and a potential London > meetup. > > > Action Items > > > > - Start voting thread for TLS + Kubernetes Operator FIPs > - Draft Vector data type FIP, build POC, open PR > - Kick off deletion vector discussion on dev list for Paimon → FIP → > vote (Yuxia) > - Sync offline with RedBook/RedNote contributors on multi-disk ingestion > stability > > Best Regards, > Mehul Batra >
