When you’ve decided to use ClickHouse as your database, you are then faced with the choice of whether to use the self managed open source version or the fully managed ClickHouse Cloud.
Though not the only the factor, the cost of each option is of course a relevant part of the decision.
Weighing this up isn’t as simple as it initially seems. Despite the fact that open source is “free”, there are obviously costs associated with running it including server costs and engineering costs. When you correctly run a TCO analysis, you will often find that the economics of ClickHouse Cloud are very compelling to the extent it can cost significantly less than an open source deployment.
Let’s first break down the various factors involved in the TCO analysis, then we will look at some real numbers.
Engineering Activities
Running a single node of ClickHouse is easy. However, as you begin to productionise it does take manual work.
In terms of initial setup, you’ll need to provision some servers and install ClickHouse. If you want to run in a clustered environment then you have to setup your shards and replicas. You might have to setup backups, monitoring and alerting and perhaps integrate with third party tools.
Going forward there will be a number of manual activities associated with your open source environment. Version upgrades, operating system upgrades, network changes, chatting with your compliance team about security, monitoring and managing disk space etc. In a large enterprise, even something as simple as a firewall change can end up taking significant effort and cost.
It’s easy to inflate a business case with lots of manpower cost to make Open Source look more expensive, but even if we assume a small amount of hours per month of engineering effort at a reasonable daily rate, the TCO outcome can change significantly.
Autoscaling
Most data use cases have a variable workload. This could be a situation like all of your employees arriving at 9am and pulling reports at the same time, or a seasonal workload such as Black Friday sales.
ClickHouse Cloud has a strong ability to scale the size of servers up and down automatically in response to demand. Your environments will scale down to zero when not in use and scale up when under memory pressure. This means that it perfectly right sizes to the usage pattern. If you do need to step in and increase the size of clusters manually then this can also be done with a few clicks.
Of course, with an open source cluster running on a cloud provider such as AWS we could introduce a degree of automation such as turning off environments outside of business hours. However, if we do want to do anything more dynamic such as intraday scaling then this will require significant engineering work. For all of ClickHouse’s qualities, it is a little hard to do this kind of automatic scaling with open source.
Bursty Workloads
Autoscaling is particularly important in a situation where you have known spikes in volumes or bursty demands.
Say you are a retailer who have to scale up for weekends, or a bank doing monthly risk reports. ClickHouse Cloud can again meet this need automatically, whereas an open source cluster may need to be overprovisioned 24x7x365 to meet the needs of a very small time window.
Again, we can introduce automation and perhaps use a platform like Kubernetes to better respond to changing workloads. However, at this point our DevOps engineering costs grow further and the complexity and risk of our solution grows. To build a ClickHouse cluster that perfectly scales up and down reliably in response to changing user patterns is no mean feat.
Supporting Tooling
With a self managed ClickHouse cluster you will typically integrate with supporting tools such as monitoring and alerting or ETL systems.
With ClickHouse Cloud we can avoid some of these costs by relying on integrated monitoring and alerting dashboards or features such as the ClickPipes ETL service.
Though some of these tools do have costs, we also need to consider the surrounding tooling and the engineering costs involved in integrating with those tools when deploying a self managed cluster.
Risk Factors
I wouldn’t want to overplay this, but running your own database cluster does bring some risk. Perhaps there is a small risk of downtime or degraded user experience. Perhaps there is some security or compliance risk due to misconfiguration or inadequate monitoring. Perhaps there is key person risk if your ClickHouse expert leaves your business. In a worst case scenario there could be a risk of data loss if you do something wrong and your backups fail.
A lot of this risk is mitigated by using a managed service such as ClickHouse Cloud as you are offloading operations to the experts who focus on just this one task. Those experts also bring certifications such as PCI and HIPAA compliance, further increasing trust and reducing risk.
It can be very hard and subjective to model these things, and it easy to manipulate a business case to tell the story you need, but in a real business case these should be accounted for.
Time To Market
Any time your people spend standing up and supporting data infrastructure is time that is not being spent on something differentiating and value.
By using a Cloud Managed service, you can begin working on your analytics immediately and get your projects to market sooner, where they are either moving the needle for your business or improving your customer experience.
As with the above, we are straying into subjective territory here, but there is a very real financial cost in getting your products and features to market weeks or months later.
Case Studies
In the examples above we have some very objective factors (infrastructure costs and engineering costs) and some which are more subjective (risk and time to market). Let’s now look at 3 examples and some real numbers to bring this to life.
Customer 1 - Variable Workload
This entertainment business have a very variable workload, where the service is busy at 9am most mornings for staff reporting, then scales to zero for most of the day. Weekend evenings are their peak time when they have to scale to approximately 32gb of RAM to monitor their operational systems.
Customer 2 - High Operational Overhead
This customer are an enterprise telco business consisting of a number of siloed teams. They have a number of engineers on staff managing their ClickHouse cluster, interfacing with infrastructure engineers, network engineers, storage engineers. They have to work with security teams to ensure their environment remains fully compliant.
Customer 3 - High Risk Workload
This customer are operating in financial services with significant regulatory and compliance risk. If they experience degraded performance for an afternoon, their clients would move trading flow elsewhere. If they experience downtime of more than 24 hours they would be exposed to fines and customer penalities. A more serious regulatory incident could lead to regulatory penalities.
The three respective customers are considered in this video:
What About On Premises?
In a lot of my TCO work I have focussed on cloud providers such as AWS and Azure. It’s is fair to say that we can run ClickHouse cheaper on on prem hardware or with vendors like Hetzner or Digital Ocean which would remove TCO from an open source solution.
I would argue that these environments are even more complex to automate so things like overprovisioning are likely to be more of a fact of life. However, it is a reasonable point that running ClickHouse open source on AWS is not the cheapest way to run it either.
Conclusion
I don’t want to be unfair to Open Source and imply that it is extremely complex and heavyweight to run. In fact, I like it for the opposite reason! However, there is cost, effort and a small amount of risk in running an Open Source cluster which should be accounted for in any economic decision.
When you accurately model this, you find that the TCO of cloud can be very compelling compared with open source.
Furthermore, if the economics do change, you have an exit path by migrating between ClickHouse Cloud to ClickHouse Open Source. This isn’t the case with Snowflake, Redshift or BigQuery. With ClickHouse we really have the of both worlds!
If you are curious how much it would cost to run ClickHouse Open Source or Cloud based on your workload? Please get in touch to learn more.