From minutes to milliseconds, without changing a single KPI.
NPP, our telecom analytics platform, was outgrowing SQL Server. In our own test environment we measured whether ClickHouse could take over its reporting layer: same hardware, same report logic, and every result compared value by value.
Summary of results
In plain English
A daily report that took 19.4 seconds on SQL Server came back in 0.02 seconds on ClickHouse.
A monthly report that took over 4 minutes came back in 0.024 seconds.
Every number stayed the same: all KPIs matched.
No per-core licence fees for self-hosted ClickHouse
Estimate · depends on scenarioClickHouse is open source (Apache 2.0), so self-hosting it carries no per-core software licence fees. Depending on the SQL Server edition, core count and existing agreements, moving the reporting layer can save several thousand pounds or more. Infrastructure, support, operating costs and any remaining commercial licences still apply, so any saving depends on the scenario and is not guaranteed.
The challenge
A platform that works, and a data layer reaching its limits.
NPP has run telecom reporting in production for years. As traffic grew, so did the cost of answering questions on SQL Server: every monthly report scans a very large table, and storage and backups grow by terabytes.
- 01Reports measured in minutesMonthly reports took several minutes each; daily reports took seconds to tens of seconds.
- 02Storage and backups growing fastBillions of rows held across row-based tables with supporting indexes, all backed up nightly.
- 03Zero tolerance for different numbersOperations teams rely on these KPIs every day. A faster platform that changed even one value would be worthless.
Approach
A fair test, then a strict one.
We designed the benchmark so that a sceptical engineer could repeat it and reach the same answer.
Equal servers
Both databases on identical 4 vCPU, 16 GB cloud servers with the same storage class.
Real report logic
The platform’s own report queries and KPI formulas, not simplified benchmarks.
Production-like tables
SQL Server tables built exactly as in production, compression and indexes included.
Value-by-value checks
Every row of every report compared on all 13 KPIs, using SQL Server’s exact rounding rules.
Results
Explore the benchmark.
Choose a measure and a report. Every figure below was measured in the benchmark study.
SQL Server vs ClickHouse
Report
By switch
“All KPIs matched” means every value we tested was identical on both platforms, for the reports and data in this study. It does not guarantee identical results for every future query. As with any migration, a parallel run on live data is good practice before switching over.
Bars are to scale: on a linear scale ClickHouse is a sliver. Tick Log scale to compare them more easily.
Why not just tune SQL Server?
Daily and monthly reports on SQL Server can be made faster by adding more indexes. But every extra index has a cost:
- More storageEach index keeps another copy of the data it covers, so storage and backups grow further.
- More to manageIndexes need regular rebuilding and statistics updates as data grows, and new reports often need new indexes.
- Slower loadingEvery index has to be updated as each batch of records is loaded, so loading takes longer.
ClickHouse gets its speed from the way it stores data, with pre-summed report projections it maintains automatically, rather than from adding more indexes.
Architecture
Today’s platform, and the design we benchmarked.
On the left, NPP as it runs today. On the right, the design we built and measured in our test environment: a new data layer beside the existing one. Select a component for detail.
Methodology & caveats
How we measured, and what it does not prove.
Good benchmarks state their limits. These are ours.
| Servers | Two identical cloud VMs: 4 vCPU, 16 GB RAM, same storage class |
|---|---|
| Versions | SQL Server 2019 (Enterprise engine) · ClickHouse 26.8 LTS |
| Data | Production-scale test data: one day (~20 million summary rows) and one month (~189 million rows) |
| Queries | The platform’s own report SQL and KPI formulas: 8 daily and 7 monthly reports, plus 31 drill-down filter combinations |
| Timing | Warm runs, median of repeated executions; SQL Server monthly reports single runs because of their length |
| Accuracy | Every row and all 13 KPIs compared value by value; SQL Server’s exact rounding reproduced |
- Small, equal test servers. Production servers are larger, so absolute times will differ on both sides. The ratio is the finding.
- SQL Server times vary with disk state. Depending on the report, monthly reports took 2.4–12.6 minutes on SQL Server. For each report we quote its fastest run, which favours SQL Server.
- Daily SQL Server figures are its best case. They were measured with the table held in memory. Read from disk, the same reports took about 28 seconds.
- Not measured: streaming ingest (Kafka) and raw record storage. Any figures for these are labelled as estimates.
- Licence savings are an estimate and depend on the scenario. Self-hosted ClickHouse has no per-core licence fees, but infrastructure, support, operations and any remaining commercial licences (for example, SQL Server kept for other systems) must still be costed.
- “All KPIs matched” applies to what we tested. That is strong evidence, not proof of identical behaviour for every future query. As with any migration, a parallel run on live data is good practice before switching over.
What we covered
Our own benchmark, with results we are happy to share.
This is benchmarking work Telcotec carried out in its own test environment, using production-scale test data. Everything below was built and measured, apart from streaming ingest.
Stack
Analytics Platform Feasibility
Is your database outgrowing SQL Server?
We can run the same kind of study on your data: a benchmark, a value-by-value accuracy check and a costed recommendation.
- Fixed scope and price, agreed after a short call
- Dataset size and query complexity agreed before quotation
- Storage, licence and running-cost comparison
- Written report and presentation you keep
Production migration is quoted separately.