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
