From Hours to Seconds: How Yuno Accelerated Customer-Facing Analytics By Switching Off Snowflake and Athena

About Yuno

Yuno is a fast-growing fintech company that provides payment orchestration and merchant analytics across Latin America. Its platform connects merchants to hundreds of payment providers, helping them optimize routing, monitor performance, and improve conversion in real time.

With hundreds of merchants and millions of daily transactions, Yuno's business relies on delivering insights instantly. Every second of delay can affect customer satisfaction and revenue.

The challenge

Customer-facing workloads and requirements

Yuno's analytics platform powers a range of customer-facing workloads that demand speed and scale, including:

• Merchant dashboards for real-time approval, decline, and fraud monitoring
• Conversion funnel analytics combining checkout behavior with payment outcomes
• Routing optimization tools that help merchants dynamically adjust providers

To support these workloads, the data platform needed to become a real-time analytics layer capable of handling:

• Concurrency: hundreds of simultaneous dashboard queries from merchants
• Latency: sub-second response times for interactive workloads
• Freshness: data updated within seconds of each transaction

These requirements outgrew Yuno's Snowflake-based architecture and drove the search for a new analytics solution.

The previous architecture

Yuno operated a hybrid data stack centered on Snowflake for analytics and Athena/Hudi for historical reporting. The system was designed for batch analytics, not for high-frequency updates or real-time dashboards.

Core components

• Snowflake: main analytical warehouse for real-time dashboards and reports
• Snowpipe + dbt: data ingestion and transformations
• Athena on Hudi (S3): historical data and ad-hoc or long-tail queries

Operational model

• Each use case or team had its own Snowflake warehouse to avoid concurrency limits.
• Data was loaded in batches and merged periodically, often taking more than an hour to propagate.
• Analytics teams maintained two separate query systems, Snowflake for live dashboards and Athena for deep history, which resulted in duplicated logic and fragmented governance.

Where it fell short

The dual-system setup could no longer keep pace with Yuno's growing customer-facing workloads:

• Data freshness: Data latency frequently exceeded one hour, far from the second-level goal.
• Latency: Query response times could reach several seconds during peak load.
• Concurrency: Snowflake's warehouse isolation limited scalability; supporting more users required provisioning new warehouses.
• Scalability: As data volume grew to terabytes, with hundreds of tables and billions of rows, performance degraded and maintenance effort increased.
• Data model complexity: The main analytics table, a large "flattened" schema, combined numerous joins from transaction and event data. Over time, this table became massive and slow to maintain, with query latency compounding as data volume grew.
• Complexity and cost: Managing two analytical systems was operationally heavy. Each required separate tuning, security, and governance.

Yuno needed a solution that could unify real-time ingestion, fast queries, and cost efficiency.

The solution

Evaluating the next solution

The team evaluated multiple technologies, including ClickHouse, Apache Druid, and PhoenixAI (powered by StarRocks).

ClickHouse offered strong query performance but lacked the lakehouse integration and native support for real-time upserts that Yuno required. Druid provided good time-series capabilities but introduced significant operational overhead and performance challenges.

PhoenixAI stood out for several reasons:

• Unified real-time and federated analytics: StarRocks can federate real-time data in its internal storage format and external tables on Hudi/S3 with full SQL semantics.
• Native support for upserts from CDC sources: Second-level data freshness without impacting query performance.
• Materialized views and shared-data architecture: High concurrency and sub-second response times even at large scale.
• High performance: PhoenixAI's fully vectorized C++ engine and cost-based optimizer deliver consistently low-latency queries, even under high concurrency.

After a successful proof of concept, where PhoenixAI handled 500 queries per second with sub-second latency and second-level freshness, Yuno decided to migrate its customer-facing workloads.

The new architecture

Yuno's new analytics platform is built around PhoenixAI as the central query engine, directly connected to its operational data and data lake:

• Sources: Streaming data sources flow through Flink CDC, are preprocessed, and are ingested into PhoenixAI's primary-key tables.
• Data lake: Historical datasets remain in Hudi on S3, accessible via federated queries.
• Processing: PhoenixAI maintains both synchronous materialized views (for near-instant aggregation) and asynchronous materialized views (for complex precomputations on large joins).
• Access layer: Merchant dashboards and internal tools query PhoenixAI directly through APIs, achieving 5–10 seconds of data freshness across transactional and aggregated data.

This architecture removed the need for separate batch and streaming systems and lets Yuno serve both live and historical analytics from a single source of truth.

Implementation

The migration was executed in phases:

• Schema redesign: Yuno moved from a massive flattened table to a set of primary-key tables optimized for upserts and incremental refresh.
• Materialized views: Critical dashboards (for example, merchant conversion rates and provider success metrics) were powered by synchronous MVs with sub-second latency. More complex metrics used asynchronous MVs that refreshed every 20–30 seconds.
• Partitioning optimization: Early ingestion issues were mitigated by switching from daily to monthly partitions, which drastically reduced IOPS and improved stability.
• CI/CD and metadata governance: PhoenixAI was integrated with Yuno's deployment pipeline. Every schema or column change required metadata annotations and was automatically propagated to PhoenixAI, building a semantic layer for downstream analytics and LLM-driven query generation.
• LLM and self-service analytics: Yuno built an internal layer where users type natural-language questions, which an LLM converts to SQL queries on PhoenixAI. The system reuses metadata and sample data to generate charts and dashboards automatically.
• Observability and troubleshooting: The team improved ingestion reliability and visibility, adding monitoring for partition health, versioning, and MV refresh status to prevent earlier stability issues.

The results

After migrating to PhoenixAI, Yuno achieved measurable improvements:

• Query latency: Reduced from ~3 seconds on Snowflake to under 1 second for most dashboards.
• Data freshness: Improved from 1 hour to around 5 seconds for core transactional data.
• Concurrency: Hundreds of concurrent dashboard queries supported without performance degradation.
• Cost efficiency: Eliminated the need for multiple Snowflake warehouses and reduced compute cost per query by over 40%.
• Reliability: The shared-data architecture and optimized partitioning significantly improved ingestion stability.

Operational teams can now monitor provider performance, identify conversion drops, and adjust routing rules in real time.

What's next

Yuno continues to evolve its analytics platform with PhoenixAI. Next steps include:

• Integrating S3 Express One Zone for lower latency and lower cost of hot data storage.
• Enhancing LLM-driven analytics by expanding the internal knowledge base with query examples and column semantics.
• Improving disaster recovery and metadata resilience to further harden ingestion during upgrades and reboots.
• Expanding customer-facing analytics to new regions and product lines.