.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Executive Summary
We tested VeloDB Cloud against ClickHouse Cloud using TPC-DS - the industry-standard, 24-table benchmark built to reflect how real enterprise data actually looks after migrating from OLTP systems, not the flat single-table setup we used the first time around.
The result: VeloDB was faster on all 9 queries we ran, beating ClickHouse by 1.2x to 3.3x, with the biggest gains showing up on the most join-heavy queries. That lines up with what the business team suspected all along - VeloDB's architecture genuinely handles multi-table joins better, and this benchmark shows it clearly for the first time.
1.Background & Objective
After our first VeloDB vs ClickHouse benchmark - which only tested a single flat table - the business team pointed out a real gap: actual enterprise data warehouses almost never look like that. Data coming from OLTP systems is normalized across many related tables, so real analytical queries need multi-table joins. That's exactly the area where the business team suspected VeloDB might have a real edge over ClickHouse.
Feedback Received
2.Benchmark Architecture
The diagram below summarizes the full pipeline used for this benchmark, from local data generation through to the final side-by-side comparison in Apache Superset.
3.Sizing & Version
Both platforms were provisioned on AWS, and both ended up running on matched compute during this benchmark - 8 vCPU / 64 GB RAM on each side. That's a useful detail: it means the performance difference measured here reflects a real architectural difference, not one platform simply being given more hardware.
4. Methodology Overview
- Generate an ~11GB TPC-DS dataset (Scale Factor 10) across 24 related tables using the official toolkit
- Generate the standard 99 TPC-DS queries to match that dataset
- Load the same dataset into both VeloDB Cloud and ClickHouse Cloud
- Pick a representative set of queries covering different levels of join complexity, from simple 2-table joins to 5+ table joins
- Connect both platforms to Apache Superset and run the same queries on each, timing every run
- Compare the results and write up what we found
5.Local Environment Setup
Everything was done locally on a Mac, no cloud compute needed for generating the data or queries. We compiled the TPC-DS toolkit from source, hit a small compatibility snag with older C code on modern Apple compilers, fixed it with a couple of compiler flags, and had both tools (dsdgen and dsqgen) working.
6. TPC-DS Dataset & Query Generation
We generated an ~11GB dataset (Scale Factor 10) across all 24 TPC-DS tables, all linked together the way real data would be. SF10 was big enough to actually stress both engines, unlike our first test which was small enough to fit comfortably in memory. We also generated the full set of 99 standard TPC-DS queries against this same dataset.
7.Loading Data into VeloDB Cloud
We created all 24 tables in VeloDB and loaded the data using its Stream Load feature via curl. One small snag: TPC-DS data files have a trailing separator on every line, which VeloDB read as an extra empty column. Easy fix - just told it to expect and discard that extra column. All 24 tables loaded cleanly, and row counts matched what we expected.
8. Loading Data into ClickHouse Cloud
Same 24 tables were set up in ClickHouse using its MergeTree engine, and data was loaded directly via clickhouse-client. One adjustment needed: ClickHouse won't let you sort by a column that can be empty, so we swapped the sort keys on the big tables to use non-nullable ID columns instead of date columns.
9. Data Volume Verification
Before running any comparison queries, row counts for the four largest fact tables were verified independently on both platforms to confirm the datasets were identical. All four tables matched exactly, confirming both platforms were tested against precisely the same data.
10. Apache Superset Integration
Both VeloDB Cloud and ClickHouse Cloud were connected to Apache Superset as separate database sources (via the MySQL-protocol connector for VeloDB, and the native ClickHouse Connect driver for ClickHouse), enabling side-by-side query execution and timing comparison through Superset's SQL Lab interface.
11. Initial Query Validation
We picked 10 queries out of the 99, covering everything from simple 2-table joins to complex 5-table+ joins - Q1, Q3, Q7, Q19, Q26, Q34, Q42, Q52, Q88, Q95. Q95 didn't get finished this round, so the results below cover the other 9.
On Query 1, VeloDB returned 100 rows in 2.08 seconds, ClickHouse in 2.78 seconds. ClickHouse also threw a column-name error at first because it's case-sensitive and VeloDB isn't - once we fixed the casing it ran fine. Worth flagging for anyone migrating queries over: VeloDB is more forgiving here, which means less friction moving existing SQL across.
12. Full Benchmark Results
All 9 completed queries were executed on both platforms via Superset, with execution time recorded for each. Results are summarized below.
VeloDB was faster on all 9 queries, with speedups ranging from 1.1x to 3.3x. Six of the nine queries show ClickHouse clustering tightly around 8-11 seconds, while VeloDB ranges from 3.1 to 6.1 seconds on those same queries - a pattern consistent with the business team's original hypothesis that VeloDB's architecture provides a real advantage on join-heavy, multi-table workloads.
13. Limitations
- SF10 is below TPC-DS's official minimum scale factor for certified, publishable results; these findings are directionally reliable but not a formal TPC-DS certification.
- Each query was executed once per platform rather than averaged across multiple runs, so individual timings may include some network or cache variance.
- Tests were run over a home network connection to each cloud service rather than from a co-located or controlled-latency environment.
- Query 95 was not completed in this round and is not reflected in the results above.
14. Conclusion & Recommendation
This confirms what the business team suspected - on realistic, join-heavy workloads, VeloDB is consistently faster than ClickHouse, and the gap grows as joins get more complex. Combined with what we already found in Phase 1 (easier migration, more reliable CDC, friendlier SQL), this makes an even stronger case for VeloDB as the right platform for Geopits' analytics.
Paramesh M
.svg)
.svg)
