Who is using Apache Fluss?

[wuchong]

Apache Fluss is growing with the support of its users and contributors. We would like to better understand how organizations are using or evaluating Fluss in real-world scenarios.

The provided information may be displayed on the official Apache Fluss website.

Please reply using the following format:

• Organization logo: Please provide a public URL or attach the logo
• Organization:
• Region:
• Type: End User / Vendor / Ecosystem Integration / Research
• Use cases:
• Public references: Blog posts, talks, documentation, or other public links
• Contact: GitHub handle or public profile

[wuchong]

• Organization: Alibaba Cloud
• Region: China
• Type: Vendor
• Use cases: Alibaba Cloud provides Streaming Storage for Apache Fluss, a fully managed cloud service built on Apache Fluss. It enables customers to create isolated, highly available Fluss instances without deploying or operating CoordinatorServer, TabletServer, or ZooKeeper nodes. The service provides visual database and table management, fine-grained access control, monitoring and alerting, and hot and cold data tiering. It integrates with Alibaba Cloud Realtime Compute for Apache Flink to support real-time data warehouses and streaming lakehouse workloads, including column pruning, partial updates, and Delta Join.
• Public references:
  • Streaming Storage for Apache Fluss — Product concepts
• Contact: @wuchong

[LiebingYu]

• Organization: Alibaba Group
• Region: China
• Type: End User
• Use cases: Alibaba Group runs Fluss as the unified real-time ingestion and serving layer for user-behavior analytics across multiple business units (Taobao, Tmall, Ele.me, Amap, Alibaba Pictures, etc.). Key internal production scenarios include:
  • User-Behavior Collection Platform (A+ Platform): Fluss ingests behavioral logs from Web, mini-programs, mobile apps, and server-side SDKs into a shared traffic-domain data layer. During Double 11 2025, the cluster sustained 4 PB/day, peaked at 100 million TPS and 100 GiB/s, while reducing overall pipeline cost by over 40% compared to the previous row-based MQ architecture.
  • A/B Testing Analysis Platform (Taotian Group): Fluss serves as the streaming source for real-time experiment evaluation covering search, recommendation, content, and user-growth experiments across 100+ scenarios. Column pruning eliminated ~70% of wasted network I/O (reading 13 of 44 fields), cut Flink job CPU by 59%, memory by 73%, and reduced 100 TB+ operator state to near zero — delivering sub-second freshness during the 618 Grand Promotion.
  • Streaming Lakehouse (Fluss + Paimon/Alake): Fluss tiering into the internal data lake replaced Lambda-style dual pipelines, providing second-level freshness with minute-level lake availability and enabling cheaper batch backfills via partial-column updates.
• Public references:
  • How Taobao uses Apache Fluss (Incubating) for Real-Time Processing in Search and RecSys
  • Taobao Instant Commerce: Real-Time Decisions at Scale with Apache Fluss
  • Fluss at Alibaba Double 11: Trillion-Scale Production Practice
• Contact: @LiebingYu

[zuston]

Organization: IQIYI
Region: China
Type: End User
Use cases: Using Fluss to Support Massive-Scale Real-Time Ingestion and Ultra-Low-Latency PK Lookups

1. Fluss PK Tables as a Disaggregated State Alternative for Flink

   Flink jobs with massive state often suffer from slow recovery, while the state itself is difficult to query and inspect. By using Fluss PK tables as a schema-enforced state store, iQIYI achieves a P99 lookup latency of under 1 ms at a production workload of 100K QPS.

2. Long-Term ML Feature Backfilling

   Fluss Log Tables serve as a streaming data source for long-term ML feature backfills. Compared with Kafka, Fluss provides significantly longer data retention at a comparable storage cost. Features such as column pruning also substantially improve Flink consumption performance.

   Combined with the disaggregated state architecture, a Fluss cluster with 10 tablet servers can handle up to 1M QPS for backfill workloads, enabling one day of data to be backfilled in approximately 30 minutes.

3. Tiered Storage for Hot-Cold PK Tables

   Real-time ML feature-tag enrichment requires both ultra-low latency and extremely high ingestion throughput. Fluss PK tables support real-time ingestion at up to 20 GB/s, while the tiering service uses Paimon to provide fallback lookups for cold data.

   Compared with the previous HBase-based solution, this architecture reduces costs by approximately 50% while providing more predictable ingestion and lookup latency.

Contact: @Junfan Zhang

[affo]

• Organization: Ververica
• Region: Europe
• Type: Vendor
• Use cases: Ververica provides Streaming Storage solutions built on top of Apache Fluss as self-managed deployments (currently in private preview). It enables customers to run instances of Fluss clusters on their premise. The installation provides a console for visually and programmatically manage Fluss clusters: from databases/tables operations and lake tiering management to rebalancing data and scaling in/out. The installation is integrated with Ververica's Platform offering to support real-time data warehouses and streaming lakehouse workloads.
• Public references:
  • Apache Fluss - Ververica Docs
• Contact: @affo

[fresh-borzoni]

• Organization: Fresha

• Region: Europe (United Kingdom)

• Type: End User, Ecosystem Integration

• Use cases: Fresha is the booking and payments platform for the beauty and wellness
  industry with over 130,000 partner businesses and more than 35 million appointments a month.
  We run Apache Fluss self-managed on Amazon EKS as the real-time serving layer
  between our operational databases and our analytical stack, and we maintain the Kubernetes
  deployment and multi-language client work upstream in the project. Our main scenarios:

  • Denormalizing transactional hierarchies with Delta Join. Our commerce domain is a deep
    parent-child hierarchy. Producing wide, query-ready rows from it with regular streaming
    joins meant carrying the whole history of every level in Flink state, where recovery time,
    not throughput, was the real constraint. Storing each level as a Fluss primary-key table
    with bucket.key set to the join key makes different join patterns eligible for Flink's
    Delta Join: each arriving row does a prefix lookup against the other side instead of both
    inputs being materialized. Operator state for the pipeline drops to effectively zero, and
    recovery that previously took tens of minutes now completes in seconds.

  • Elixir-native access to Fluss. Our application stack is predominantly Elixir, so a
    Flink-only client was never going to give us tight integration with it. Fresha contributes
    the Rust core client and the Elixir bindings built on top of it, establishing a solid base
    for application services to work with Fluss directly in a BEAM-friendly way.

  • Self-managed on public-cloud Kubernetes. Fluss runs on EKS with 3 tablet servers, S3
    remote storage authenticated through IRSA, and the community Helm chart. We worked with the
    community to make this a reliable, documented path on the major public clouds, contributing
    the missing pieces as we hit them. This is the stock Apache release with no vendor
    distribution underneath it. Three Fresha engineers contribute to the project.

• Public references:

  • Bottling the River: Apache Fluss on EKS
  • What the Fuss with Fluss: Flink Delta Force
  • What the Fuss with Fluss: Flink 2.2 Delta Force
  • Processing Patterns with Apache Fluss
  • The Rise of the Streamhouse — QCon London 2026

• Contact: @fresh-borzoni

[hanliu0830]

• Organization: rednote (Xiaohongshu)
• Region: China
• Type: End User
• Use cases: At RedNote, we use Apache Fluss as a key part of our real-time data infrastructure for both real-time indexing and data warehouse workloads. In indexing pipelines supporting search, recommendation, and advertising, we use Fluss’s column pruning to read only the required columns, reducing wide-table read amplification. Fluss’s tiered storage also enables us to read historical data directly from object storage, reducing the impact of batch index builds on online serving workloads. In data warehouse workloads, we combine Fluss primary key tables with Paimon-based lake tiering to support real-time updates and persist streaming data in the data lake, connecting real-time processing, historical data processing, and batch analytics. Together with Apache Flink and Apache Paimon, we are building an integrated data pipeline spanning real-time writes, streaming consumption, data updates, lake tiering, and analytics.
• Public references: From Kafka to Fluss: How Rednote Migrated a Core Real-Time Indexing Pipeline
• Contact: @hanliu0830