When you’ve decided to use ClickHouse as your database, you are then often faced with the choice of whether to use the self managed open source version or the fully managed ClickHouse Cloud option.
Despite the fact that open source is “free”, there are obviousky 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 an open source deployment.
Let’s first break down the various factors involved in the decision, 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.
Of course, with an open source cluster running on a cloud provider such as AWS we could introduce similar automation to turn 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 peak or bursty demands.
Say you are a retailer who have to scale up to meet Black Friday sales, 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 window.
Again, we can introduce automation and perhaps use 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.
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
The flip side of risk is “time to market”. Any time your people spend standing up and supporting data infrastructure is time that is not being spent on something differentiating which actually impacts your business. 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.
Case Studies
Customer 1 - Variable Workload
Customer 1 has the following development and production environments.
They have have a very variable workload, where the service is business at 9am most mornings, then scales to zero for most of the day. Weekend evenings are their peak time during the week when they have to scale to approximatly 32gb of RAM.
Customer 2 - High Operational Overhead
Customer 2 are an enterprise business consisting of tens of siloed teams.
Customer 3 - High Risk Workload
Customer 3 are operating in financial services with significant regualatory 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.
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.