Neutral

Positive

My main use case for ClickHouse at Infoblox involves receiving detection data, which we attempt to perform aggregation on and store in ClickHouse for faster query and access.

For the kind of detection data I work with, I use ClickHouse, specifically utilizing Aggregate MergeTree and deleting tables, along with indexing and sharding techniques for faster access.

In handling detection data with ClickHouse, we write two queries to retrieve data, but for storing, we use different Kafka table engine and Aggregate MergeTree to keep our data structured.

The best features ClickHouse offers in my experience include its performance and the various table engines it provides, allowing me to avoid writing large queries to access my shaped or fine-tuned data.

I mostly use the Kafka table engine, SummingMergeTree, and AggregatingMergeTree, which enhance performance because we work with streaming data, using Kafka as our input.

The features of ClickHouse that stand out for me are primarily centered around performance.

ClickHouse has positively impacted my organization by replacing PostgreSQL, which required complex foreign tables for queries. With ClickHouse, we now have Cube.js for easier data visualization.

I have seen specific improvements such as faster query times. For instance, queries that took 10 milliseconds on PostgreSQL are now approximately 50% faster due to improved storage and query performance.

ClickHouse can be improved, and the main challenge I see is its operational complexity.

One improvement I think ClickHouse needs, apart from operational complexity, would be around its documentation, which is already quite great.

I started using ClickHouse in my current company about one year ago.

In my experience, ClickHouse is stable.

ClickHouse's scalability is good as we manage it through Kubernetes, allowing us easy scaling up and down with ClickHouse operator and installation resources.

I have not interacted with ClickHouse's customer support, as I focus mainly on query work, and any issues go through a separate team that contacts support.

Previously, I used Snowflake and BigQuery in a different company, but ClickHouse is now in use. The reason for the switch is uncertain to me.

I can vouch for time as a return on investment with ClickHouse, but I am uncertain about the financial aspect.

Regarding pricing, setup cost, and licensing, I have not been involved in the pricing part and am not fully certain about it.

Before choosing ClickHouse, I think my organization evaluated other options such as CockroachDB, though I am not entirely certain.

My advice for others considering ClickHouse is to opt for it due to its scalability, performance, and deployment ease, especially with Kubernetes.

I believe ClickHouse is a great product that is maturing well, and although it may have flaws, it will overcome them and continue to serve users worldwide. I would rate this product an 8 out of 10.

My main use case for ClickHouse is that it primarily drives our analytics and reports. I use ClickHouse for product analytics, and that mostly drives product decisions.

We moved away from Redshift to ClickHouse because of the integration and the flexibility that it provides, which best suited our use case. Most of the teams in my company use it as a central resource where all teams have their separate accesses to the databases that they work on within ClickHouse.

The best features ClickHouse offers are seamless integrations, data exports, and data imports, which fit well because we use Postgres as our primary database for our transactional databases. Seamless integrations help our workflow by allowing us to integrate data sources more easily, and the data exports and imports compare favorably to our previous solution.

ClickHouse has positively impacted my organization by driving our products because we use it for our product analytics, and the integrations make it easier to integrate new data sources.

ClickHouse could be improved with self-hosting capabilities and better documentation for how to host it at scale. I do not have anything in particular to add about the needed improvements around performance, UI, or anything else.

I have been using ClickHouse for about a year.

In my experience, ClickHouse is stable.

The scalability of ClickHouse is great. I would like to add that performance and the scalability needs are important aspects of ClickHouse.

The customer support for ClickHouse is fine, and I have used it. I would rate the customer support as ten out of ten.

Positive

I previously used Redshift, as it did not fit our use case.

I purchased ClickHouse through the AWS Marketplace since that was how I could deploy it on AWS.

In terms of specific outcomes, I have noticed faster report generation, but I cannot really say the cost has reduced much. I have already mentioned what returns I got in terms of driving our product.

My experience with pricing, setup cost, and licensing was straightforward, as it is open-source.

Before choosing ClickHouse, I evaluated all the major cloud database providers that have something analogous to ClickHouse.

I would rate ClickHouse as a nine or an eight on a scale of one to ten. I chose nine because there are certain improvements, as I previously mentioned, that prevent me from giving it a ten. My advice for others looking into using ClickHouse is to understand your use case and choose accordingly, as it is good at many things and may fit well with analytics use cases. I appreciate the team behind ClickHouse; it is a really great product. My overall review rating for ClickHouse is nine.

Negative

ClickHouse serves as our main OLAP system. We have almost three lakh plus IoT devices where we receive the raw feed through pipelines into ClickHouse, and from ClickHouse, we customize the data as per the site so that each individual site can be monitored. We display analytics by site, by dispenser, or by a particular device. Each individual site owner or their staff will have permissions and other things, so they can only access their site's behavior regarding transactions or alerts. This entire telemetry data is pushed to ClickHouse using Kafka pipelines and Mej AI pipelines. From there, we build advanced analytics. Given ClickHouse's columnar storage, we retrieve data very fast. Therefore, we also use the data directly in our models. Recently, we used the LightGBM and LSTM deep learning model, where the input data was fetched from ClickHouse at the site level, dispenser level, and also other dispenser devices level. We use a lot of indexes and deduplication because the raw data sometimes has a lag in a pipeline or is broken, resulting in duplicate data entering ClickHouse. ClickHouse provides us with various important functions such as the `argMax`, which allows us to get the latest timestamp or record using that. We also use the ReplacingMergeTree in one of our tables for generating alerts using some logic. Whenever a new alert is closed, we use the ReplacingMergeTree and back up old data into another table. We employ multiple ClickHouse functions, which have been very helpful for our product.

In addition to the use case already mentioned, we use Materialized Views mainly for pre-aggregation, which minimizes latency. We also have summary tables—metadata per device, for instance—and lookup tables for converting various strings to integer formats for quick lookups. We utilize pre-aggregated materialized views or temporary tables to minimize the database impact on storage. We use ReplacingMergeTree, Materialized Views, and Kafka streaming to ingest data into ClickHouse, along with Mej AI preprocessing.

The best feature ClickHouse offers us is its performance on large datasets. It is consistently fast for analytical queries involving billions of rows. Time range aggregations, group by operations, and joins are simplified, making our work more efficient. We utilize the MergeTree engine for partitioning and indexing, and I appreciate the simplicity of automatic indexing that occurs whenever we create a table by providing the order by clause. We have different engines such as MergeTree, ReplacingMergeTree, and aggregated pre-aggregated daily for time series. These options are easy and flexible, even for our junior engineers. The Materialized Views and rollups are particularly impressive, as we continuously build pre-aggregated tables at daily and hourly levels. The documentation provided by ClickHouse is also quite user-friendly and easy to navigate. Additionally, the columnar architecture allows for strong compression, enabling us to store a significant amount of history without excessive storage costs.

ClickHouse has positively impacted our organization. The low cardinality feature stands out as incredibly useful because it provides a smaller storage footprint, faster joins, and quicker group by queries. The TTLs support lifecycle management, allowing us to drop older raw data as discussed. We drive backups from our main primary table after 14 days into a cheaper disk. Projections, similar to lightweight materialized indexes, are also helpful for specific query patterns. Our vectorized execution improves the efficiency of extracting complex aggregated data over billions of rows within a short timeframe. ClickHouse supports JSON and semi-structured data excellently, making it easier to handle complex IoT telemetry data. The documentation, alongside its integrations with Python, Pandas, or AWS SageMaker, facilitates model training. We collect IoT telemetry data from three lakh plus devices, encompassing over 30,000 sites and about one and a half to two lakh dispensers. Our daily data load is initially 100 GB, which compresses down to approximately 10 GB in ClickHouse. We retain data for 14 days, resulting in a very quick latency of less than one second on our UI for machine learning API inferences, thanks to the efficient partitioning provided by ClickHouse. We also provide daily and hourly summary tables for our site teams, aiding our aggregations. The cost reductions due to compression benefit us significantly. We use the TTL function and carry out our data backup efficiently. Integrating with MLflow has simplified data retrieval for model training as ClickHouse provides the data quickly without encountering I/O failures in our pipelines.

ClickHouse could be improved further in several areas. I believe the areas where ClickHouse could improve involve more intuitive error messages. Additionally, it would be beneficial to have short instructional videos for users new to ClickHouse, which could help them understand its functionalities better. The documentation is already quite comprehensive, but a summary of key points differentiating ClickHouse from others would be beneficial.

In terms of managing multiple Materialized Views, tracking their lag can be tricky, and additional features for tracking query lineage or transformations could enhance the user experience.

ClickHouse has proven to be stable in my experience. We have not encountered any serious bugs as we run it in production for over five years. My company started in 2018, and it is now 2025, so I have gained experience over one to two years. I can confidently say that it is very consistent and stable even when handling high volume loads and real-time streaming analytics across financial and operational domains. It remains consistent as data grows, and ingestion has also been stable. Materialized Views, rollups, and performance have proven reliable, with no major outages experienced.

ClickHouse demonstrates impressive scalability. Currently, I'm working with billions of rows, and I can confidently say that ClickHouse is very scalable. The vertical scalability is impressive, with high insert throughput, allowing millions of rows per second with low latency. Our data growth is significant, and our horizontal scalability is effective since we distribute it across clusters. We also take advantage of parallel processing with our multiple CPU cores to aid scalability, making ClickHouse easy to scale.

The customer support for ClickHouse has been excellent. We interacted through email and utilized a chatbot, where the responses were typically prompt and constructive. When we faced any challenges, the ClickHouse support team provided helpful resolutions.

Negative

Before ClickHouse, we did not use any other solutions at this company. Initially, we deployed ClickHouse on our EC2 clusters and instances but later moved to ClickHouse Cloud. However, we do use MySQL for transactional database needs, as both analytics and transactional requirements complement one another, allowing us to have efficient operations.

ClickHouse Cloud saves a lot of time for our DevOps engineers since there isn't much deployment involved and everything is served directly, leading to increased efficiency and productivity. Our storage efficiency significantly reduces costs. While I cannot provide exact numbers, I can affirm that the time I save as a data scientist and ML engineer is considerable. I don't wait two or three hours for data to be read from CSV files or to utilize Spark anymore. I receive data instantly in minutes even for large aggregations. Therefore, analysts and engineers like myself do not spend time waiting on heavy SQL queries. The developers instantly access the data they need, improving overall productivity. I estimate we save four to five hours per person per week due to this efficiency, translating to around 20 to 25 hours saved monthly for each individual. Although I cannot quantify the monetary savings precisely, our 10x data compression has made a substantial difference in operational efficiency. The onboarding experience for junior engineers is also pleasant, given the straightforward design of ClickHouse.

I did not deal much with pricing issues. I discussed the pricing with our CTO and founding members, and I found ClickHouse's pricing to be efficient in comparison to other services such as Redshift. The setup costs are flexible for ClickHouse hosting, and the privacy aspects are simple to navigate. Overall, my experience has been quite good.

Prior to choosing ClickHouse, we evaluated several options including Redshift, BigQuery, and Snowflake. We did not select them because they are optimized more for batch reporting rather than real-time analytics. Their higher storage and compute costs for managing billions of events of telemetry data were additional deterrents. Even our tests with Redshift, PostgreSQL, and TimescaleDB showed slower aggregations and performance limitations at high scales, prompting us to choose ClickHouse, which provides fast analytical performance, excellent compression, and beneficial SQL flexibility.

For those considering ClickHouse, I suggest it as an excellent choice if your use case revolves around analysis and real-time streaming. The customer support, reliability, and easy-to-understand documentation combined with SQL familiarity make ClickHouse a preferable product versus others. The competitive customer support ensures we can get assistance quickly. ClickHouse's data compression is vital for minimizing storage costs, while functions such as low cardinality, `argMax`, `ReplacingMergeTree`, and different MergeTree engines prove beneficial for various smaller use cases within your product. I would rate this product an 8 overall.

My main use case for ClickHouse is for logging, where our whole application, consisting of microservices, sends the logs to ClickHouse, and the second major use case is for the dashboard, as we rely heavily on ClickHouse for our major dashboards.

We have multiple scenarios in which we have 62 to 63 microservices running, and we use ClickHouse for parallel log sending, which works fine. ClickHouse is a very performant database in storing logs, and fetching logs from 10 to 60 days back happens in no time, which is the best thing about ClickHouse. In terms of dashboards, we use it for querying and displaying data in Grafana, and we appreciate the support it offers for direct communication with Grafana to visualize our data further.

ClickHouse is a very performant database in storing logs, and fetching logs from 10 to 60 days back happens in no time, which is the best thing about ClickHouse. We appreciate the support it offers for direct communication with Grafana to visualize our data further.

ClickHouse positively impacted our organization by absorbing the whole logging system without hassle, storing logs for six months efficiently.

Regarding performance, we tried multiple solutions when Kibana was failing, including PostgreSQL, MySQL, and even MongoDB for log ingestion of huge volumes, but ClickHouse outperformed all databases we tested, leading us to choose it for further use cases.

We would like to have fuzzy search capabilities in ClickHouse like we had with Kibana because there are scenarios where we cannot search keywords fuzzily in ClickHouse, whereas Elasticsearch allows that, and in such cases, Elasticsearch outperforms ClickHouse.

We would love to have a fuzzy search feature in ClickHouse to allow searching across rows without hassle, similar to Kibana, making querying individual or multiple rows a very easy process in ClickHouse. Additionally, the UI of ClickHouse is pretty basic, and I would love to have a more efficient UI along with improved security features.

I have been using ClickHouse extensively for various purposes in my previous company, so we have been using ClickHouse for around two years.

ClickHouse is stable in my experience.

ClickHouse is quite scalable, especially when we are using an AWS instance.

I didn't get a chance to interact with ClickHouse's customer support.

Negative

Earlier, we were using Elasticsearch and Kibana, but we needed to switch to ClickHouse, realizing it was awesome to work with. In scenarios where Kibana and Elasticsearch were not allowing us to parallelly write logs to the database, I carried out a performance test under heavy load, verifying that ClickHouse supports parallel execution of logs, and it performed really well, which is the core feature we love about ClickHouse.

We didn't have any issues regarding pricing, setup cost, or licensing.

The integration and documentation for ClickHouse are flawless; we didn't need to add anything because every feature is explained so well that we did not have concerns about how everything is going to work.

We set up ClickHouse manually using the AWS instance and the open-source version.

We have saved a lot with ClickHouse regarding parallel execution, efficiently storing logs that we ingest, which used to be around 10 to 20 million rows per day, all executed in parallel. Previously, we had to increase the servers and run up the disks for Kibana, but with ClickHouse, we didn't need to spend much on resources, cutting costs by around 25 to 30%.

We didn't have any issues regarding pricing, setup cost, or licensing.

We tried various options, but ClickHouse outperformed every solution, proving to be the best choice for us.

ClickHouse is really easy to use, and I don't have anything further to add because it integrated directly into our application without any hassle.

ClickHouse is a go-to database for performance. It natively supports features such as compression, making it a great choice for logging, so it is highly recommended for anyone needing raw performance out of the box.

It is just a typical customer relationship with the vendor. I received a gift card.

I would rate ClickHouse around 8.5 to 9 on a scale of one to ten because there are some scopes for improvement, as I mentioned earlier, and I chose a rating of nine out of ten for this review.

ClickHouse has been used for more than a year as the primary solution for an observability data platform hosted on AWS EC2 instances. Data flows from S3 through Kinesis Data Streams and is processed in DataBricks using Medallion architecture, which includes bronze, silver, and gold layers. Once the gold layer is finalized, the data is sent to the ClickHouse cluster hosted on EC2 nodes.

ClickHouse serves as the data sync solution in the workflow, processing data from over 9,000 retail stores from CVS Health in JSON format to make it meaningful for analytical purposes. This data is stored in ClickHouse in the form of multiple tables, such as logs, events, metrics, and traces, and is used for reporting purposes in Grafana and for ML model training.

ClickHouse also hosts as a database sync for the front-end application. A chatbot prompt has been developed on this data that has been hosted, with the model trained based on it. When a user sends a text prompt, the model sends a more generalized or granular query to get the desired results quickly, so the user does not have to write their own query. Instead, the user just needs to provide the prompt of what kind of query they are looking for, and the AI prompt will provide the required query.

ClickHouse offers several best features, including the S3 engine function and the ReplicatedMergeTree function. Instead of storing data in EBS volumes, data is stored mainly in S3 Express, which provides computation speed comparable to an EBS volume. The ability to configure ClickHouse using XML configs is also highly appreciated. With an 18-node cluster, multiple zone replication can be configured across three availability zones in US East 1. The configs allow data to be stored in multiple locations separately, and with ReplicatedMergeTree, data needs to be sent to only six nodes, and that gets replicated automatically to all 18 nodes. These features are beneficial, and since ClickHouse is an OLAP database, it provides faster analytical speeds, which is really suitable for this use case.

For the S3 engine, a fault-tolerant data storage pattern was sought, as the data is highly secure and contains PII data. The concern was that data should not be lost or be in remote setups so that even if a failure occurs, data is not lost or accessed by unauthorized individuals. S3 engine was considered a very encrypted and fault-tolerant solution, and it has proven to be very reliable for storing data in ClickHouse. Regarding ReplicatedMergeTree, high write and read rates are dealt with because a real-time analytical application is being created, so avoiding reliance on all 18 nodes for read and write simultaneously was important. ReplicatedMergeTree helps maintain an isolated environment for writing on specific nodes while allowing all nodes to participate in read queries, which is how both S3 engine and ReplicatedMergeTree have helped.

ClickHouse provides great query speeds because it is an OLAP database, so naturally, it provides higher speeds. For cost optimization, after deploying the cluster on-premises and using S3 Express, approximately 5x cost savings were achieved on data storage. Initially, a budget of $15,000 monthly was anticipated for data storage with EBS volumes, but upon switching to S3 Express, storage costs dropped to $3,000. In terms of scalability, the observability data that was sitting idle was expanded to multiple terabytes and incorporated security data from AWS, Tanium, Azure, and CrowdStrike, scaling up to multiple petabytes. This solution led to high performance, prompting the ClickHouse team to invite this organization to share its performance at their annual conference.

ClickHouse could be improved concerning data insertion, especially given the high amount of data handled. Constant efforts are made to optimize the features on its own, but with merges and inserts, only a single insert query can be performed allowing for the input of only 100,000 rows per second. It would be beneficial to insert more data and have configurations that are less user-operated. Ideally, ClickHouse would optimize itself to handle these processes automatically, reducing the need to contact the ClickHouse support team for infrastructure optimization.

Additionally, delays are experienced when trying to delete databases with corrupt data, taking too much time and causing major outages, which necessitate contacting multiple teams across continents for resolution. The community surrounding ClickHouse also seems limited, providing a reliance on documentation, and there is a scarcity of developers working with ClickHouse, which hinders growth. If ClickHouse were more user-friendly and technically feasible, it would likely see greater expansion in usage.

More than four years have been spent working in the current field.

ClickHouse has been stable and reliable for most workloads.

ClickHouse has handled growth and changes in data volume remarkably well.

Overall, customer support has been positive, and the representatives are knowledgeable. However, during major issues, such as the three to four-day outage experienced, the support team was less available, possibly due to tight schedules. If more timely support could be provided during critical issues, situations could have been resolved much more quickly, saving considerable time.

Positive

ClickHouse was the first solution used; the product was built from scratch, and ClickHouse was started from the first stage. No other solution was considered.

ClickHouse is deployed in a private cloud setup. An AWS VPC is configured with multiple AWS nodes, comprising two environments: dev with a 12-node cluster and prod with an 18-node cluster. Each node is equipped with 128 GB RAM and 128 GB of SSD, backed by S3 for data storage, and comes with a CHProxy layer of four nodes in both environments to handle read requests. Write requests are handled directly through an IP basis, and AWS Route 53 and other DNS services have been incorporated for the VPC communication.

Before choosing ClickHouse, Elastic was evaluated for observability data. However, since the organization was previously using Elastic and scrapping it due to higher costs with the cloud version, ClickHouse was opted for instead.

This interview could be improved by not asking a single question multiple times. The same question was asked in different ways, and it is recommended to avoid stressing the interviewer or interviewee by not repeating questions. If the answer provider has already given an answer, there is no need to ask for more details again.

My advice to others considering ClickHouse is to opt for the cloud version instead of the on-premises version if budget permits. This decision saves considerable time on managing infrastructure and allows more focus on application and product development. This review has been rated with a score of six out of ten.

My main use case for ClickHouse is data ingestion and for its OLAP properties, as we had use cases where database locks were slowing us down and because ClickHouse does not have that, we chose to use it.

I could give you a quick, specific example of how I'm using ClickHouse for data ingestion where the lack of database locks helped us when we were parsing IOCs among other things, as a lot of that data has to be processed really quickly and ingested into the database for further processing and identifying which IOCs are compromised.

ClickHouse helped us solve the problem that we were having and it's one of the two databases we used at Cyware—one was Postgres, the other was ClickHouse.

The best features ClickHouse offers are its OLAP features because, given that there are no database locks and its eventual consistency, that is the biggest feature that we have or that solved our problems.

The eventual consistency and lack of database locks specifically benefit my team in terms of speed and reliability, as once data is ingested, we have to quickly process it and then show the outputs to the user, say there are ten indicators of compromise, and we have our own database where we tally whether these IPs or IOCs that we are scanning right now are marked or red flagged before or not, so we have to quickly scan them, process them and then give an output, and that helped us with the reliability part, the speed part, while eventual consistency is used on a different side of the product.

ClickHouse has positively impacted my organization, as there was an entire exercise done on which database we were supposed to use for solving our problems, and we found ClickHouse was the one performing the best, which is when we adopted it.

ClickHouse can be improved on the documentation side, and there is one small constraint that is mentioned in ClickHouse documentation, which is a partition limit of ten thousand that we hit, so if that can be increased or there are workarounds around it, that would be great.

I chose nine out of ten because, as I mentioned, the improvement side and the ten thousand partition limit created issues that we were hitting quite frequently, but with some schema manipulations we did manage to find a workaround, although that could have been avoided had things been better documented on how we could have solved this problem in a different approach, which took some bandwidth.

I do not have any other improvements I think ClickHouse needs, besides the documentation and partition limit.

I have been using ClickHouse for about a year, maybe slightly more than that.

ClickHouse is stable, as we did not encounter stability issues in production, but in the dev environment, one of the seniors did flag one specific point where we found some inconsistencies, although I think they did find a workaround around it, but it was stable for us.

ClickHouse's scalability is good.

We previously used Postgres, and we encountered issues with Postgres, which was again, as I mentioned, why we did a study on switching.

I have seen a return on investment, as I can share that on the engineering side we had improvements in database performance, but for the metrics asked, time saved, fewer employees needed, I do not have them.

My experience with pricing, setup cost, and licensing was such that the setup costs were just my own bandwidth, while licensing and pricing were done by other members of the team so it was abstracted away from me, and I am not aware of it.

Before choosing ClickHouse, we evaluated other options such as Apache Druid and Pinot from Apache, and then there was a study.

The advice I would give to others looking into using ClickHouse is that on the engineering side, if there is some OLAP use case or anywhere where data needs to be ingested at very high rates or there is a use case for eventual consistency, then perhaps it can be used. I gave this review a rating of nine out of ten.

My main use case for ClickHouse is that I used it earlier at my previous companies for transactional data of blockchain, so we could provide analytical data to our clients.

A specific example of how I used ClickHouse for blockchain transactional data is that our clients would not directly interact with ClickHouse database, but we had our entire SaaS application that used to do that. We had a lot of ETLs that wrote into ClickHouse database that we built, with ClickHouse being one of the primary databases we used for real-time calculations of different account balances or tracking entities through multiple channels.

The unique aspect about my main use case with ClickHouse is that we made it into multiple shards and had multiple replicating instances, alongside using replicated merge trees and neat materialized views. However, the most painful part was the cold starts of new chains, as materialized views need to be filled, deleted, and rebuilt again because they only track upserts, not deletions, which wasted significant amounts of my time.

The best feature ClickHouse offers is speed, no question.

I would add that the connectors and ClickPipes are really cool tools, and the ETL capabilities around ClickHouse are also improving, with good Kafka integrations, making ClickHouse excellent, particularly with many connectors to ClickHouse and CDC systems.

ClickHouse positively impacts my organization by potentially saving costs if you are migrating from an OLAP database or OLTP database to an OLAP database, but cost-wise, it depends on how you set it up and how many replicating systems you need, with bare-metal costs depending on that. There is no better option than ClickHouse in all OLAP-based databases, so I think it is best to use ClickHouse in that regard.

ClickHouse can be improved, primarily in terms of the materialized views that do not change based on the base table, which is painful to keep reusing due to the demonstrated architecture.

I would add that we could benefit from more connection options with ClickHouse, as the connections are good, and while the documentation is solid, it could use more graphics to help explain things, particularly since I have not seen the documentation in the last year and a half. Support-wise, the team is really solid, and I had a chat with them a few times—they are good product folks.

My experience with ClickHouse's documentation is that it needs improvement; I think it can be made more beginner-friendly, while the community support is really good.

I have been using ClickHouse for three years.

ClickHouse is stable.

ClickHouse's scalability is a ten.

I did not use customer support that much.

My experience with ClickHouse's security features is limited, as I have not used many of them.

I am satisfied with the monitoring and observability features in ClickHouse, rating them as good, not great.

Negative

The ease of setting up and configuring ClickHouse for my needs is a nine.

The setup and configuration process is a nine for me because I think the onboarding could be better.

In terms of return on investment, my focus was more on developer productivity than on money saved per se, but compared to other databases we used, it was fairly in a similar range. The number of employees needed did not change initially, but we could reduce the amount of employees needed when we migrated to ClickHouse Cloud.

My experience with pricing, setup cost, and licensing indicates that it is very expensive—ClickHouse is the most expensive option.

After switching to ClickHouse, I noticed specific outcomes such as cost savings if we put the right engines in place, and our metrics indicated at least 500 requests per second at peak times, with more typical requests being around 20 or 30 per second, handled adequately by our systems. We started with about 200 GB of data during testing, which grew to about five or six TB in production, indicating our capacity to handle a huge dataset.

My advice for others looking into using ClickHouse is that it is a good system that remains stable. I would rate this review as a nine.