Why We Moved Our Analytics Engine from MongoDB to ClickHouse

As a reporting platform built for Jira Service Management ,View26 Charts and Reports helps teams turn their project data into actionable insights through charts, KPIs, dashboards, and detailed tabular reports. As our customers’ datasets grew into the millions of rows, we knew it was time to rethink the foundation powering it all.

This is the story of why we migrated from MongoDB to ClickHouse, what we learned along the way, and where we’re headed next.

The Challenge: When Your Database Wasn’t Built for Analytics

MongoDB served us well in our early days. Its flexible document model made it easy to iterate quickly and ship features fast. But as our platform matured and our customers started tracking increasingly complex Jira workflows, we began running into a fundamental limitation: MongoDB is a general-purpose database, not an analytical one.

Our customers rely on us to aggregate, slice, and visualize their Jira data in real time. They build KPI dashboards that compute metrics across hundreds of thousands of issues. They generate trend charts spanning months or years of project history. Some of our power users manage datasets exceeding two million rows — and they expect every chart, metric, and report to load without hesitation.

We needed a database that was purpose-built for these kinds of analytical workloads.

Why ClickHouse

After evaluating several options, ClickHouse stood out for a few key reasons:

Columnar storage built for aggregation. Unlike row-oriented databases, ClickHouse stores data by column, which means analytical queries (the kind that power dashboards and KPI calculations) can scan only the columns they need. For a reporting platform like ours, this is a natural fit.

SQL-native query engine. Moving from MongoDB’s aggregation pipeline to standard SQL made our query layer more maintainable, more testable, and more accessible to our engineering team. Complex reporting logic that previously required multi-stage pipeline configurations could now be expressed in clean, readable SQL.

Compression and storage efficiency. ClickHouse’s columnar compression dramatically reduces the storage footprint of large datasets. For a platform handling diverse customer workloads, efficient storage translates directly to better resource utilization.

Scalability by design. ClickHouse was built from the ground up to handle analytical queries over massive datasets. While our current workloads don’t push the boundaries of what ClickHouse can do, we’re investing in a foundation that will scale alongside our customers’ growing data needs.

What We Learned Along the Way

No migration is without its surprises, and we want to be transparent about what we encountered. To ground this in something concrete: we benchmarked the view-fetch operation, which is the request that backs every report load in our product, across 3,129 real customer views on global-residency accounts, comparing the same data served from MongoDB and ClickHouse side by side. The picture that emerged is more nuanced than a single “ClickHouse is faster” headline.

The shape of the distribution tells the story better than any single average. ClickHouse loses ground in the sub-100ms tier (MongoDB: 557, ClickHouse: 230), which represents the small, simple queries where MongoDB’s indexed lookups are hard to beat. It also gives up ground in the 1 to 3 second bucket, which is dominated by mid-size row-dense table views. But in the heavy 3-second-plus tiers, the two databases converge, and as we’ll see, when ClickHouse wins on those queries, it wins big

Aggregation workloads shine. The queries powering our charts, KPIs, and computed metrics — the core of what our customers interact with daily — mapped naturally to ClickHouse’s strengths. Aggregation-heavy operations across large datasets are exactly what a columnar engine is optimized for.

Large tabular exports required rethinking. One area where we invested significant engineering effort was optimizing how we serve large, row-dense table views. Columnar databases are optimized for scanning and aggregating data, not necessarily for returning large result sets row by row. This pushed us to implement smarter pagination strategies, asynchronous data loading, and more efficient data serialization — improvements that ultimately benefit the user experience regardless of the underlying database.

Schema design is a different discipline. Moving from MongoDB’s flexible document model to ClickHouse’s structured columnar format required us to think carefully about how we model data. Denormalization strategies, sort key selection, and partition design all matter in ways they simply don’t in a document database. This was a meaningful investment, but one that gave us a much deeper understanding of our own data patterns.

Widget-dense reports exposed network round-trip costs. This one caught us off guard. Many of our customers build comprehensive reports with 30 or more widgets — each chart, KPI, or table representing an independent analytical query. In MongoDB, we could bundle and optimize these queries with relative ease. With ClickHouse, each widget triggers its own query to the database, and on reports with high widget counts, the cumulative round-trip latency adds up. A dashboard with 10 widgets loads snappily; a report with 40 widgets feels noticeably slower. This is less about ClickHouse’s query performance and more about the architecture of how we dispatch and resolve queries — a problem we’re actively tackling through query batching, parallel execution, and intelligent prefetching. It’s a solvable problem, but one we want to be upfront about because it affects our most engaged power users the most.

The Honest Tradeoffs

We’d be doing a disservice to anyone considering a similar migration if we didn’t lay out the tradeoffs clearly.

ClickHouse was faster on 1,374 views (44%), and slower on 1,755 views (56%). But the headline number hides the more interesting detail: when ClickHouse won, it won by an average of 4.25 seconds. When it lost, it lost by 2.48 seconds. The wins are nearly twice as large as the losses, and the wins are concentrated in exactly the workloads that matter most for a reporting product, namely aggregation-heavy dashboards over large datasets. The losses cluster around small, simple lookups and row-dense exports, which we have other levers to address (smarter pagination, caching, query dispatch).

The clearest way to see this is to group views by approximate dataset size. Our customer base spans views scanning anywhere from around 10,000 rows on the small end to roughly 2 million rows for our largest power users, with everything in between.

The pattern is striking. On the smallest views (around 10,000 rows), ClickHouse wins only 5% of the time. As dataset size grows, the win rate climbs steadily: 50% at around 75,000 rows, 55% at around 250,000 rows, and then it flips decisively.

For views scanning roughly 500,000 to 1 million rows, ClickHouse was faster 88% of the time, saving an average of 3 seconds per load. For the largest views, those scanning 1 to 2 million rows, ClickHouse was faster 94% of the time, saving an average of 11 seconds per load.

This is the curve that matters for our customers. The users who feel database performance most acutely are the ones with the largest datasets and the most complex reports. Those are exactly the users ClickHouse helps the most. The losses on small queries are real, but they’re losses in the regime where everything is already fast enough that the difference is imperceptible.

What got better: aggregation queries over large datasets, SQL-based maintainability, compression efficiency, and a clear path to scale.

What got harder: large row-dense table views, high-widget report load times, and the operational learning curve of running a columnar database tuned for a very different access pattern than what we were used to.

What’s still in progress: optimizing query dispatch for widget-heavy reports, fine-tuning materialized views, and continuing to improve cold-start performance for first-time dashboard loads.

We don’t view these tradeoffs as failures. They’re the natural cost of making an architectural bet on the future. The important thing is that we understand them clearly and are investing in solving them.

The Bigger Picture

This migration was never just about switching databases. It was about aligning our infrastructure with our product vision.

View26 Charts and Reports exists to make Jira data useful. That means fast dashboards, reliable KPIs, and reports that teams can trust to make decisions. Choosing ClickHouse was a deliberate investment in the analytical backbone of our platform, one that positions us to deliver richer insights, handle larger datasets, and build more sophisticated reporting features in the future.

We’re still early in unlocking everything ClickHouse makes possible. Materialized views for precomputed metrics, more advanced time-series analysis, and real-time aggregation pipelines are all on our roadmap. The foundation is in place, and we’re excited about what we’re building on top of it.