Recorded: October 27 2026 @ 08:00 am PDT
Presenter: Robert Hodges and Alexander Zaitsev

Explore Altinity Antalya builds for ClickHouse®: independent compute swarms, Iceberg hybrid tables, CAS storage, OAuth security, and cost savings.

Key Moments (Timestamps)

Key moments and transcripts are generated with AI assistance – there may be mistakes.

• 0:00 – Introduction and Altinity product overview
• 1:51 – What Antalya builds add to ClickHouse
• 3:49 – Why analytics storage costs keep growing
• 6:48 – How the Antalya project began
• 11:02 – Four major capabilities of Antalya builds
• 13:59 – Independent query swarms for Iceberg
• 18:23 – Caches that accelerate data lake queries
• 20:03 – Hybrid tables combine MergeTree and Iceberg
• 24:09 – CAS introduces content-addressed shared storage
• 28:57 – Live comparison of storage operating costs
• 32:47 – CAS compared with SharedMergeTree architecture
• 36:51 – OAuth authentication and MCP identity propagation
• 41:28 – Roadmap and benchmark performance results
• 51:35 – Audience questions on cost and scalability
• 59:50 – High availability and practical deployment questions

Webinar Transcript

0:00 — Introduction and Altinity Overview

Robert: Welcome everybody to our webinar entitled on the shoulders of giants an introduction to altinity Antalya builds. My name is Robert Hodes and I am CEO of Altinity. I have with me today my friend and colleague Alexander Zaitzv who’s our CTO. let’s just go ahead and dive in. if we could go to the next slide please. a few disclaimers and disclosures. So we are Altinity. We run open-source ClickHouse better. That’s our motto. we offer cloud managed ClickHouse either in your own environment, we call that BYOC, or in our environment, we call that SAS. We also do enterprise support. We have helped hundreds and hundreds and hundreds of customers build high performance systems over the years.

Robert: There’s about 270 of y’all today. And I’d like to welcome, in fact, I see a few of you in the crowd. Welcome. It is a pleasure to present this. on the disclaimer side, we are not a affiliated or associated in any way with ClickHouse Incorporated and ClickHouse itself is a registered trademark of ClickHouse Incorporated. So we are different companies and don’t get us confused. I will thank you Alexander. I let me just tell you two more things that will help you in this enjoy this presentation. We are recording this so you will get a copy of it afterwards if you sign anybody who signed up will get it along with a copy of the slides. We also have time and space for questions. You can pop them

Robert: into the Q&A box in which we will see them. if we can we’ll offer we’ll answer them in the background as we go by or we will have some time at the end to answer them as well. So please do cue them up. We’d love to hear what you think.

1:51 — What Antalya Builds Add to ClickHouse

Robert: All right. so let’s talk about Antalya builds. flip to the next slide. What is an Antalya build? Well, it is our version what we I like to call it a better open- source ClickHouse, but what it really is they are our advanced technology builds. We do number we do several different kinds of builds of ClickHouse. We have Altinity stable builds. Those are basically open- source ClickHouse with minimal changes. They track the LTS releases and they have been used and popular for many years. Antalya is where we put our advanced technology. So we outfit the code with features that lower your cost, strengthen security, increase performance, gain flexibility with zero lockin. So features that in other

Robert: builds might be held back or are simply not there, we provide them as an open source build free for everyone to use and enjoy. some of the key features about the Antalya builds is like our stable builds. They are 100% compatible with upstream ClickHouse. So if you’ve got data on disk and you’re running say 26.3 you can just pop in Antalya build it will plop down and read the same data without any problem. Similarly like ClickHouse it operates in any environment. That’s a big part of what we do is enable people to run anywhere. That’s why we have support BYOC as well as SAS models. our goal is to enable customers to choose where they want to run and then we help them do it. Nice like

Robert: compute storage separation, data lake optimization. You’ll be hearing a lot more about those in a few minutes. And we’re evolving the builds very quickly to meet new use cases. Everything that we’re doing is driven by things we’ve run into in supporting customers. And of course like everything we do in this area it’s 100% open source Apache licensed. Let’s go to the next slide. Okay. So how did we get on to

3:49 — Why Analytics Storage Costs Grow

Robert: this? Well there’s a basic problem that you have with analytic systems which is that successful ones grow. And one of the things that we ran into was or the and just to introduce what it looks like, if you build a an analytic system and you start to load data into it, pretty soon you get a lot of it. And this is this graph shows roughly the type of growth that we see in analytic systems. the CPU even though it may vary up and down from day to day or if you have something where a bunch of people want to run over and look at the data that might cause a spike but in general CPU grows gently because most of the CPU tends to be tends to be looking at newer data just sits there until there’s some unusual case where you need to look at it storage on the other hand just grows

Robert: and grows and grows and this is one of the biggest problems we’ve run into because it essentially grows exponentially and that creates some practical problems for people running ClickHouse. Let’s have a look at what those are on the next slide. So first ClickHouse has as I think many of you are aware it was designed on what’s called a shared nothing architecture where you have a bunch of nodes each with their own attached storage. So Linux block storage and connected over the network which allows them to replicate or share the blocks in the tables. and when data grows too fast or grows fast in general or just grows to large size the these systems become very expensive. So

Robert: we’ve seen systems that were not terrifically large but could easily reach a point where when you looked at the bill storage was 80% of the bill and this is just because you’ve got this more expensive block storage and and you’ve got multiple copies of it. So that’s a that’s a key problem. A second issue is that compute is overprovisioned. and I’ll give you an example of a system to do to manu to manage traces which is one of the pillars of observability. In general you have fairly stable compute where you’re just consuming the data. So the data may be is maybe read in if you have a big system it could be coming from thousands of services that are all generating traces. but there’s a

Robert: certain amount of compute required for ingestion, a certain amount of compute required for merging and then from time to time you’ll make changes. This doesn’t vary a lot but as soon as you have a problem you might have say dozens or even hundreds of people suddenly look at the system to try and figure out what’s going on. So being able to handle those peaks in compute that’s that’s a real problem. So these were things that we were running into or more specifically our users were running into. So we decided to do something about it and we’ll show

6:48 — Origins of Project Antalya and Open Source Development

Robert: you on the next slide. We of course did an offsite to investigate what was going on. And this was actually a picture from a town called Antalya in Turkey. It’s a really nice place. And what we did was we got the development team over there and we sat down together to think about this problem and how we could how we could solve it. So to make a long story short, we had already been doing quite a bit of work on sort of beginning to separate data lakes to parse and query parquet on on S3 storage on object storage. And it became apparent that we should take these efforts and combine them into a single system that would at the time what we wanted to do was use Iceberg as the primary storage. So that is to say

Robert: parquet files stored on S3 and then of course build in compute storage separation so that we could scale the query easily. These are a few of the people and sort of the different thoughts that we had as we were there and what that led to was Antalya. So here we go. So project Antalya is an extension of upstream ClickHouse. Very simply what we do is every time there is an LTS or long-term support branch gets cut in ClickHouse, we of course in our repo which is a which is cloned from the upstream ClickHouse repo. we get that branch and we take our changes which we made for Antalya and we just rebase them on top of the branch. the ones that we’re working we’re working on the

Robert: ones that the branch that’s active right now is actually 26.6. That’s not an LTS branch. We chose to work on it for a while to get some features, but the one that we’re focused on for our next major release is 28 26.8. that’ll be coming out shortly. So what we do is we get the we can see the commits we can pull those and we rebase our changes on top of them and then we put our own features in. so things like compute storage separation swarms these are features you’re going to hear about in just a minute from Alexander. a certain number of things contri get contributed back some of them are so for example are things like well you’ll see them but I’ll give you an example OAuth that’s something which we would submit to upstream but they have a

Robert: different approach to this and so they didn’t take that one but every time we find something that’s a bug or something that’s generally useful we contribute it back. The builds themselves are available on builds.tellian.cloud. If you’re sort of a bare metal Linux type of person, you can find binary everything from tarballs to RPMs. and then there’s containers out on DockerHub under Altinity. So, let’s have one final look at the stats. So, Antalya is moving fairly quickly and these are recent stats for merged PRs and submitted PRs. So here’s the PRs we put in 27 features. We’ll describe in just a second what Alexander will describe what they are, improvements, bug fixes. So pretty active development.

Robert: We have about five to six people who are regularly committing code and looking for more to help with it. And then there are additional things where we submit features, improvements and bug fixes to upstream ClickHouse so that ClickHouse gets better for everyone. We’re motivated to do that because in our business we support both upstream ClickHouse as well as our own builds. So if it gets better for if they all get better it makes our job easier and our users happier. So that’s a quick introduction to Antalya. It is our high technology build built fully on top of ClickHouse and then packed with features that we have discovered or worked out in collaboration with our users. And I’m

Robert: now going to turn it over to Alexander to describe exactly what those features are. So take it away.

11:02 — Four Capabilities and Independent Query Swarms

Alexander: Thank you Robert and hello everybody. So what is Antalya? Roberts tried to explain the rational about that but we often look into that as a collection of different things or different features or shades or sides if you wish and they kind of they may seem a little bit different but they all match together in many applications. What are those features? First, Antalya can be used as a data lake engine and I will explain the details in a minute. So, it allows you to deploy a scalable compute close to your data or use Antalya as a query engine for data bricks for everything which can be queried using a catalog or using the object storage calls. Another view on Antalya is that it is integrated data lake because we combine features

Alexander: both of traditional ClickHouse and Iceberg cataloges and blend them together in a in a hybrid solution. I will explain the hybrid tables and how they can be used in order to build hybrid architecture that combine best properties of ClickHouse and of data lakeink. also another thing is compute storage separation with CAS. This is our new development that allows us and you to extend merged tables into the shared object storage without any changes to application or whatso whatsoever. And CAS has already support for different types of object storage extensions for MergeTree and k is yet another one but it has some very important advantages compared to

Alexander: existing approaches and oh I will explain them in a second and finally antala is a collection of security features that we put into and they don’t exist in upstream ClickHouse for variety of reasons. First we put all security u and this is really important in the world of AI right now when you need to make sure that you trust the identity and on top of that we are building more and more functionality like with your user who authenticates using OAuth to ClickHouse the same user may authenticate to catalog because the catalog itself is a other system right which is not click house but external system but we still need to carry over identity across all the all the call stack which is

Alexander: something that upstream ClickHouse can do as well so we will briefly discuss all those features and I will show some examples so let’s start with a compute model of Antalya that we call swarms the idea is that you may scale compute to query Iceberg search independently from your main ClickHouse. So you have you have your ClickHouse with your schema with your tables and you want to query the Iceberg catalog or unity catalog with this ClickHouse. Usually if if you have a lot of data in a data lake you need to scale your ClickHouse quite big and it may be not convenient or expensive. So if you have some data in merch tables for example in your replic if you add more replicas then you need to replicate and so on so forth even if you don’t need extra

Alexander: power for your main instance you still need it you still need to scale it with the swarms we deploy a separate or we allow you to deploy a separate stateless cluster of click host nodes which is doing only queries to Iceberg and nothing more that allows to distribute the workload pretty efficiently, do aggregation on a swarm and so on. So here’s an example maybe a little bit more detail how the query looks like for the user. It’s just a setting and it can be put in a profile if needed and under the hood the query goes to your native what we call native ClickHouse cluster initial one and it delegates the scans to Iceberg or to object storage to the swarm cluster and this swarm cluster can be scaled

Alexander: completely separately you can get you can scale it bigger you can scale it smaller if you don’t need Iceberg queries today you can shut it down or you still you still be will be able to run Iceberg queries but slower using your native ClickHouse cluster. So this is an extension model that was the first feature of Antalya and it showed really good results as soon as we developed , 1 secondit. It somewhat resembles parallel replicas in ClickHouse but parallel replicas they kind of reuse your main cluster and it’s still limited to scalability of your main cluster. with swarms. this is totally separate compute. you can call it compute separation if you wish. Right now swarms only work for queries.

Alexander: But we plan to extend swarm models to inserts to merges and even use swarm swarms as a serverless ClickHouse in the future. So there are some ideas how to do it. few use cases how you can use swarms for your applications. So this one which I already started with when you have a query coming to ClickHouse and this query have to query Iceberg data and it is slow you can just spin up the swarm cluster and we have several models how we can do it with minimum configuration and that will increase your performance without touching your mainly color system which may be hard to do because this is it uses provisioned hardware or this is a important production system that it cannot touch But with swarms you kind of get around this limitation

Alexander: pretty easily. Another important example is to put your compute close to your data. We call it data gravitation gravity right because your application may be in one location one region or even different geography but your data may be sitting somewhere else. And if you query across the network it may be really slow and expensive because cloud providers they charge for network quite excessively. So what you can do with swarm you can deploy the swarm as close to the data as possible. So you mainly call may stay in one location but you may deploy swarm close to your data and that will increase both performance and decrease costs because there will

Alexander: be no network transfer costs. So this is another important examples and there are more but those two are probably the most important ones for swarms.

18:23 — Caching and Hybrid Iceberg Tables

Alexander: there are a lot of settings that allow you to manage swarm performance and if you look into this list you will see a lot of caches. This is because caches are very important for data lake performance and we put a lot of effort to make caches efficient and fast. There are four main caches and many of them has been developed by us at Altinity first but then they were re-implemented by upstream or adopted by upstream but we were leading the game here that includes Iceberg metadata cache this is that allows to prune files without reading a huge Iceberg manifest very easily in a query playing time that includes Parquet metadata cache that allows to prune Parquet row groups again without reading all the files and without reading the Parquet headers on every

Alexander: request. that includes S3 list object cache a little bit strange one but with Iceberg queries ClickHouse sometimes do this lists just to check that files are here and there and that may be expensive for some queries. So we add a cache just to eliminate that. And finally there is this free file system cache which is standard for ClickHouse and of course it speed ups queries enormously. So your cold query may take a few seconds but after it’s cached and it is cached on the first query then your second query on the same data will take 100 or 200 milliseconds. This is just a normal nurs performance. Since we started talking about Iceberg, this is yet another important area of Antalya. We put a lot of effort

Alexander: in order to make Iceberg a first citizen in ClickHouse or a good tier for the data. So basically we try to build what we call hybrid architecture when part of your data is in claw m tree and part of your data is in Iceberg and this is the same data but maybe for different time ranges but for the user for the end user there is no difference here or she just works with the table and this table we call hybrid table under the hood it understands where the data is resided and queries the data from MergeTree or from Iceberg you can think of that as the very smart distributed table and internally it it is in fact very smart distributed table so how to use it right there’s an engine which you call hybrid and

Alexander: inside engine you define which clusters you need to query and this could be local cluster or you could be swarms cluster for Iceberg and for what date ranges it should it should be queried this is a manual configuration We do support some sort of automation that will move this what we call watermark more or less automatically. But the basic idea is that u the hybrid table defines this rules where the data for different slice is located. For the end user there’s no difference. He just queries a hybrid table and that’s it. Everything else is done by Antalya. On top of that, we added functionality that allows you to move data from MergeTree table to Iceberg table in the most efficient way. So we can move

Alexander: partitions or we can move parts and the data is moved without full repackaging resourcing. We try to do it as fast and as efficient as possible that allows you to build those hybrid architectures. And what we what I think here is the following one. So by the way why do we need hybrid architecture at all? Because inserts in Iceberg are very hard and very expensive. Iceberg and datal in general they’re not very well suited for realtime inserts and this is what ClickHouse does very well. So if you building the system for observability for example you have real time inserts and you cannot use Iceberg easily for that. Instead what you can do you can insert a MergeTree table and the MergeTree is very efficient for inserts and also

Alexander: very efficient for merges and once the data is merged maybe a day after or 7 days later you can move them move this data to Iceberg and for that we had this move functionality. So this is architecture that we envisioned maybe a year ago and we built all the pieces here hybrid tables, swarms movement of parts to Parquet and they started to work together allowing you to build such sort of architecture and we have customers who are doing that already. However, this architecture is kind of hard to adopt and it cannot suit to all use cases. The problem is that it often requires scheme redesign because the data types in Iceberg and nursery are somewhat different and they are not

Alexander: fully compatible. Iceberg doesn’t support projections. So if you have projections you need to think something else. Iceberg doesn’t support MergeTree views. So you have to do some modifications. So if you have application which is designed for MergeTree it is really a migration project to build application that uses both MergeTree and Iceberg. It can it is possible to do and in many cases it makes sense but not for everybody. This is why we started to think for a better approach

24:09 — CAS Storage and Migration

Alexander: and the next feature that we introduced Antalya is called k. CAS stands for content address storage. And the main idea of that this is that every content and by content I mean file it could be part or it could be file inside the part it has the hash which uniquely identifies this content and using the hashes we can do dduplication but not dduplication is important here but the fact that when we have multiple replicas they can access the same data without any conflicts and without any specific synchronization because they reference the data by those hashes. what it means for the user is that they can use merge C is an extension to click storage model. So you don’t need to use different storage engine. You don’t need to use Iceberg.

Alexander: don’t need to use my I would say shared MergeTree right so this is just a regular MergeTree or replicated MergeTree the only difference how storage is configured so internally this is just a type of the disk and I will show you how it’s configured this is really straightforward so no hybrid tables is required this is all standard call functionality you just need to do a couple of twix configuration and it’s very easy to migrate you start with your existing data you configure has disk you add it to your storage policy and you can configure TTL rules or you can move data and you’re done. So basically the migration is totally straightforward and no project is required. It’s just regular house functionality.

Alexander: So how it compares with Iceberg. So before we go to detail they kind of serve the same use case but from a different angles. Iceberg is open table format and it allows us to build this comput storage separation. But the main use case for Iceberg is when you need this open table format when you need other systems to access the same data and this is what Iceberg is built for. Say if you have the data that you want to query not by click but also by spark or by something else. this is where it makes sense to go with Iceberg root with CAS it’s a bit different so this is it kind of solves the same problem but only for ClickHouse so you can share the data which is in CAS but only by ClickHouse

Alexander: instances you cannot share it with spark or something else but this problem it’s it solves much more efficient than Iceberg because this is just this is just a storage for MergeTree tables. How to configure? This is ClickHouse configuration for CAS and you see highlighted two things that are specific for CAS. Everything else is standard. So you need to define the disk and CAS is a metadata type. ClickHouse supports several metadata types. It could be S3, S3 plane and CAS and maybe something else. So K is just extension of existing ClickHouse models model nothing else. Kas server root is specific to CAS. I don’t want to explain it in too much detail but this is unique identifier of

Alexander: your of your server. So once you define cas disk and you define a policy you’re done. You can create a table and specify a storage policy CAS and you can start working with that immediately. or if you add this u add this disk to your existing policy that it immediately changes the behavior of your existing tables. So you don’t need any migration. This is why it’s really cool. So this is just comparison of S3 disk and CAS disk. I just want to show one more time that there is no difference. So it’s it’s defined almost complete almost exactly like the standard 3D disk and we just add a metadata type and couple of parameters. That’s it. now I can show you something really cool. I will stop my share. So this is screenshot but I will switch to a

Alexander: live demo. We have a very interesting calculator. Give me one second. So can you see it?

28:57 — Storage Cost Calculator and SharedMergeTree Comparison

Alexander: So what is storage cost calculator? We tried to model how clicks would behave with different storage types for different workloads. So the first workload is logs which are arriving directly to the tier right. So we have single SE setup and this is very small system just 1 TB of data you can see it and maybe 30 days retention but it doesn’t it doesn’t matter of course EBS is hands down better and the block storage hands down better than any object storage and it is better because rightes are really expensive for object storage it’s not just rights it’s all merges that you need that click needs to run on object storage and you can see that the regular S3 would cost you for this

Alexander: data almost $3,000 and we have analysis of why it’s happening here mostly because of inserts and partially mergers S3 plane rewritable this is another S3 layout it is even worse and C is slightly better but still way behind if we increase the storage here amount of storage this will change the picture. EBS will start to be more expensive but still it is not as good as we would like to. The picture completely changes. If we if we switch to tier storage when we have the cold the hot tier on tree and cold tier in object storage and you can see that in this case EBS solution is already far more expensive than anything else but CAS is far less expensive than other S3 based solutions and u

Alexander: the difference will increase as you increase the storage size. So if you’re talking about 100 terabytes, then EBS is already cost would cost you 16,000 per month, regular S3 for two replicas would cost you 3.5 and car would be less than 2,000 and if you increase number of replicas, the difference will be even more significant and the reason why because CAS is a single copy of the data regular S3 and S3 plane rewritable they will keep multiple copies of the data. CAS will keep a single copy of the data. That’s why when you increase number of replicas the cost of CAS doesn’t doesn’t increase. You may argue that those numbers are not real and in reality it could be a little bit different but we modeled that very carefully. We modeled that using some

Alexander: experiments and measuring number of S3 requests that are coming back and forth measuring the data size and so on so forth. I can say that this is 100% accurate but this is good enough. And we can play with retention here. We can play with number of tables u some other things. there are pricing rules that are looked up from AWS for this region. and different assumptions that we did about ClickHouse behavior and this can be configured. So this is a pretty good model and it shows how huge difference the object storage can give you for a big data sizes and how CAS outperforms in terms of cost the other the existing recourse open source solutions. Let me switch back to slides

Alexander: and discuss few more few more cost related questions. Okay. the question that you may ask and everybody would ask how CAS compares to shared me. of course we cannot compare it directly because shared MergeTree is closed source and cases is open source but we can reason about that. First of all they are very different in terms of architecture. K shares parts and shared MergeTree shares table state for CAS everything is kept inside the object storage it doesn’t use keeper for that for example u but shared MergeTree uses the shared state and this shared state is shared between all replicas that access the data. So for example, if we add a new replica to CAS, the new replica

Alexander: will read the state from the object storage and recreate it manu internally. If we add a replica to shared tree, it just connects to shared state. That means that adding a new replica is faster for shared m than for CAS. But K is also not very slow. It’s very different in terms of deployment. K can be deploying deployed anywhere because it’s open source. shared machine you can only use in recall club the compute model is a bit different it’s both elastic you can add more replicas to CAS in order to get more performance but it is not for shared me it scales to 100 replicas easily for CAS I wouldn’t do it but in real applications you probably need two three war replicas but not more because you mostly do it for high

Alexander: availability rather RA than performance and CAS keeps the single copy of the data and that allows you to keep controls keep cost under control. Another compar comparison the last one for sh for shared merch versus CAS if you’re using CAS for single tier inserts and you could see it in a cost calculator then it is both expensive and it would also be slower because CAS metadata is in S3 and all updates are slower of course than you would do it in keeper or in , 1 secondmemory and also it means that there is some concurrency logs because if you update something on S3 there are some interesting S3 calls that can do it in transactional way but they require

Alexander: concurrency lock shared me is designed for injection into shared object storage. Therefore, it is much better when you insert directly to shared me. But with shared mer you have no option because with CAS you can easily go to tiered storage and this is our main use case where hot inserts and early mergers are going to your block storage but once the data is settled a bit you can it can be moved to CAS and this is what we would recommend to do with certain you don’t have those options. It is just all or nothing. In terms of query performance, they’re comparable. we of course didn’t test it head to head, but since this is just a regular ClickHouse, once the data isn’t cached, there’s no difference at all. the

Alexander: difference is how fast data is being cached and shared mi and in particular glucose cloud, they have distributed cache. and distributed cache allows them to cach the data once across multiple replicas. This is something that K cannot do right now but we will add it in the future. And in terms of cost K is of course better because you can run it by yourself. You don’t have to run it in ClickHouse cloud and when you run it by yourself you just keep your costs under your control and not under vendor control. That’s it for CAS and storage features that I would like to discuss. Robert, do you want to pick it up and talk a little bit about O?

36:51 — OAuth, MCP, and Identity Integration

Robert: You bet. Yeah. So, I’m going to just click quickly touch on OAuth, which is I think as most people are aware is the standard form of authentication between services out on the web. And we started working on this in response to needs from users. it began as a project to allow people to have broad authorization to Grafana dashboards and I want to thank the folks that helped us do that. You are on the call, who you are. Thank you so much. so anyway we put it in because Grafana has great support for OAuth and then it turned out that other people wanted to use it because so for example you can use it with MS Entra that’s the new ver the new name for Microsoft Active Directory and so we have this baked into ClickHouse. This

Robert: is not something you have in open source. As I mentioned, we did submit this to Upstream. They didn’t want it. They have a different way that they do it that’s tied to their cloud. Where it gets really interesting is any place where you have a lot of people accessing data. And one of the ways that we’re seeing this play out is with MCP servers, which are used to access to, to give AI access to source data. And the way that it works is that we have an MCP server. Many of you probably have your own, but it’s very common now to bake OAuth into MCP servers. In fact, this is becoming a standard sort of an extension of the MCP server. And what will happen is when you set this up and the configuration details you can check out

Robert: in our blogs and our docs. what will happen is you’ve got your AI client. Let’s say you’re using Claude or something like that. and it has the connection to the MCP. What it will do is Claude in particular knows how to send a request out to your IDP. That’s your identity provider. you’ll get the tokens from it OAuth and OIDC. There’s usually three that come back. They then can get managed by the Altinity MCP which just passes the tokens over to the to ClickHouse itself. And what ClickHouse does is it’s not we tried to avoid too many arrows here, but ClickHouse has a bakedin support so that it knows where the IDP is for a particular token and can from time to time go back check that it’s correctly stamped. between checks it holds it in cash say for or something like that. What

Robert: this does is it basically lays the groundwork for broad access to databases like ClickHouse and the pools of data behind them. another thing that’s kind of cool about the about the implementation is it in your identity providers you can have groups. Entra supports these let’s see keycloak is another one we work with. it has a notion of groups and those will get automatically mapped to roles in ClickHouse so that you can easily control the security and what they can see. Can we get to the next one? Okay, here we go. Great. So, yeah. So, yeah, basically this we’re already seeing this as an important way to allow people to give access. As I mentioned the driving the initial use case was Grafana but where we really see this

Robert: opening up is MCP. So we do have an MCP that server that we do. We also know that as I said many people are accessing it. And now you can see how this you can basically see how this works. I think this arrow actually really should go actually it should go underneath OAuth and Arbback to but anyway I think you get the idea. As I say OAuth is a little bit tricky to set up but we’ve done our best to make the configuration files like Cass as reduced as possible. So in fact configuring ClickHouse to support OAuth is usually about 15 to 20 lines of configuration files. It’s really simple. So yeah feel free to ask us questions. It’s also in our documentation and there for you to use.

Robert: And one more thing this is something we’ve worked on with users. If you have additional use cases, give us a give us a yell and we’ll we’ll work with you to put them in. back to you Alexander.

41:28 — Roadmap, Benchmarks, and Deployment

Alexander: Yeah. So we started Antalya a year and a half ago actually almost two years ago already and it is now matured enough to start to be a re a real product. some features are really matured and I covered them. They include queries swarms hybrid tables or o that Robert just explained partition expert and others. Some of them are pretty new like direct standalone swarms or CAS discs that we that we just discussed. We also started to work on Iceberg the free features. So delion vectors were added in 26.6 Antalya and some of them are just coming. So we were working on adopting to Unity liquid clustering. Unity is a is a Databricks catalog and they kind of generate a clustering part and partitioning on fly and using this information allows

Alexander: them to query much faster and we with Antalya should utilize this data as well. We adding w to catalogs something that I already announced. So this authentication path from model or from a user to ClickHouse will continue to the data lake. the CAS story will continue of course we keep improving the implementation and performance. There are some things that are currently in works and by the end of the year we plan to announce CAS s. So this will be as a part of 26.8 and next year we will focus on extending the swarm models swarm model with new features like swarms for insert swarms for compaction and also serverless swarms which is really an interesting and appealing architecture.

Alexander: few things about benchmarks because everybody is interesting in benchmarks. So we did few of them for Antalya. a lot of actually a lot of Antalya benchmarks were published earlier. We were showing how Parquet performance works, how queries against Iceberg compared to MergeTree and so on. This is a different one. This is a benchmark against Databricks Photon which are the Databricks query engine for Iceberg. this is courtesy of one of our customers. Actually they did this benchmark using they using our antal builds and they were testing against they were testing observability use case against Photon and as you can see ClickHouse is significantly faster on many queries. and

Alexander: this is this was even before we started to optimize for Unity for liquid clustering and stuff. So right now I think the results are even better and we and not just us but our customers they see not just the speed but also cost efficiency. So from the cost perspective, this is probably five or to 10 times less expensive than Photon because in Databricks the Photon cost model is really interesting. They charge for not for the compute they charge for the latency. So if you want the queries to comp P95 for example to complete in certain number of seconds you pay X amount of money and depending of your data that could be $1 or $100,000 right with ClickHouse the model is totally different you pay for compute and with a smaller compute we

Alexander: can get much better results another use another benchmark that we did we call Iceberg bench and we compared some queries against StarRocks and Trino and StarRocks is you can check results u in Altinity GitHub. the project is called Iceberg bench. there are a lot of things to discuss here discuss here but the most important is that StarRocks is still a winner but it is a winner because there are couple of queries where StarRocks is faster or I would say ClickHouse is very slow but for many queries they are really side by side. Sometimes ClickHouse is faster, sometimes StarRocks is faster. And StarRocks we take it as a as a baseline because it is known as a very good engine for data links.

Alexander: Trino on the other hand that was a known engine for years. It is really slowish compared to modern ClickHouse. And you can also see that Antalya is faster than upstream thanks to optimizations that we put in Antalya. So that’s it for features. Robert, could you take from here? And I’ll do so gladly and as quickly as possible

Robert: because we’ve got some great questions in the chat. Feel free to throw them into the Q&A box. yeah, just facts on the on the builds. I think we’ve already stressed most of these, but once again, two locations where you can get the builds from the builds.cloud page. That’s where you pull your binaries, tarballs, RPMs, and Debian packages. And then containers come from DockerHub. Yay. we’ve we’ve never gotten away from it. and of course you can pull them and put you put them in your own private private repos. yeah, so we test on upstream LTS releases or that’s our standard. Every now and then we break that for TW you saw 26.6 there that was there because there were features that we needed and we all we needed to be on the most current version as we were doing CAS. So we jumped on to that one.

Robert: in general we are focused on the LTS releases and after 26.8. Our plan is to go to three-year maintenance tails, which are standard for our stable builds as well. yeah, and by the way, we test the daylights out of these things. They are we have a great build system. I don’t think people know this, but we run about five or 600,000 GitHub build tasks a year to build all this stuff. It’s we operate pretty large scale. just different ways to run logging issues come to our ClickHouse repo at altinity log issues there’s templates for Antalya as well as other things and then do you want to contribute we would love it if you did because of the way because we’re

Robert: operating as a clone it’s a little bit different you don’t come in and see main as your as your default branch you come in and whatever is the active branch of Antalya will be the default in the in the repo. It’s right now it’s Antalya 26.6 and you can go ahead pull the code submit a PR against it and we can post it up and after that it will rebase we’ll rebase it with new with new stuff. So we would love to have more people contributing to this. Right now there’s about half between five and 10 people contributing. We are starting to see some external contributions coming in. So keep up the good work. Yeah. And the easiest way to run this if you want to just test it out is to go to Altinity.cloud.

Robert: Obviously, we run everything there, everything from upstream builds to stable builds, which are for, if you want to be, sure that you’re using the exact feature set for upstream, but just have support on it, the ability to patch, that’s what you run. But if you want all the features you’ve seen here, the simplest way to get them is come to Altinity cloud. When you create the cluster, you’ll be able to select Antalya builds. So all the features we’ve talked about are supported there. CS, Iceberg, swarm nodes, and clickus regular ClickHouse nodes. Yeah, not for all features. We have full automation in place, but we’re working on that. So we’re working on it. Yeah, it’s a it’s we’re we’re getting the automation.

Robert: That’s that’s something you’ll see coming out over the next few months. we’re really excited about this. yeah. And how to find out more, we have docs in the docs.Altinity.com. Come in and just type the word Antalya. There’s a little search box. It’s super quick. We have what’s called the Antalya playground. You can just Google that. it is among others. There’s a an Antalya playground where we’ve set up a server that has data both in Iceberg as well as on the on the Antalya cluster itself. and there’s GitHub there’s a GitHub repo that shows how we set it up. So you can just grab that code and make your own. And then of course there’s the Antalya code if you’re using if you’re using AI to develop and I mean

Robert: who doesn’t now what you can do is you can just have I often run Claude and just have it sitting on top of the repo. the so that we can so that the Claude can see the code and then it can answer questions about Antalya. And speaking of questions, we’re at that. You can get to the demos, you can get to the ClickHouse repo from these. come join us. we love open source and we are hiring. if you like to build these systems, just give us a yell. And with that, I’m going to stop because we want to answer a few questions. So,

51:35 — Questions on Cost, Caching, and Scaling

Robert: okay. So, I got one here from Omar. Hi, Omar. can you restate the cost difference for Photon versus Antalya for your observability use case? And for that I think the trace that’s a great question. So it really depends on how you do it. so if you because you have the option previously you really just had the option of in older Antalya versions of using replicated MergeTree and then having a hybrid table out to Iceberg or S3 un unreplicated S3. So, as long as the system is not is not enormous and in which case you really like and we’re talking systems that have like

Alexander: 50 or 100 pabytes for some of our customers as long as it’s not that scale then you can now this is the kind of thing that cash should now handle for many applications. So, the cost difference here is probably going to be sub substantial as you can see from that calculator. So, you basically because the majority of your, and by the way, we will release the Alexander, we’re going to release the cost calculator, right? As soon as we’re we’re happy with it. Yes. Yes. Yes. This is just a Java actually or just some stylesheets. Yeah. Yeah. So, so you’d have to you’d have to actually try it on your own data, but I think the cost calculator can help you with that. And as

Alexander: ClickHouse is just if you run it yourself or in Antalya, it tends to be a lot cheaper than Databricks. let’s see. So, Alexander, I have a there’s a couple questions. here’s here’s one. do the caches for CS live in RAM, local disk, or network disc? Do you want to answer that one? they can live everywhere. So, depending on the cache. so u actually for ca for c the main the main cache is local disk for the data it’s called file system cache

Robert: but the metadata of course is cached in RAM in RAM as well the main performance benefit is a caching of the data itself is true for all object storage implementations yeah and I think this brings up a really important point which is as you’re looking at the difference say between what we’ve done and shared MergeTree. shared MergeTree is designed to run in a regional cloud service and so if you go look at the architecture and you can read about it on their blogs they have a they have really nice articles about what they built. they have this really big caching service that is just a pool of memory that where all the blocks can live that are then shared across many instances of ClickHouse. We’ve taken a different

Robert: approach as you’ve seen from this just about everything we do we try to make it just a simple extension off existing ClickHouse. So that means you’ve got an existing open source ClickHouse system. how it works. Now you get an Antalya build and you add say another 20 lines of configuration and now you’ve got this extra feature. And what that means is for caching rather than we don’t assume that you have a separate caching service we’ve made design decisions like when we when you send a query to a swarm cluster the algorithm that we use to distribute work tries to ensure that the that each query on a particular arc file for example will always hit the same server. So we basically have the we use the existing ClickHouse resources as

Robert: to provide cache and that’s that’s an example of how these architectures are really different and how you really if you’re designing for something that truly runs anywhere you tend to make some different design decisions of which this is one Alexander here’s one was separating compute from storage meant to give more room to horizontal scaling without sharding which would fit more the use case of burst and load during parts of day. Can you talk to that one?

Alexander: It’s in the chat. Yeah, it actually depends. you do sharding not because you often do sharding in order to distribute not just query workload but insert workload as well. And K doesn’t help here because you’re still limited to a single shot, right? but Cass helps you to make sharding less expensive. I would say it helps you to make everything less expensive because you cannot leave with single replica. You always need two or three replicas. without CAS you have to have multiple copies of the data. Yes, some of users try to use ClickHouse zero copy replication which is not supported anymore by upstream all tests are disabled and the main problem with zero copy replication is that it can lose the data in

Alexander: object storage we call it orphans. for some of our customers who try to use it the amount of orphans could be tens or even hundreds of terabytes of data. So this is really doesn’t work. With CAS you always have a consistent single copy of the data across multiple replicas. You cannot run 10 replicas but you can run two three four replicas if you need to. So I would say that you still need to do sharding for big systems and really big systems but it just goes for smaller price tag. Yeah. And we’ve also the big thing about sharding is if the data that’s stored on the chart is smaller they

Robert: then just become way easier to replicate. And in fact with tiered storage you can do the calculation yourself. There’s a lot of cases where you can just forget about sharding and just each ClickHouse server can be can just can be small enough that you can actually just have individual copies without actually sharding or ex excuse me without having replication. I didn’t say that very well but the point is we just trying to make the sharding problem smaller. I think Alexander over time we would consider trying to do something that implementing our sort of building on our design so that we could truly get rid of it but that’s not in the cards for now. Correct.

Robert: Yes. Yes. And ClickHouse has what is called dynamic sharding which which can somewhat help but we didn’t experiment with that at scale. Yeah. Mostly what we’ve seen are for example systems that do trading, systems that do observability, they actually have fairly stable usage except when people need to come on and look at the data and that’s why that’s why being able to scale the compute quickly is really important. you do need to be able to add more shards, but in fact when if it doesn’t take too long to add them and in our case the way that CAS works makes it vastly cheaper it’s it’s it’s a big enough improvement that you no longer need to do away with them completely. a question can a swarm node run the whole query stage filters UDFs partial

Robert: aggregation or is it limited to scanning to at the point where the data is?

Alexander: Yeah, it is it runs all ClickHouse functionality for distributed queries. Let’s put it this way. So, it is filters the data if it can be filtered on the on the low level. It does partial aggregation it applies all the functions you can do on this aggregation state and then the partial aggregated results are passed as are sent back to the query initiator. You can think of that as a simple extension of distributed queries that doesn’t require you to touch your primary call cluster.

59:50 — High Availability, Object Storage, and Closing Questions

GCP. It is replicated by design. So they replicated for multiple copies already and therefore you don’t need you don’t need multiple replicas for HA you have replicas of ClickHouse so you run multiple ClickHouse replicas but they connect to the same data copy on object storage so if something happens to with your ClickHouse you always have ha to other nodes but we assume that the data which is on

Robert: object storage this is reliable enough and it doesn’t needs to be replicated ated by clical color means it is already replicated by the storage provider. Great. hey, here’s a question. Is the following pipeline working? Superset to keycloak to click Antalya with OAuth supported. yes. I can’t think why not. Yes. Yeah, it should work. I think we tried that. So supererset can work as of ClickHouse client and the best way to configure it by the way use AI because it might be non-trivial ask your cl or charge to configure this setup and it will do it nicely.

Robert: Yeah. Okay. let’s see. yeah there were questions about S3. one kind of out there thing which I’ve been interested in is because we see other people doing this is we do have a lot of customers some of you on this call who don’t run in the cloud you are running in HPC environments or other types of on-prem data centers you may be running in you know even in sort of IoT environments edge computing so one very interesting topic is as we get better support for S3 is also to benchmark it against things like Back Blaze or Shelby or Cloudflare R2.

Robert: this is a really the emergence of these new sort of global S3 systems is a very interesting development because it means that it’s just it gives you another way of basically chasing cheap compute but still having access to object storage which is important for costs. let’s see. For Cass, you’re building tools to more easily scale equivalent compute nodes up and down as in another node with all the same replicas. I think there’s a that’s a question. Is that a question? It’s from Adam. so with CAS, yeah, that’s I think a fair statement of what we’re doing right

Robert: now. The swarms allow you to have as Alexander said, compute separation. So, I think we’ve got the most of the questions. thank you everybody for attending. We hope this was interesting. We’re really stoked about this and I notice Misha Philonov is on as a panelist. He joined us. Misha is the author of Cass. Misha, if you want to take a bow. Hi guys. Yeah, just like also excited to uh to hear that this thing already going like going online like so we waiting for post production installations for testers. So just like yeah please try and how it works. Yeah. And

Robert: we we’ll still have a lot of things to improve, but it’s already Yeah. Yeah. Thank you, Misha. Thank you for joining us and thank you for a great design. Okay. We’re going to have more coming out on Cass. I think from here on out it you’ll see more performance results, more blog articles describing how to use it. And if you want to test this, give us a yell. Particularly if you’re in Altinity cloud, there’s nothing could be easier. You can spin up a cluster right away and check it out. we will help you. And yeah, we’d love to work with you.

Robert: And Alexander and Misha, thank you so much for helping with this talk today. It’s it’s just been a real pleasure to be with you guys. Thank you, Robert. Thank you everybody. And yeah, thanks to the audience. I hope we’ll talk to you soon. And yeah, have fun.

Alexander: Yeah. with no extra replicas, how is HA maintained with CS? We already had a partial answer from Doug, but Alexander, you want to take a crack at that? Yeah. So, we consider that object storage is reliable u especially in major cloud providers like AWS or

FAQ

What are Altinity Antalya builds?

They are open-source builds based on upstream ClickHouse with additional features for data lake analytics, compute and storage separation, and security. The webinar describes compatibility with existing ClickHouse data and deployment in different environments.

What are query swarms used for?

Swarms are separately scalable, stateless ClickHouse compute nodes that handle queries against Iceberg and object storage. They can be located near data to reduce network transfer and avoid scaling the primary cluster for every data lake workload.

How do hybrid tables combine MergeTree and Iceberg?

A hybrid table routes queries across data held in MergeTree and Iceberg according to configured data ranges. The presenters describe using MergeTree for real-time ingestion and moving older data to Iceberg, while noting compatibility and migration challenges.

How does CAS differ from an Iceberg-based architecture?

CAS uses content hashes to let multiple ClickHouse replicas reference the same object-storage data without storing a separate copy per replica. Unlike Iceberg, it does not provide a shared open table format for other engines such as Spark.

Why is tiered storage important for CAS costs?

The cost demonstration finds that direct object-storage ingestion can be expensive because of writes and merges. The recommended architecture uses block storage for hot ingestion and early merges, then moves settled data to CAS object storage. Actual savings depend on workload and pricing assumptions.

How does Antalya support OAuth for AI applications?

The webinar describes OAuth and OIDC authentication through identity providers, with tokens passed through an MCP server to ClickHouse. Identity-provider groups can map to database roles, helping control access for AI clients and other applications.

© 2026 Altinity, Inc. All rights reserved. Altinity®, Altinity.Cloud®, and Altinity Stable® are registered trademarks of Altinity, Inc. ClickHouse® is a registered trademark of ClickHouse, Inc. Altinity is not affiliated with or associated with ClickHouse, Inc. Kubernetes, MySQL, and PostgreSQL are trademarks and property of their respective owners.