As digital experiences become more personalized and data-driven, many companies face mounting pressure to deliver fast, self-serve analytics—without driving up costs or adding architectural complexity. But achieving that balance is difficult, especially when historical and real-time data live in different systems.

This case study highlights how Fanatics, a global leader in sports merchandise, consolidated their fragmented analytics stack into a unified, open lakehouse powered by StarRocks and Apache Iceberg. The result: sub-second dashboards, lower cost, and faster iteration for hundreds of internal users—across petabytes of data.

What is Fanatics

Fanatics is a global digital sports platform and the official e-commerce partner of all major U.S. sports leagues. The company manages over 900 online stores, serving more than 100 million customers worldwide and offering a product catalog of 14 million products.

Behind the scenes, Fanatics processes around 1 billion events daily from 800+ event types, spread across 120,000+ datasets. Data fuels everything from on-site personalization to internal decision-making. For the company, enabling fast, reliable, and cost-effective analytics is critical to maintaining their competitive edge.

Legacy Architecture and Challenges

Fanatics’ previous architecture spanned multiple engines and storage layers:

• Data warehouses: Amazon Redshift and Snowflake
• Data lake: S3 queried via Athena (often with >30s latency)
• Real-Time layer: Druid, used for real-time dashboards

This setup resulted in performance bottlenecks, rising costs, and increased operational complexity.

• Interactive queries on Athena were too slow for real-time use cases (>30s median latency)
• Cross-warehouse joins were impractical, forcing teams to maintain redundant data copies
• Druid couldn’t support complex requirements like fact-to-fact joins, primary-key updates, or point lookups
• High warehouse and data transfer costs due to overlapping workloads and fragmented data ownership
• Inconsistent governance and lack of clear ownership across tools and teams
• Forced denormalization: Every piece of data needed to be denormalized due to join limitations of the underlying engines, which creates duplicated data across systems and costly preprocessing pipelines

Alternatives Considered

Fanatics evaluated other OLAP engines including ClickHouse, but found similar limitations around join capabilities and operational integration. They ultimately selected StarRocks for its fast, full-featured query engine, native support for Glue Catalog, and asynchronous materialized views with automatic query rewrite.

New Architecture

Fanatics adopted a modern lakehouse architecture built on:

• Apache Iceberg as the open table format, with S3 as the source of truth
• StarRocks as the high-performance query and serving layer
• AWS Glue Catalog as the central metadata store
• dbt Core for transformations, with Superset and a Bedrock-based text-to-SQL agent for visualization and access

Ingestion and Table Design

Fanatics supports several ingestion patterns into StarRocks:

They design tables with workload in mind:

• Primary-key tables for fast reads and real-time update support
• Duplicate-key tables for high-throughput append-only data
• Tablet sizes are optimized (~1 GB), and tenant-aware partitions are carefully designed to avoid skew and small files

Performance Optimization

To improve query speed and concurrency, Fanatics applies several techniques:

• Async materialized views (AMVs) are used selectively for the hottest workloads, with fine-tuned refresh windows and partition alignment. Query rewrite made sure there is no manual sql rewrites.
• EXPLAIN/ANALYZE are used to validate plan efficiency, pruning, and pushdown
• Colocate and shuffle join strategies are monitored and tuned to reduce inter-node I/O
• Multi-stage aggregation is configured where needed to support high-cardinality metrics

Caching and Storage

Fanatics takes a layered approach to performance:

• Most queries hit Iceberg base tables directly, with data cache enabled to keep hot data blocks local
• Async materialized views are only introduced when base table performance isn’t sufficient
• StarRocks runs on EC2 with EBS for shared-nothing deployments today, with a roadmap toward shared-data clusters for elastic scaling

Results

• Apache Druid was eliminated for real-time dashboards, yielding significant savings while enabling joins, PK updates, and point lookups on the same platform.
• Snowflake footprint and cost dropped substantially; as reported, usage was reduced by up to 95% and cost savings were ~90% after consolidation of use cases.
• Fanatics now hosts multiple thousands of tables, views, and AMVs on a single StarRocks cluster, with multiple petabytes of Iceberg data accessible through one query layer.
• Dashboards that previously took hours/days/weeks can now be assembled in minutes, as reported.

Future Work

• Broaden AI usage (e.g., conversational analytics across multiple datasets).
• Wider adoption of Streamlit for lightweight apps on top of the platform.
• More automation (toward “touchless” onboarding of new databases/tables).
• Cluster metadata backup/restore to strengthen disaster recovery.
• Unify BI tooling under StarRocks as the standard serving platform.

StarRocks+Apache Iceberg

Fanatics’ journey shows how large-scale organizations can simplify their analytics architecture, reduce cost, and accelerate access to insights—by combining open table formats with a high-performance query engine. By unifying streaming and batch analytics on a single stack, they now serve real-time and historical workloads more efficiently, with greater flexibility and control.

Join the StarRocks community on Slack