Originally published at altinity.com on April 16, 2025.
Exploding data volume is blowing up database cost and stability. We’re bringing real-time analytics to the next level by extending ClickHouse with Iceberg shared storage. Cheap and real-time: what’s not to like?
Is your data volume blowing up your analytics budget? You’re not alone. Today’s observability and AI applications generate petabytes daily, pushing traditional analytics architectures to their breaking point. We help ClickHouse users work around cost and management of large clusters on a daily basis. It’s time for a permanent fix.
Meet Project Antalya – our game-changing solution that combines ClickHouse’s lighting-fast queries with Iceberg’s cost-efficient storage. This isn’t just another feature update–it’s a fundamental rethinking of analytics economics that delivers:
- 90% reduction in storage costs by replacing replicated MergeTree with Iceberg/Parquet
- 10 to 100x faster queries through revolutionary swarm cluster technology
- Zero application changes required – a drop-in upgrade for open source ClickHouse deployments
- Universal data access that eliminates silos between real-time, AI, and batch workloads
Starting today, we’re inviting you to try out swarm clusters, our breakthrough technology that delivers sub-second reads on Iceberg/Parquet tables. Install an open source Project Antalya build and scale up to your price/performance point. Stop worrying about costs. It’s time to start building systems for the next generation of analytic systems. Welcome to Project Antalya.
Show me the code already!
We know many of you have been waiting — If you already know about Project Antalya and just want to try it out, jump to our GitHub antalya-examples repo.
So what’s the problem?
Rising costs are crushing analytics ROI
ClickHouse appeared as an open source project on GitHub in 2016. Its compressed columnar storage and lightning fast performance drastically reduced the cost of real-time analytics. It was helped by the fact that ClickHouse installations rarely exceeded a few tens of terabytes in total, which kept overall bills in check for most users.
The high performance of ClickHouse encouraged users to apply it to use cases with vastly larger data sizes, like observability and LLM monitoring. Altinity now operates or supports applications that load multiple petabytes per day. This represents an increase of up to three orders of magnitude.
ClickHouse is of course as fast as ever, but the enormous growth in data has led to a number of practical problems related to cost. The two most important are:
- High storage costs – The traditional ClickHouse table design uses MergeTree with block storage with copies replicated across up to 3 servers. This design is around 10x more expensive than keeping the same data on S3-compatible object storage.
- Excessive compute costs – Open source ClickHouse does not have a simple way to scale compute temporarily for a large batch job or split the resources used for data loading from resources for queries. Users instead provision for peak combined load, which needlessly inflates compute costs.
If data and compute costs were the only problem, we could solve them within ClickHouse. That would ignore another important development in the marketplace for analytics.
Silos of proprietary batch and real-time data are disappearing
Workloads for real-time analytics, AI, data science, and batch reporting often operate on exactly the same source data, originally stored in separate silos for each application. The separation has become complex and costly as data size has increased. Instead, users increasingly operate workloads on a single copy of source data stored on data lakes consisting of object storage, Parquet, and open table formats, of which Iceberg is most popular.
Keeping a separate copy of real-time data stored in ClickHouse is a common but costly design. Besides extra storage costs, separate silos mean separate data pipelines, which is yet another source of complexity and expense. There’s an obvious argument to reduce cost and complexity by sharing storage with other workloads. But there’s upside as well. ClickHouse has an adaptable, toolkit-like design and runs anywhere. Data lakes need real-time ingest, query, and data compaction. ClickHouse has those capabilities, but there’s no easy way to apply them.
Reduce storage costs and share data. Better data lakes are a freebie
An ideal solution to both problems would be a savvy implementation of compute/storage separation that combines the fast query and optimized native data structures of ClickHouse with shared storage on Iceberg. This preserves the strengths of ClickHouse but adds the ability to operate on very large tables shared with other workloads. Existing ClickHouse applications could extend seamlessly onto data lakes. At the same time, ClickHouse’s adaptable features would make data lakes better.
Embracing Iceberg requires rethinking low-level design assumptions of ClickHouse. However, the pay-off is huge. That’s exactly what we’re doing with Project Antalya.
Project Antalya – Transforming ClickHouse for Cost-Efficient Data Lake Analytics
Project Antalya adapts ClickHouse to use Iceberg data lakes as primary storage. It leverages the current strengths of ClickHouse: ability to run anywhere, open source licensing, and a powerful toolkit of existing features like parallel query, SQL, role-based access control, and tiered storage. The architecture has three main goals:
- Store table data as single copies in a globally accessible Iceberg data lake. This reduces storage cost by 10x and enables sharing with other workloads like AI.
- Allow applications to see all data, regardless of location, from a single ClickHouse SQL connection. This keeps access simple and enables existing ClickHouse applications to take advantage of data lake storage without changes.
- Enable fast, independent scaling of ingest, merge, transformation, and query. This reduces costly over-provisioning of compute and opens the door to use of cheap resources like spot instances.
Most importantly, Project Antalya introduces additions to ClickHouse but does not break current features. Existing applications can seamlessly extend storage onto Iceberg. Developers build groundbreaking applications by combining real-time ClickHouse query and native storage with Iceberg data. Here’s the full architecture.
Project Antalya is more than just a “better ClickHouse.” It’s a powerful new way to build high-performance, low-cost analytic systems that can meet real-time SLAs on shared data lake tables. We are focusing on three main areas of innovation.
- Iceberg, Parquet, and S3 performance – Low-level ClickHouse changes to speed up reads and (in future) writes. This includes reading Bloom filters, PREWHERE processing, Parquet metadata caching, and the like. We’re committing these features to upstream ClickHouse wherever possible.
- Data access improvements – Introduction of stateless compute swarms, distributed caching, and tiered storage onto Iceberg storage. These are the key underpinnings to cut cost while keeping query at real-time speeds.
- Cloud Native Runtime – ClickHouse and of course Project Antalya builds run anywhere. That said, we’re focused on delivering templates for cloud native operation that enable fast swarm auto-scaling, cache deployment, monitoring, as well as templates for deploying Kubernetes itself.
We are implementing the architecture in phases. The first phase introduces swarm clusters, which offer real-time compute on Iceberg tables using cheap, stateless ClickHouse servers. This is available today. Future phases will introduce tiered storage on Iceberg as well as the ability to build materialized views on data lakes. We’ll reveal yet more great features in time. Join our Slack Workspace if you have questions or watch for regular roadmap updates on this blog.
Let’s walk through a couple of use cases that show the versatility of the Antalya Architecture. There’s a lot more, but this should help you see where we are going.
Real-time query on Iceberg tables with cheap swarm clusters
Iceberg tables with Parquet reduce storage costs by 10x over replicated MergeTree. But there’s a down side. In today’s open source Clickhouse, they make queries painfully slow and expensive to scale. As query load goes up, users resort to costly over-provisioning to maintain performance. The only alternative is proprietary storage engines like SharedMergeTree.
The first step, of course, is to make Parquet reads as quick as possible. The second step is scaling compute to meet demand. Swarm clusters solve that problem. Swarm clusters are scalable pools of self-registering, stateless ClickHouse servers. ClickHouse clusters delegate reads on Parquet files to the swarm. This speeds up queries while minimizing load on existing ClickHouse applications.
Here’s how it works.
Swarms have a number of important features that make them both fast and cheap at reading Parquet.
- Caching – Caches can reduce latency by 90% or more. There are three main types.
- ClickHouse initiator nodes cache Iceberg metadata. This reduces the cost of query planning.
- Swarm clusters cache S3 file blocks and parquet file metadata. They reduce the cost of reading files on specific swarm nodes.
- External HTTP caches save API requests to S3, including slow S3 ListObjectsV2 calls. They reduce the number of API calls (hence your cloud bill) and and also reduce latency across the entire swarm.
- Auto-scaling – Swarm nodes combine easily with Kubernetes cluster autoscalers. They register themselves when they come up and deregister when they go away.
- Ephemeral – Swarm nodes can run on spot instances, which typically reduce compute costs by somewhat over 50%. They use minimal storage, which further reduces costs.
Swarm clusters are not limited to Iceberg tables. They can read any Parquet data stored on S3. That includes Hive tables as well as Parquet files using wildcards.
To see swarm clusters in action for yourself, check out our antalya-examples repo on GitHub.
Extend large ClickHouse tables seamlessly to Iceberg storage
Tiered storage is a popular ClickHouse feature that automatically moves table data to cheaper storage as it ages. As a user you just see a single table regardless of where the data is actually stored. We’re extending tiered storage to move data into Iceberg, which reduces cost for older data by around 10x. You’ll still see a single table but older data will be 90% less expensive.
Here’s how it works. Queries that hit tiered tables are automatically dispatched to local storage and Iceberg storage in parallel. The swarm provides additional compute capacity for scanning cold data. That helps to keep clusters that manage hot data small. Applications just see a single set of results.
Existing ClickHouse features like Merge Table Engine help with this implementation. The design includes features to avoid gaps or duplicates in data when selecting. We expect to release the implementation around mid-year.
The best part about tiered storage is that you will be able to turn it on with a simple configuration setting without application changes. We expect large ClickHouse installations will be able to reduce storage cost by 80% or more once tiering is fully enabled.
Some Frequently Asked Questions
Shared Iceberg storage for ClickHouse clusters is a big jump forward. We expect you have a few questions at this point.
Is Project Antalya open source?
Yes. Code is available in the Antalya branch in the Altinity ClickHouse repo on GitHub. It’s the same repo we use for Altinity Stable Builds.
Is Project Antalya a fork of ClickHouse?
No. We’re submitting as many changes as practical to upstream ClickHouse. We’re balancing getting working code out quickly against maintaining compatibility with upstream.
Wait! What about Delta Lake Tables?
We love Delta Lake. It’s just that we need to pick a place to start and Iceberg at this point is more popular among users at large. We’ll turn to Delta Lake once we have Iceberg in hand. Upstream ClickHouse is already implementing support for Delta Kernel, which will improve support.
Where’s the performance test?
We’ll publish detailed performance results shortly and also show you how to reproduce them. The in-house results are good and getting better. If you can’t wait, check out our launch webinar for Project Antalya. It includes a nice demo showing 35x scaling.
What is your roadmap?
We have a well-defined roadmap that we’ll be opening up shortly. For now the main priorities are:
- Swarm clusters (what we’re releasing today)
- Hosted Iceberg catalogs and tooling
- Iceberg Tiers for MergeTree tables
- Swarm cluster auto-scaling
There’s a lot more on the way.
How can I get started?
Look at the antalya-examples repo. It shows how to set up Project Antalya on Docker and Kubernetes. Also, read our upcoming blog articles. We’ll be publishing a Project Antalya Tutorial and also show how to get the best performance from queries on Iceberg tables.
How can I contribute?
We welcome contributors. If you want to submit a PR, check out the antalya-examples README.md for more information.
Does this work in Altinity.Cloud?
Yes! We’ve done a lot of the internal development using Altinity.Cloud. It’s our favorite test bed because it can run any ClickHouse build version. Come back in May and we’ll let you try it yourself. We’ll have built-in support for swarm clusters by then. There is a follow-up webinar coming on May 21st that will go deep on production use of swarm clusters, including deployment in Altinity.Cloud.
In conclusion…
Project Antalya is more than just a new release — it’s a vision for the future of analytics. Many people will see Project Antalya as a “better” ClickHouse — and they’re not wrong. But this isn’t just an evolution. It’s a reimagined architecture that combines the capabilities of ClickHouse, cloud native operation, and Iceberg/Parquet to deliver analytic systems ready for a decade of growth. Get the performance you want, at the price you can afford, anywhere you choose to run. That’s the vision of Project Antalya.
We’re building this together — in the open — with your insights, challenges, and goals shaping the roadmap. This release, and all that follow, are dedicated to the community and customers who made it possible.
Try it out. We can’t wait to see what you’ll create.
Top comments (0)