20x P99 improvement | 50% cost reduction |
Sub-second dashboard performance
Splitmetrics is a growth engine for mobile-first companies, specializing in helping mobile app businesses scale their user acquisition. As an official Apple Ads partner, the company manages the Apple Search Ads channel and provides mobile app market analytics and advertising performance insights.
The company's flagship product, Acquire, delivers ads performance dashboards at different levels and granularities. These dashboards serve as mission-critical tools that user acquisition managers rely on daily to control campaign performance. The platform supports hundreds of metrics including custom formulas, filters across multiple dimensions, and joins across up to 10 different data sources. Some data sources update in real-time, with changes made directly on the dashboard propagating almost immediately to reflect updated campaign performance.
This dynamic, feature-rich environment creates significant technical complexity. With growing client adoption, increasing data volumes, and expanding feature sets, Splitmetrics needed a database architecture that could maintain fast, consistent query performance for customer-facing analytics at scale.
Splitmetrics faced a multi-faceted problem stemming from their product offering. As a company providing mobile app analytics and insights, they needed to maintain feature-rich dashboards for thousands of daily active users with demanding requirements:
Flexible dropdowns and custom views
Filters and sorting across multiple dimensions
Custom formulas and hundreds of metrics
No limitation on historical data querying
Real-time updates reflecting dashboard changes
Four years before their StarRocks migration, dashboard loading times reached crisis levels. User acquisition managers who relied on these dashboards daily to control campaign performance waited 3, 5, or even 10 minutes for data to load. Customers complained constantly while the database team desperately tried optimizations, adding indexes until the system could barely handle writes.
The team invested significant effort optimizing PostgreSQL through infrastructure improvements, database tuning, query rewrites, and application-level optimizations. They managed to achieve a P99 of 8 seconds, which wasn't perfect but seemed acceptable. However, over the next two years, performance degraded almost 2x as they onboarded more clients with more data and added more features and metrics. The previous optimization approaches simply didn't work anymore.
Engineers attributed the bulk of the problem to what they called PostgreSQL's "query planner hell." The platform's typical queries created massive complexity:
5-7 Common Table Expressions (CTEs) per query
10-12 joins across multiple data sources
Roughly 700-line SQL statements
PostgreSQL struggled with this complexity. One developer described it as a "butterfly effect" where a small change in one random table, like stale statistics from a delayed ANALYZE command, would completely blow up the entire query plan and trigger an avalanche of problems.
The unpredictability proved especially frustrating:
Median response time: 2 seconds (acceptable)
P99: 20 seconds (problematic)
Maximum latency: Over 5 minutes (unacceptable)
Unfortunately, these worst-case scenarios often hit the biggest, top-paying customers. The usual suspects of disk explosion from denormalization, poor caching, and unoptimized views were rampant. The team faced a critical decision: they couldn't continue with PostgreSQL's unpredictable performance, but they also couldn't afford to make the wrong technology choice for their customer-facing analytics workload.
After a rigorous 3 way benchmark against ClickHouse and PostgreSQL, Splitmetrics chose StarRocks as their real-time query engine. Their test was composed of selecting thousands of the most expensive queries they faced on PostgreSQL, and translated these queries into StarRocks and ClickHouse queries with 30+ variations of the query dataset, utilizing whatever bells and whisltes each database provided. This was conducted on an anonymized db such that engineers could make unbiased decisions.
The result of their test found a staggering 50% infrastructure cost reduction by using StaRocks, with ClickHouse 2x as expensive as their existing infrastructure.
This was just the start. What really brought the Splitmetrics team to StarRocks was:
A query planner that was predictable and performant under load
Excellent query rewrite abilities, especially when leveraged with features like asynchronous materialized views
Out of the box results that didn’t need much optimization
Clickhouse, on the other hand, riddled the team with
Poor performance results that required denormalization
Rising costs and efforts to build the infrastructure and data pipeline that Clickhouse required
Unintuitive SQL and data modeling capabilities
With their evaluations conclusive and their t’s and i’s crossed and dotted, they settled on an architecture that allowed them to bridge the best of multiple database worlds.
The architecture is designed for performance, reliability, and scale. This split data ingestion into two optimized pathways: real-time and batch.
Real-time ingestion powers the most critical customer experience: instantaneous campaign updates. When users adjust values in the dashboard, they expect to see those changes reflected immediately. Debezium streams updates from the core PostgreSQL database into Kafka, and the StarRocks sink connector delivers them into StarRocks via stream load with end-to-end latency consistently under two seconds. This unlocks true real-time interactivity for campaign management.
Batch ingestion complements this by efficiently processing large volumes of historical data that still live across multiple PostgreSQL instances. Apache Airflow orchestrates scheduled ingest using two high-performance methods:
Broker load from S3 for bulk imports
JDBC-based INSERTs through external tables for multi-source consolidation
Even with incremental loads approaching 50GB, careful JDBC tuning ensures the batch pipeline operates with stable, predictable throughput.
At the core of the system is StarRocks’ storage and compute separated architecture, chosen for its speed, concurrency, and elasticity. The team adopted primary key tables to support real-time upserts, with unique key tables powering fast, accurate aggregations.
Furthermore, the query layer includes a dedicated dashboard service that converts user interactions into SQL executed directly against StarRocks. To build confidence during rollout, the team implemented a smart fallback mechanism: if a query failed in StarRocks, it would automatically reroute to the legacy PostgreSQL service, ensuring users always received results, even if slightly slower.
In practice, the fallback became unnecessary. After six months in production, and zero major incidents, StarRocks proved exceptionally reliable for customer-facing workloads. The system now delivers the speed, freshness, and stability required for a modern analytics experience.
The shift to StarRocks improved performance and fundamentally transformed how Splitmetrics delivers customer-facing analytics.
After migration to StarRocks, the improvements were immediately visible across the board in production:
P95: 6.53s to 1.69s
P99: 30.29s to 3.35s
The consistency proved equally important. Unlike PostgreSQL's unpredictable planner, StarRocks delivered stable, fast query timing even for large data ranges and complex metrics. The team achieved very consistent P99 performance without the butterfly effect that plagued their PostgreSQL deployment.
Critical operational improvements rounded out the results:
50% infrastructure cost reduction compared to PostgreSQL
Zero major incidents after six months in production
Sub-2-second end-to-end latency for real-time dashboard updates
Predictable query performance regardless of data complexity
Splitmetrics continues expanding their StarRocks deployment with ambitious optimization goals:
Table consolidation and query simplification to expand asynchronous view use cases
Migration to S3/Iceberg architecture to eliminate PostgreSQL JDBC limitations and use StarRocks as the complete aggregation pipeline
Vector search migration from pgvector to StarRocks' native vector search capabilities for improved performance
MCP server for AI agent analytics leveraging StarRocks as the analytical backend for their Iris AI agent
Want the story straight from the source? In this StarRocks Summit 2025 session, SplitMetrics’ Solutions Architect Grisha Lira shares the hard parts, the tradeoffs, and the turning points of rebuilding their dashboards’ backend. It’s candid, practical, and full of lessons you can borrow for your own stack. Watch the video below.