Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Some entity spoiled the link "they don't like it" by adding (R), correct link is [1]
1. https://github.com/ClickHouse/ClickHouse/issues/49383#issuec...
by Perepiska - I have used tinybird for production fraud monitoring and customer facing analytics. Javi and the team are great to work with. I have also used regular clickhouse cloud.
I initially tried tinybird out just to rule out clickhouse as an option for my workload when I was planning on going with Apache Druid but then found out for my workloads they blew it out of the water.
So I definitely recommend them and the whole clickhouse ecosystem in general for any kind of high throughput read and write analytics work.
- Complex systems have complex operations and problems. I think isolating the read and write workloads and separating the read queries by departments or even users is a distinct possibility especially with technologies like DuckDB.by dev_l1x_be
- That is exactly where all the high scale stuff like Trino and StarRocks have gone (and ClickHouse can use S3 as storage too). However, the problem you run into is when you want to index stuff- secondary indices are tightly coupled to the query engine, so in practice you arent going to use StarRocks to write and index data to the object store, and then use ClickHouse or Trino to query it. I think it would be a useful development to decouple writes and reads, but this requires a common indexing scheme, and then once you have this standard, in principle lots more indexing plugins can be written and all compatible query engines can use them. Apache DataFusion is probably the right framework to build off of.by a34729t
- What kind of systems are generating enough useful analytics data to ever scale to petabytes in the first place?
It's difficult (for my bird brain, at least) to imagine a scenario where such volume of analytics data would ever be necessary.
by wackget - they are working with CDNs and others companies like Vercel, localstack or canva and those companies generate a lot of (really a lot) data.
In fact, they have solutions teams to check with the clients what they are storing and what they really need to store, how to consume it, etc.
by razes - It's multiple records per user over time. See something like posthog. One interaction with a form can generate 10-15 events. eg enter page, click link with text "settings", change input, clicked input, etc. So active users can generate 15-150 events per session, each ~1kb to 2kb in size.
The reason to store that data is to be able to build analytics and funnels you didn't anticipate and construct them retrospectively. You can of course save massive amounts of storage by building rollups and aggregating, but that prevents you from being able to eg change the funnels and see the funnel in the past.
10M users × 100 events/day × 1KB ≈ 1TB/day. A couple years gets you into PB range.
The other obvious thing is logs. Being able to have a vulnerability then go back in time and see if you were exploited is super valuable. See eg log4shell: if you kept records, you probably could go back and see if you'd been exploited.
by x0x0 - For those interested, there's also a second part [2025]: https://www.tinybird.co/blog/what-i-learned-operating-clickh...
(note: the first part was originally published April 2025 according to the date tooltip)
by mrngm - I’m operating a terabyte-scale Clickhouse - but only because I left Langfuse running for a few months on a MacBook :)
But seriously Clickhouse does love disk space.
by threecheese - But on the same time it is super efficient with it compare to other solutions. Kind of efficient for application logs for example.by cnkk
- > "Every single company handling ClickHouse® struggles with ingestion."
Very true. Reading about "too many parts" gave me flashbacks.
(previously owned ingestion into CH at PostHog, no longer)
by yakkomajuri - Scaling during that era was fun. Slack was non-stop:
:oof-1: CH needs more disk to keep up with merges.
We ran CH way too lean in those days.
by fuziontech - I just wish Amazon would offer it as an RDS DB; it'd make my life so much easier.by bradleyy
- You can use ClickHouse cloud to host it on AWS.
But given the majority of use-cases of CH, AWS can be quite expensive.
by f311a - Do any two teams actually operate it in anything like the same way though?
What I saw of it, especially some years ago, was it was highly particular, and everyone had their own odd habits built around running it, ingestion, querying, everything, to the point I suspect there are a non trivial number of companies using it where it is actually the core operational expertise of the company, despite them all appearing to be in totally different domains.
by fidotron - You can use actual CH Cloud on AWS?..by andriy_koval
- A couple weeks ago I was scanning Github for repos with frequent commits to identify so-called "software factories" and was surprised to see clickhouse. I wouldn't touch it with a 10ft pole considering how quickly they're merging code into main. I'm talking 50+ commits per day and thousands of AI generated issues and triages. Check it out for yourself https://github.com/clickhouse/clickhouseby anguss
- Just wait till you find out how many commits per day to a product are occurring to most of the SaaS you rely on.
Clickhouse has a managed SaaS and it's their primary product. They have a lot of engineers. They're going to do a lot of commits.
by ryan_lane - The CTO himself reported 600 commits and 300 PRs each day. And they can do so because they have a massive CI [1]:
> Every day CI runs about 20..80 million tests in 600 commits and 300 pull requests
> Last year, ClickHouse spent 360 years of machine time for CI
I am no user of CH so I can't talk about their product. But we are talking about a company with 686 employees as per their LinkedIn, where ClickHouse is clearly the core of their business. Considering all of this, is 50+ commits a day that much?
[1] https://presentations.clickhouse.com/2026-openhouse-sf/great...
by ggcr - That's a lot of ®, curious how ClickHouse® Inc. is treating the use of its name by others ... Hopes it's not like Oracle with JavaScriptby lucrbvi
- It's in fact two ®'s too many: even the "they don't like it" link to the GitHub issue has them.by fusl
- > Tinybird is not affiliated with, associated with, or sponsored by ClickHouse, Inc. ClickHouse® is a registered trademark of ClickHouse, Inc.
Yeah, it sucks they need to do this. If I was a visitor to their website, I'd immediately want to know what ClickHouse, Inc. is and you'd realize ---> it's managed clickhouse, direct competitor... why would I use the one that needs all the ®'s
by mritchie712 - It's defensive language for sure, i don't know how much it adds of protection in reality, but i nonethelesss sympathize with the author if he feels the need to protect himself that way or signaling the risk he takes.by doe88
- They sell managed ClickHouse so I suspect it’s a precaution
- As an aside, I was stuck when turning on the Fulham v Crystal Palace game last week to find that Fulham have ClickHouse on their shirts this year, and Palace have Temporal AI. Talk about my worlds colliding.by walthamstow
- > For loads with over 20k rows/s and people pushing changes, you may need a full-time person to handle the cluster and take a look at the crazy queries people are going to write.
I think this was a benefit of DBA culture in previous eras. Not that the DBAs were specifically necessary to write good queries (often they'd need to work with application teams to guide them towards schemas/behavior that worked well) or to maintain the database (managed DB offerings obsolete a lot of this work), but because they functioned as gatekeepers and rate-limiters of what queries and schemas could exist.
In that mode, DBAs functioned a bit like a human/process version of a thin microservice wrapping database access functionality. A big benefit was that the rate of change of queries/schema changes/access patterns was controlled and had a higher probability of being reviewed and thought about by humans before it went live. This also resulted in an increased end-database-user culture of trying to make existing schemas/query patterns work before jumping straight to bespoke access patterns. That culture's not what you want as e.g. a startup or pro-rapid-big-refactors shop, but it is what you want when your DB reliability needs or query rate/dataset size are high.
I don't think it's a given that a gatekeeper team is worth the overhead and cost; that's situational. I do think that the code version of that team (aforementioned microservice that wraps DB accesses/schema changes and nothing else) is usually not worth the cost. In my experience, that pretty much always reduces reliability and free performance gains that come from using direct DB clients from user code.
by zbentley - hello we still exist :)by winrid
- I'm going to go out on a limb here and say that having a tuned LLM would probably be able to eliminate the need for a full time DBA query analyst.
Disclaimer: I've never managed a ClickHouse cluster, let alone one of this size.
by pstuart - Most startups can just scale your traditional separation of compute & storage here though. You’d be shocked how well duckdb against s3 scales for 99.9% of use casesby bushbaba
- Instead we're... listen to this... we're going to take a software developer right. Just a normal developer right. We're going to make them be the database expert right. And the cloud expert. And we're going to put them on call. We're going to have them debug linux logs, and optimize our AWS costs. They'll be there for client escalation work. And big sales calls. From time to time we'll even have them do front end work.
And get this. We pay them the exact same.
by tmpz22