How SplitMetrics Replaced PostgreSQL with StarRocks for Customer-Facing Analytics

About SplitMetrics

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. User acquisition managers rely on these dashboards 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, and changes made directly on the dashboard propagate almost immediately to reflect updated campaign performance.

With growing client adoption, increasing data volumes, and an expanding feature set, SplitMetrics needed a database architecture that could keep query performance fast and consistent for customer-facing analytics at scale.

The challenge

SplitMetrics maintains 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 the StarRocks migration, dashboard loading times had become a serious problem. User acquisition managers waited 3, 5, or even 10 minutes for data to load. Customers complained, and the database team kept adding indexes until the system could barely handle writes.

The team invested significant effort in optimizing PostgreSQL through infrastructure improvements, database tuning, query rewrites, and application-level optimizations. They reached a P99 of 8 seconds, which was not perfect but seemed acceptable. Over the next two years, however, performance degraded almost 2x as they onboarded more clients with more data and added more features and metrics. The earlier optimization approaches no longer worked.

Query planner hell

Engineers attributed most of the problem to what they called PostgreSQL's "query planner hell." A typical query on the platform had:

• 5–7 common table expressions (CTEs)
• 10–12 joins across multiple data sources
• Roughly 700 lines of SQL

PostgreSQL struggled with this complexity. One developer described it as a "butterfly effect": a small change in one table, such as stale statistics from a delayed ANALYZE command, would blow up the entire query plan and set off a chain of problems.

The unpredictability was the hardest part:

• Median response time: 2 seconds (acceptable)
• P99: 20 seconds (problematic)
• Maximum latency: over 5 minutes (unacceptable)

These worst cases often hit the biggest, top-paying customers. The usual problems were also present: disk growth from denormalization, poor caching, and unoptimized views. The team could not continue with PostgreSQL's unpredictable performance, but they also could not afford the wrong technology choice for a customer-facing analytics workload.

The solution

Evaluating StarRocks, ClickHouse, and PostgreSQL

SplitMetrics ran a three-way benchmark of StarRocks, ClickHouse, and PostgreSQL. The team selected thousands of the most expensive queries they ran on PostgreSQL and translated them into StarRocks and ClickHouse queries, with 30+ variations of the query dataset, using whatever features each database provided. The test ran on an anonymized database so engineers could make unbiased decisions.

The test showed a 50% infrastructure cost reduction with StarRocks, while ClickHouse came out 2x as expensive as the existing infrastructure.

Beyond cost, what brought the team to StarRocks was:

• A query planner that was predictable and performant under load
• Strong query rewrite abilities, especially combined with asynchronous materialized views
• Good results out of the box, without much optimization

ClickHouse, on the other hand, showed:

• Poor performance results that required denormalization
• Rising costs and effort to build the infrastructure and data pipeline ClickHouse required
• Unintuitive SQL and data modeling capabilities

StarRocks was chosen as the real-time query engine.

The architecture

The architecture is designed for performance, reliability, and scale. Data ingestion is split into two pathways: real-time and batch.

Real-time ingestion

Real-time ingestion powers the most critical customer experience: instant 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.

Batch ingestion

Batch ingestion processes large volumes of historical data that still live across multiple PostgreSQL instances. Apache Airflow orchestrates scheduled ingestion using two 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 keeps the batch pipeline's throughput stable and predictable.

Storage and query layer

At the core of the system is StarRocks' storage-compute separated architecture, chosen for its speed, concurrency, and elasticity. The team uses primary key tables to support real-time upserts, and unique key tables for fast, accurate aggregations.

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 added a fallback: if a query failed in StarRocks, it was automatically rerouted to the legacy PostgreSQL service, so users always received results, even if slightly slower.

In practice, the fallback was not needed. After six months in production with zero major incidents, StarRocks proved reliable for customer-facing workloads.

The results

After the migration, production query latency improved across the board:

• P95: 6.53s to 1.69s
• P99: 30.29s to 3.35s

Consistency mattered as much as speed. Unlike PostgreSQL's planner, StarRocks delivered stable query times even for large data ranges and complex metrics, and P99 stayed consistent without the butterfly effect the team had seen on PostgreSQL.

Operational results:

• 50% infrastructure cost reduction compared to PostgreSQL
• Zero major incidents after six months in production
• Under two seconds end-to-end latency for real-time dashboard updates
• Predictable query performance regardless of data complexity

What's next

SplitMetrics continues to expand its StarRocks deployment:

• Table consolidation and query simplification to extend the use of asynchronous materialized views
• Migration to an S3/Iceberg architecture to remove PostgreSQL JDBC limitations and use StarRocks as the complete aggregation pipeline
• Moving vector search from pgvector to StarRocks' native vector search for better performance
• An MCP server for AI agent analytics, with StarRocks as the analytical backend for the Iris AI agent

Grisha Lira, Solutions Architect at SplitMetrics, describes the rebuild of the dashboards' backend, including its tradeoffs, in a StarRocks Summit 2025 session.