{"slug": "clickhouse", "name": "ClickHouse", "category": "databases", "category_name": "Databases", "description": "Open-source column-oriented OLAP database for real-time analytical queries over large datasets.", "recommenders": 16, "commenters": 33, "warners": 1, "score": 16.743, "rising": -1.58, "first": "2025-11-14", "latest": "2026-10-24", "why": "Praised for very fast analytical queries, often after moving off Postgres, and for cheap, low-maintenance log and event storage.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 17, "neutral": 14, "compare": 4, "warn": 1}, "spark": [2, 0, 1, 1, 0, 2, 0, 7, 1, 2, 1, 0], "listed": true, "loved": ["Query speed", "Logging backend"], "caveat": "Not transactional", "short_quote": "we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never looked back. Much more performant, practical, and a lot less maintenance.", "icon": true, "domain": "clickhouse.com", "github_repo": null, "official_url": "https://clickhouse.com", "pricing": "open source", "aliases": ["ClickHouse"], "verdict": [{"text": "Praised for very fast analytical queries, often after moving off Postgres,", "cites": [{"id": 789836753, "item_id": 49364797, "url": "https://news.ycombinator.com/item?id=49364797", "by": "rgbrgb", "date": "2026-08-19", "stance": "recommend", "quote": "truly amazing software that just works without any tuning for this kind of exploratory analytics workload.", "excerpt": "i love postgresql but once we added ai-generated dashboard to our homegrown analytics tool [0] some of the crazy (amazing) dashboards that the ops team was building began accumulating horrendously slow db queries. I considered dynamically adding indexes or alerting around postgres slow queries but also quickly prototyped mirroring the postgres data in clickhouse. At first could not believe how fast clickhouse was on ", "context": "", "use_case": "analytics queries", "switched_from": "PostgreSQL", "story": "PostgreSQL for Everything"}, {"id": 777619024, "item_id": 48601189, "url": "https://news.ycombinator.com/item?id=48601189", "by": "rozenmd", "date": "2026-06-19", "stance": "recommend", "quote": "Since moving to Clickhouse I think I can grab a full year's data in around 200ms", "excerpt": "I used to keep all of OnlineOrNot's timeseries data entirely in a hot postgres db with the rest of the relational data. Used to take a few seconds to get a week's uptime data and do some useful analysis. Since moving to Clickhouse I think I can grab a full year's data in around 200ms (probably less if I try optimising it). Still completely blows my mind everyday.", "context": "", "use_case": "timeseries uptime data analytics", "switched_from": "PostgreSQL", "story": "Ten years of ClickHouse in open source"}, {"id": 754835952, "item_id": 47177247, "url": "https://news.ycombinator.com/item?id=47177247", "by": "dirtbag__dad", "date": "2026-02-26", "stance": "recommend", "quote": "before we switched to clickhouse and it was night and day.", "excerpt": "OLAP conveniently not mentioned. Anyone have any suggestions for this? We tried to get as much mileage as we could out of Postgres before we switched to clickhouse and it was night and day.", "context": "", "use_case": "OLAP analytics", "switched_from": "PostgreSQL", "story": "You Just Need Postgres"}]}, {"text": " and for cheap, low-maintenance log and event storage.", "cites": [{"id": 746096979, "item_id": 46631061, "url": "https://news.ycombinator.com/item?id=46631061", "by": "physicles", "date": "2026-01-15", "stance": "recommend", "quote": "we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month.", "excerpt": "I can't get over how expensive these observability platforms are. Last I looked (and looked again just now), if we were to take all our structured logs from all services and send them to Datadog with our current retention policy, it would just about double our current IT spend. Instead, we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month. What am I missing? What'", "context": "", "use_case": "log storage", "switched_from": "", "story": "I built Vector. Now I'm answering the question your observability vendor won't"}, {"id": 777713888, "item_id": 48607118, "url": "https://news.ycombinator.com/item?id=48607118", "by": "mial", "date": "2026-06-20", "stance": "recommend", "quote": "we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never looked back. Much more performant, practical, and a lot less maintenance.", "excerpt": "On top of being a really good OLAP database, what has been a game changer for me is the built-in connectors for bringing in data from remote sources. It can manage automatic recurring import of a s3 folder containing parquet/json files and it can also connect directly to Postgres. For our data warehouse at a medium sized newspaper, we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never l", "context": "data warehouse at a medium sized newspaper", "use_case": "data warehouse", "switched_from": "Druid", "story": "Ten years of ClickHouse in open source"}, {"id": 734968067, "item_id": 45935504, "url": "https://news.ycombinator.com/item?id=45935504", "by": "didierbreedt", "date": "2025-11-14", "stance": "recommend", "quote": "We use Vector and Clickhouse for logging and works really well.", "excerpt": "I have found Grafana to be a decent product, but Prom needs a better horizontally scalable solution. We use Vector and Clickhouse for logging and works really well.", "context": "", "use_case": "log storage", "switched_from": "", "story": "I can't recommend Grafana anymore"}]}, {"text": " Commenters stress that it complements rather than replaces Postgres,", "cites": [{"id": 777583328, "item_id": 48598958, "url": "https://news.ycombinator.com/item?id=48598958", "by": "eklavya", "date": "2026-06-19", "stance": "recommend", "quote": "I use clickhouse AND postgres. Clickhouse is not a replacement for postgres at all.", "excerpt": "Not to mention ACID and CAP and all that. I use clickhouse AND postgres. Clickhouse is not a replacement for postgres at all.", "context": "", "use_case": "analytics alongside Postgres", "switched_from": "", "story": "Ten years of ClickHouse in open source"}, {"id": 778740018, "item_id": 48671251, "url": "https://news.ycombinator.com/item?id=48671251", "by": "Imustaskforhelp", "date": "2026-06-25", "stance": "recommend", "quote": "something like clickhouse or redis combined with postgresql might be more than enough for many things", "excerpt": "I agree, the reason why I had submitted this HN submission post was because I was getting way too deep into the weeds of new databases like surrealdb/tigerbeetle/scylladb etc. which while are an interesting problem to think through because well, it makes me feel smarter knowing these databases. I still felt like postgresql was enough, (at best something like clickhouse or redis combined with postgresql might be more ", "context": "", "use_case": "analytics alongside PostgreSQL", "switched_from": "", "story": "PostgreSQL Is Enough"}]}, {"text": " and some find it heavier to operate than DuckDB.", "cites": [{"id": 757104705, "item_id": 47319044, "url": "https://news.ycombinator.com/item?id=47319044", "by": "antonio-mello", "date": "2026-03-09", "stance": "neutral", "quote": "I use ClickHouse for production analytics", "excerpt": "The \"early React\" analogy resonates. I've been seeing the same pattern with MCP (Model Context Protocol) \u2014 the primitive is powerful (AI assistants calling tools via a standard protocol), but most implementations are still gluing things together ad-hoc. There's a gap between \"I can build an MCP server\" and \"this is a polished, opinionated product.\" The DuckDB choice is smart for local-first. I use ClickHouse for prod", "context": "", "use_case": "production analytics", "switched_from": "", "story": "Show HN: DenchClaw \u2013 Local CRM on Top of OpenClaw"}, {"id": 734822721, "item_id": 45926420, "url": "https://news.ycombinator.com/item?id=45926420", "by": "faizshah", "date": "2025-11-14", "stance": "recommend", "quote": "I found that clickhouse was the fastest", "excerpt": "I had to do something like this for a few TB of json recently. The unique thing about this workload was it was a ton of small 10-20mb files. I found that clickhouse was the fastest, but duckdb was the simplest to work with it usually just works. DuckDB was close enough to the max performance from clickhouse. I tried flink & pyspark but they were way slower (like 3-5x) than clickhouse and the code was kind of annoying", "context": "", "use_case": "processing TBs of JSON", "switched_from": "", "story": "650GB of Data (Delta Lake on S3). Polars vs. DuckDB vs. Daft vs. Spark"}]}], "praise": [{"label": "Query speed", "summary": "Users report large speedups on analytics queries, such as 60s to 0.5s and a year of data in about 200ms.", "quotes": [{"id": 789836753, "item_id": 49364797, "url": "https://news.ycombinator.com/item?id=49364797", "by": "rgbrgb", "date": "2026-08-19", "stance": "recommend", "quote": "truly amazing software that just works without any tuning for this kind of exploratory analytics workload.", "excerpt": "i love postgresql but once we added ai-generated dashboard to our homegrown analytics tool [0] some of the crazy (amazing) dashboards that the ops team was building began accumulating horrendously slow db queries. I considered dynamically adding indexes or alerting around postgres slow queries but also quickly prototyped mirroring the postgres data in clickhouse. At first could not believe how fast clickhouse was on ", "context": "", "use_case": "analytics queries", "switched_from": "PostgreSQL", "story": "PostgreSQL for Everything"}, {"id": 777619024, "item_id": 48601189, "url": "https://news.ycombinator.com/item?id=48601189", "by": "rozenmd", "date": "2026-06-19", "stance": "recommend", "quote": "Since moving to Clickhouse I think I can grab a full year's data in around 200ms", "excerpt": "I used to keep all of OnlineOrNot's timeseries data entirely in a hot postgres db with the rest of the relational data. Used to take a few seconds to get a week's uptime data and do some useful analysis. Since moving to Clickhouse I think I can grab a full year's data in around 200ms (probably less if I try optimising it). Still completely blows my mind everyday.", "context": "", "use_case": "timeseries uptime data analytics", "switched_from": "PostgreSQL", "story": "Ten years of ClickHouse in open source"}, {"id": 754835952, "item_id": 47177247, "url": "https://news.ycombinator.com/item?id=47177247", "by": "dirtbag__dad", "date": "2026-02-26", "stance": "recommend", "quote": "before we switched to clickhouse and it was night and day.", "excerpt": "OLAP conveniently not mentioned. Anyone have any suggestions for this? We tried to get as much mileage as we could out of Postgres before we switched to clickhouse and it was night and day.", "context": "", "use_case": "OLAP analytics", "switched_from": "PostgreSQL", "story": "You Just Need Postgres"}]}, {"label": "Logging backend", "summary": "A common choice for log storage with Vector, Grafana or OTel, outperforming Loki on the same hardware.", "quotes": [{"id": 777714784, "item_id": 48607174, "url": "https://news.ycombinator.com/item?id=48607174", "by": "jaysh", "date": "2026-06-20", "stance": "recommend", "quote": "substantially better performance on the same hardware", "excerpt": "Off the top of my head: - substantially better performance on the same hardware, even moreso for larger range queries (multiple days) - no new query language to learn - significantly more expressive as you said - agents for scraping logs use way less CPU (I used to use grafana-agent which used about 80%, vector uses sub 5%) - very intuitive to manage TTLs - I can keep some logs for 10 years, and some for 1 week based", "context": "", "use_case": "log storage and querying", "switched_from": "Loki", "story": "Ten years of ClickHouse in open source"}, {"id": 734968067, "item_id": 45935504, "url": "https://news.ycombinator.com/item?id=45935504", "by": "didierbreedt", "date": "2025-11-14", "stance": "recommend", "quote": "We use Vector and Clickhouse for logging and works really well.", "excerpt": "I have found Grafana to be a decent product, but Prom needs a better horizontally scalable solution. We use Vector and Clickhouse for logging and works really well.", "context": "", "use_case": "log storage", "switched_from": "", "story": "I can't recommend Grafana anymore"}, {"id": 746096979, "item_id": 46631061, "url": "https://news.ycombinator.com/item?id=46631061", "by": "physicles", "date": "2026-01-15", "stance": "recommend", "quote": "we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month.", "excerpt": "I can't get over how expensive these observability platforms are. Last I looked (and looked again just now), if we were to take all our structured logs from all services and send them to Datadog with our current retention policy, it would just about double our current IT spend. Instead, we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month. What am I missing? What'", "context": "", "use_case": "log storage", "switched_from": "", "story": "I built Vector. Now I'm answering the question your observability vendor won't"}]}, {"label": "Low maintenance", "summary": "Described as working without tuning and needing far less upkeep than multi-system stacks.", "quotes": [{"id": 777713888, "item_id": 48607118, "url": "https://news.ycombinator.com/item?id=48607118", "by": "mial", "date": "2026-06-20", "stance": "recommend", "quote": "we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never looked back. Much more performant, practical, and a lot less maintenance.", "excerpt": "On top of being a really good OLAP database, what has been a game changer for me is the built-in connectors for bringing in data from remote sources. It can manage automatic recurring import of a s3 folder containing parquet/json files and it can also connect directly to Postgres. For our data warehouse at a medium sized newspaper, we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never l", "context": "data warehouse at a medium sized newspaper", "use_case": "data warehouse", "switched_from": "Druid", "story": "Ten years of ClickHouse in open source"}, {"id": 746096979, "item_id": 46631061, "url": "https://news.ycombinator.com/item?id=46631061", "by": "physicles", "date": "2026-01-15", "stance": "recommend", "quote": "we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month.", "excerpt": "I can't get over how expensive these observability platforms are. Last I looked (and looked again just now), if we were to take all our structured logs from all services and send them to Datadog with our current retention policy, it would just about double our current IT spend. Instead, we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month. What am I missing? What'", "context": "", "use_case": "log storage", "switched_from": "", "story": "I built Vector. Now I'm answering the question your observability vendor won't"}, {"id": 789836753, "item_id": 49364797, "url": "https://news.ycombinator.com/item?id=49364797", "by": "rgbrgb", "date": "2026-08-19", "stance": "recommend", "quote": "truly amazing software that just works without any tuning for this kind of exploratory analytics workload.", "excerpt": "i love postgresql but once we added ai-generated dashboard to our homegrown analytics tool [0] some of the crazy (amazing) dashboards that the ops team was building began accumulating horrendously slow db queries. I considered dynamically adding indexes or alerting around postgres slow queries but also quickly prototyped mirroring the postgres data in clickhouse. At first could not believe how fast clickhouse was on ", "context": "", "use_case": "analytics queries", "switched_from": "PostgreSQL", "story": "PostgreSQL for Everything"}]}, {"label": "Data connectors", "summary": "Reads directly from S3, Postgres and other sources, and offers a single-binary local mode.", "quotes": [{"id": 774572144, "item_id": 48410759, "url": "https://news.ycombinator.com/item?id=48410759", "by": "f311a", "date": "2026-06-05", "stance": "recommend", "quote": "ClickHouse also supports a lot of data sources and has a local mode where you just use a single binary with local-only access.", "excerpt": "ClickHouse also supports a lot of data sources and has a local mode where you just use a single binary with local-only access. Coincidentally, I wrote an article today on how I use it for similar scenarios. It can fetch from S3, multiple databases at once, and so on. And you get all the benefits of a database when you need to join or postprocess data from multiple sources. https://rushter.com/blog/clickhouse-data-pro", "context": "", "use_case": "local data processing across sources", "switched_from": "", "story": "databow: a Rust CLI to query any database with an ADBC driver"}, {"id": 777713888, "item_id": 48607118, "url": "https://news.ycombinator.com/item?id=48607118", "by": "mial", "date": "2026-06-20", "stance": "recommend", "quote": "we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never looked back. Much more performant, practical, and a lot less maintenance.", "excerpt": "On top of being a really good OLAP database, what has been a game changer for me is the built-in connectors for bringing in data from remote sources. It can manage automatic recurring import of a s3 folder containing parquet/json files and it can also connect directly to Postgres. For our data warehouse at a medium sized newspaper, we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never l", "context": "data warehouse at a medium sized newspaper", "use_case": "data warehouse", "switched_from": "Druid", "story": "Ten years of ClickHouse in open source"}, {"id": 792882288, "item_id": 49555143, "url": "https://news.ycombinator.com/item?id=49555143", "by": "f311a", "date": "2026-09-03", "stance": "recommend", "quote": "we use regular CH in production. I'm pretty familiar with it and I can always run large queries on a production server with 1TB of RAM.", "excerpt": "Because we use regular CH in production. I'm pretty familiar with it and I can always run large queries on a production server with 1TB of RAM. Regular CH also support external data sources, so I can read 500GB of JSON from S3 and group by it on production server very fast and in memory.", "context": "uses ClickHouse in production", "use_case": "large analytical queries", "switched_from": "", "story": "Pre-Release of Polars 2.0"}]}, {"label": "Scalability", "summary": "Handles billions of events and can be deployed on clusters of many machines.", "quotes": [{"id": 781442833, "item_id": 48840177, "url": "https://news.ycombinator.com/item?id=48840177", "by": "BajajScooter", "date": "2026-07-08", "stance": "recommend", "quote": "that's why we used clickhouse db here which scales to billions of events easily", "excerpt": "Traditional databases(mysql, postgres) are perfect for transactional data. users, products, orders and the like. but they aren't made for tracking events which is typically huge volume. that's why we used clickhouse db here which scales to billions of events easily. We also have sdks that you can use in your app to publish the events to our services. You can also query these events on our app, create trends, funnels,", "context": "", "use_case": "high-volume event storage", "switched_from": "", "story": "Show HN: Pug.sh \u2013 open-source product analytics"}, {"id": 746685792, "item_id": 46667862, "url": "https://news.ycombinator.com/item?id=46667862", "by": "zX41ZdbW", "date": "2026-01-18", "stance": "recommend", "quote": "When a single server is not enough, you deploy ClickHouse on a cluster, up to thousands of machines", "excerpt": "When a single server is not enough, you deploy ClickHouse on a cluster, up to thousands of machines, e.g., https://clickhouse.com/blog/how-clickhouse-powers-ahrefs-the-worlds-most-active-web-crawler", "context": "", "use_case": "large-scale data processing", "switched_from": "", "story": "Command-line Tools can be 235x Faster than your Hadoop Cluster (2014)"}]}, {"label": "Resource efficiency", "summary": "Noted for efficient resource use and storage compressed 4-5x better than the previous setup.", "quotes": [{"id": 789888209, "item_id": 49368013, "url": "https://news.ycombinator.com/item?id=49368013", "by": "nikcub", "date": "2026-08-19", "stance": "recommend", "quote": "clickhouse is resource efficient", "excerpt": "I love OpenRouter, long time user. Stripe will hopefully be a good custodian. I just want to point out some features of OpenRouter that make it more than just a model selection and routing endpoint and that I find incredibly useful: 0/ Default routing is to the cheapest provider, but they're usually not the most performant. I'd guess 99% of OpenRouter integrations never tweak the default routing. Here you can setup c", "context": "", "use_case": "storing LLM traces", "switched_from": "", "story": "OpenRouter Is Joining Stripe"}, {"id": 777714784, "item_id": 48607174, "url": "https://news.ycombinator.com/item?id=48607174", "by": "jaysh", "date": "2026-06-20", "stance": "recommend", "quote": "substantially better performance on the same hardware", "excerpt": "Off the top of my head: - substantially better performance on the same hardware, even moreso for larger range queries (multiple days) - no new query language to learn - significantly more expressive as you said - agents for scraping logs use way less CPU (I used to use grafana-agent which used about 80%, vector uses sub 5%) - very intuitive to manage TTLs - I can keep some logs for 10 years, and some for 1 week based", "context": "", "use_case": "log storage and querying", "switched_from": "Loki", "story": "Ten years of ClickHouse in open source"}]}], "caveats": [{"label": "Not transactional", "summary": "Commenters say it is not a Postgres replacement and is best paired with one.", "quotes": [{"id": 777583328, "item_id": 48598958, "url": "https://news.ycombinator.com/item?id=48598958", "by": "eklavya", "date": "2026-06-19", "stance": "recommend", "quote": "I use clickhouse AND postgres. Clickhouse is not a replacement for postgres at all.", "excerpt": "Not to mention ACID and CAP and all that. I use clickhouse AND postgres. Clickhouse is not a replacement for postgres at all.", "context": "", "use_case": "analytics alongside Postgres", "switched_from": "", "story": "Ten years of ClickHouse in open source"}, {"id": 778740018, "item_id": 48671251, "url": "https://news.ycombinator.com/item?id=48671251", "by": "Imustaskforhelp", "date": "2026-06-25", "stance": "recommend", "quote": "something like clickhouse or redis combined with postgresql might be more than enough for many things", "excerpt": "I agree, the reason why I had submitted this HN submission post was because I was getting way too deep into the weeds of new databases like surrealdb/tigerbeetle/scylladb etc. which while are an interesting problem to think through because well, it makes me feel smarter knowing these databases. I still felt like postgresql was enough, (at best something like clickhouse or redis combined with postgresql might be more ", "context": "", "use_case": "analytics alongside PostgreSQL", "switched_from": "", "story": "PostgreSQL Is Enough"}]}, {"label": "Operational complexity", "summary": "Some find DuckDB simpler for single-node work despite ClickHouse being faster.", "quotes": [{"id": 757104705, "item_id": 47319044, "url": "https://news.ycombinator.com/item?id=47319044", "by": "antonio-mello", "date": "2026-03-09", "stance": "neutral", "quote": "I use ClickHouse for production analytics", "excerpt": "The \"early React\" analogy resonates. I've been seeing the same pattern with MCP (Model Context Protocol) \u2014 the primitive is powerful (AI assistants calling tools via a standard protocol), but most implementations are still gluing things together ad-hoc. There's a gap between \"I can build an MCP server\" and \"this is a polished, opinionated product.\" The DuckDB choice is smart for local-first. I use ClickHouse for prod", "context": "", "use_case": "production analytics", "switched_from": "", "story": "Show HN: DenchClaw \u2013 Local CRM on Top of OpenClaw"}, {"id": 734822721, "item_id": 45926420, "url": "https://news.ycombinator.com/item?id=45926420", "by": "faizshah", "date": "2025-11-14", "stance": "recommend", "quote": "I found that clickhouse was the fastest", "excerpt": "I had to do something like this for a few TB of json recently. The unique thing about this workload was it was a ton of small 10-20mb files. I found that clickhouse was the fastest, but duckdb was the simplest to work with it usually just works. DuckDB was close enough to the max performance from clickhouse. I tried flink & pyspark but they were way slower (like 3-5x) than clickhouse and the code was kind of annoying", "context": "", "use_case": "processing TBs of JSON", "switched_from": "", "story": "650GB of Data (Delta Lake on S3). Polars vs. DuckDB vs. Daft vs. Spark"}]}, {"label": "Specialized alternatives", "summary": "Some teams moved to purpose-built tools, such as VictoriaMetrics for metrics or Parquet plus DuckDB.", "quotes": [{"id": 770142162, "item_id": 48133885, "url": "https://news.ycombinator.com/item?id=48133885", "by": "valyala", "date": "2026-05-14", "stance": "compare", "quote": "We tried using ClickHouse as a database for metrics in 2017, but then decided implementing a specialized database for metrics.", "excerpt": "VictoriaMetrics CTO here. We at VictoriaMetrics took another approach. We tried using ClickHouse as a database for metrics in 2017, but then decided implementing a specialized database for metrics. This database uses ClickHouse architecture ideas for achieving the best performance and the lowest resource usage. The main difference between ClickHouse and VictoriaMetrics is that VictoriaMetrics is optimized solely for ", "context": "VictoriaMetrics CTO", "use_case": "metrics database", "switched_from": "", "story": "Traceway: MIT-licensed observability stack you can self-host in ~90s"}, {"id": 786832689, "item_id": 49177043, "url": "https://news.ycombinator.com/item?id=49177043", "by": "encoderer", "date": "2026-08-04", "stance": "neutral", "quote": "At Cronitor we use ClickHouse, but we're leaving it behind for our next product", "excerpt": "At Cronitor we use ClickHouse, but we're leaving it behind for our next product and building directly on Parquet and DuckDB. We think the future of observability in the AI age is self-hosted directly on NVMe backed by cheap and limitless object storage. I don't want to send customer conversations and agent thoughts to a giant multi-tenant borg SaaS database like Sentry or BetterStack.", "context": "works at Cronitor", "use_case": "observability data", "switched_from": "", "story": "DuckDB \u2013 Data power tools for your laptop, now in Clojure (2023)"}]}, {"label": "Development pace", "summary": "One commenter distrusts the very high commit rate and the AI-generated issues in the repo.", "quotes": [{"id": 794631936, "item_id": 49664496, "url": "https://news.ycombinator.com/item?id=49664496", "by": "anguss", "date": "2026-09-11", "stance": "warn", "quote": "I wouldn't touch it with a 10ft pole considering how quickly they're merging code into main.", "excerpt": "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/clickhouse", "context": "", "use_case": "", "switched_from": "", "story": "I've operated petabyte-scale ClickHouse clusters for 5 years"}]}], "who": [{"by": "f311a", "context": "uses ClickHouse in production", "url": "https://news.ycombinator.com/item?id=49555143", "date": "2026-09-03"}, {"by": "encoderer", "context": "works at Cronitor", "url": "https://news.ycombinator.com/item?id=49177043", "date": "2026-08-04"}, {"by": "robbie-c", "context": "works on PostHog", "url": "https://news.ycombinator.com/item?id=48664957", "date": "2026-06-24"}, {"by": "mial", "context": "data warehouse at a medium sized newspaper", "url": "https://news.ycombinator.com/item?id=48607118", "date": "2026-06-20"}, {"by": "dmix", "context": "uses it in a Rails app", "url": "https://news.ycombinator.com/item?id=48600371", "date": "2026-06-19"}, {"by": "chickensong", "context": "promotes DIY", "url": "https://news.ycombinator.com/item?id=47820231", "date": "2026-04-18"}, {"by": "hasyimibhar", "context": "team of about 6, half non-engineers", "url": "https://news.ycombinator.com/item?id=47718961", "date": "2026-04-10"}, {"by": "vaibhav2614", "context": "Engineering Manager at Nectar Social", "url": "https://news.ycombinator.com/item?id=47223326", "date": "2026-03-02"}], "tags": ["for analytics dashboards", "for log storage", "for event tracking", "alongside Postgres", "for data warehouses"], "use_cases": ["log storage", "analytics queries", "analytical database", "analytics storage", "large analytical queries", "telemetry storage"], "compared": [{"slug": "postgresql", "name": "PostgreSQL", "co": 13, "switched_from": 3, "switched_to": 0}, {"slug": "duckdb", "name": "DuckDB", "co": 5, "switched_from": 0, "switched_to": 1}, {"slug": "loki", "name": "Loki", "co": 3, "switched_from": 1, "switched_to": 0}, {"slug": "datadog", "name": "Datadog", "co": 2, "switched_from": 1, "switched_to": 0}, {"slug": "claude-code", "name": "Claude Code", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "vector", "name": "Vector", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "grafana", "name": "Grafana", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "victoriametrics", "name": "VictoriaMetrics", "co": 1, "switched_from": 0, "switched_to": 1}], "makers": [{"id": 802033760, "item_id": 50127110, "url": "https://news.ycombinator.com/item?id=50127110", "by": "zX41ZdbW", "date": "2026-10-17", "stance": "neutral", "quote": "building ClickHouse with PGO does not give any meaningful improvement", "excerpt": "We are building our compiler and the entire LLVM toolchain with PGO, and it gives a solid 20..30% improvement in build speed*. At the same time, building ClickHouse with PGO does not give any meaningful improvement. * https://github.com/ClickHouse/ClickHouse/pulls?q=is%3Apr+state%3Aclosed+%22Add+a+CI+workflow+to+build+PGO%2BBOLT+optimized+clang+toolchain%22+author%3Aalexey-milovidov", "context": "works on ClickHouse build", "use_case": "database build optimization", "switched_from": "", "story": "PGO or not PGO this is the dilemma. Step 2"}, {"id": 778814224, "item_id": 48675889, "url": "https://news.ycombinator.com/item?id=48675889", "by": "zX41ZdbW", "date": "2026-06-25", "stance": "recommend", "quote": "I host a publicly open database with Hacker News data at", "excerpt": "I host a publicly open database with Hacker News data at https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPTSBoYWNrZXJuZXdzX2hpc3RvcnkgTElNSVQgMTAw So you can create any sort of similar services in a single SQL query and an HTML page. I also hosted it as a publicly accessible data lake, which you can query from everywhere: https://github.com/ClickHouse/ClickHouse/issues/29693#issuecomment-4755761107 It is al", "context": "", "use_case": "public HN data querying", "switched_from": "", "story": "Show HN: I made Google Trends for Hacker News by indexing 18 years of comments"}, {"id": 777648561, "item_id": 48603035, "url": "https://news.ycombinator.com/item?id=48603035", "by": "saisrirampur", "date": "2026-06-19", "stance": "recommend", "quote": "Sai from ClickHouse", "excerpt": "We at PeerDB/CickPipes tried to make that mirroring as frictionless as possible. It is validated at scale across 1000s of customer moving over half a PB of a data per month from Postgres to ClickHouse. You should give it a shot and you might be surprised. Side note: May be there is way even more native than CDC/logical decoding that you never have to worry about keeping PG and CH in sync. Stay tuned for some updates ", "context": "works at ClickHouse", "use_case": "analytics database", "switched_from": "", "story": "Ten years of ClickHouse in open source"}, {"id": 743898624, "item_id": 46493664, "url": "https://news.ycombinator.com/item?id=46493664", "by": "saisrirampur", "date": "2026-01-04", "stance": "recommend", "quote": "another amazing database technology which is equally cooler and useful to the world and for a different use-case (analytics)", "excerpt": "Lovely article! Thanks for writing this one. Really love your motivation for the move from Timescale to ClickHouse - basically wanted to give ClickHouse a try! :) And later found it easy and useful. This is what happened to me too when I spent past decade working for to Postgres companies and later started working for ClickHouse. Realized that there is another amazing database technology which is equally cooler and u", "context": "works for ClickHouse, previously at Postgres companies", "use_case": "analytics", "switched_from": "", "story": "A Small Time Review of ClickHouse"}], "threads": [{"url": "https://news.ycombinator.com/item?id=48546890", "title": "Ten years of ClickHouse in open source", "mentions": 6}, {"url": "https://news.ycombinator.com/item?id=46617744", "title": "I built Vector. Now I'm answering the question your observability vendor won't", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=50205816", "title": "Remove pgrust: the entry is cheating (per-query kernels and result caching)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50166960", "title": "Show HN: Pug \u2013 open-source product analytics", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50090453", "title": "PGO or not PGO this is the dilemma. Step 2", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49601138", "title": "I've operated petabyte-scale ClickHouse clusters for 5 years", "mentions": 1}], "sentiment_by_month": {"2025-11": {"recommend": 2}, "2025-12": {}, "2026-01": {"neutral": 2, "recommend": 1}, "2026-02": {"recommend": 1}, "2026-03": {"neutral": 2}, "2026-04": {"recommend": 2, "neutral": 2}, "2026-05": {"compare": 2}, "2026-06": {"recommend": 7, "neutral": 2}, "2026-07": {"neutral": 3, "recommend": 1}, "2026-08": {"neutral": 2, "compare": 1, "recommend": 2}, "2026-09": {"recommend": 1, "warn": 1}, "2026-10": {"neutral": 1, "compare": 1}}, "quotes": [{"id": 803480673, "item_id": 50217542, "url": "https://news.ycombinator.com/item?id=50217542", "by": "remywang", "date": "2026-10-24", "stance": "compare", "quote": "Turning off dictionary-related optimizations in pgrust immediately made it 5x slower (from 3.8s to 20.4s on my machine), while ClickHouse takes a total of 15.0s.", "excerpt": "So I spent some time poking at the released 0.4-beta code. Controversy aside, it is interesting to see an open source system that beats ClickHouse on ClickBench - 4 out of the 5 systems ahead of CH (Umbra, elosdb, Hyper, CedarDB) are all closed-source, while the only open one is pivotlake. What makes pgrust fast? There's no one single reason, but a combination of techniques like dictionary encoding [1], zone maps [2]", "context": "", "use_case": "analytical database", "switched_from": "", "story": "Remove pgrust: the entry is cheating (per-query kernels and result caching)"}, {"id": 802677569, "item_id": 50167348, "url": "https://news.ycombinator.com/item?id=50167348", "by": "BajajScooter", "date": "2026-10-20", "stance": "neutral", "quote": "built using go, nats, clickhouse, postgres", "excerpt": "built using go, nats, clickhouse, postgres; goal is to make it easy to self host github: https://github.com/pug-sh/pug demo(no sign up needed): https://app.pug.sh/demo", "context": "", "use_case": "analytics storage", "switched_from": "", "story": "Show HN: Pug \u2013 open-source product analytics"}, {"id": 794631936, "item_id": 49664496, "url": "https://news.ycombinator.com/item?id=49664496", "by": "anguss", "date": "2026-09-11", "stance": "warn", "quote": "I wouldn't touch it with a 10ft pole considering how quickly they're merging code into main.", "excerpt": "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/clickhouse", "context": "", "use_case": "", "switched_from": "", "story": "I've operated petabyte-scale ClickHouse clusters for 5 years"}, {"id": 792882288, "item_id": 49555143, "url": "https://news.ycombinator.com/item?id=49555143", "by": "f311a", "date": "2026-09-03", "stance": "recommend", "quote": "we use regular CH in production. I'm pretty familiar with it and I can always run large queries on a production server with 1TB of RAM.", "excerpt": "Because we use regular CH in production. I'm pretty familiar with it and I can always run large queries on a production server with 1TB of RAM. Regular CH also support external data sources, so I can read 500GB of JSON from S3 and group by it on production server very fast and in memory.", "context": "uses ClickHouse in production", "use_case": "large analytical queries", "switched_from": "", "story": "Pre-Release of Polars 2.0"}, {"id": 790361921, "item_id": 49397620, "url": "https://news.ycombinator.com/item?id=49397620", "by": "clintonb", "date": "2026-08-22", "stance": "neutral", "quote": "which exports to ClickHouse (formerly Datadog)", "excerpt": "(I\u2019m not the person you replied to, but have experience here.) I follow the [gateway deployment pattern](https://opentelemetry.io/docs/collector/deploy/gateway/). Everything sends telemetry to our gateway, which exports to ClickHouse (formerly Datadog). We use Node.js, so all we need to do is run a script initializing Otel before running the app. We set this up following the docs a few years ago, and haven\u2019t had to c", "context": "", "use_case": "telemetry storage", "switched_from": "Datadog", "story": "OTel isn\u2019t going well"}, {"id": 789888209, "item_id": 49368013, "url": "https://news.ycombinator.com/item?id=49368013", "by": "nikcub", "date": "2026-08-19", "stance": "recommend", "quote": "clickhouse is resource efficient", "excerpt": "I love OpenRouter, long time user. Stripe will hopefully be a good custodian. I just want to point out some features of OpenRouter that make it more than just a model selection and routing endpoint and that I find incredibly useful: 0/ Default routing is to the cheapest provider, but they're usually not the most performant. I'd guess 99% of OpenRouter integrations never tweak the default routing. Here you can setup c", "context": "", "use_case": "storing LLM traces", "switched_from": "", "story": "OpenRouter Is Joining Stripe"}, {"id": 789836753, "item_id": 49364797, "url": "https://news.ycombinator.com/item?id=49364797", "by": "rgbrgb", "date": "2026-08-19", "stance": "recommend", "quote": "truly amazing software that just works without any tuning for this kind of exploratory analytics workload.", "excerpt": "i love postgresql but once we added ai-generated dashboard to our homegrown analytics tool [0] some of the crazy (amazing) dashboards that the ops team was building began accumulating horrendously slow db queries. I considered dynamically adding indexes or alerting around postgres slow queries but also quickly prototyped mirroring the postgres data in clickhouse. At first could not believe how fast clickhouse was on ", "context": "", "use_case": "analytics queries", "switched_from": "PostgreSQL", "story": "PostgreSQL for Everything"}, {"id": 789340066, "item_id": 49333754, "url": "https://news.ycombinator.com/item?id=49333754", "by": "otter-in-a-suit", "date": "2026-08-17", "stance": "compare", "quote": "have even experimented with Clickhouse as a complete alternative", "excerpt": "Super excited about Quack (partially due to the name). I use duckdb for both analytics and runtime, but I do have to serve/handle/manage a giant, multi-GiB duckdb file as effectively a runtime artifact[1]. I'm aware that this isn't the _perfect_ database for this, but the mix of it being fast, having spatial support, sane coding interfaces, great dbt integration, and me being able to do everything between \"run a gian", "context": "", "use_case": "alternative to DuckDB", "switched_from": "", "story": "A Preview of DuckDB v2.0"}, {"id": 786832689, "item_id": 49177043, "url": "https://news.ycombinator.com/item?id=49177043", "by": "encoderer", "date": "2026-08-04", "stance": "neutral", "quote": "At Cronitor we use ClickHouse, but we're leaving it behind for our next product", "excerpt": "At Cronitor we use ClickHouse, but we're leaving it behind for our next product and building directly on Parquet and DuckDB. We think the future of observability in the AI age is self-hosted directly on NVMe backed by cheap and limitless object storage. I don't want to send customer conversations and agent thoughts to a giant multi-tenant borg SaaS database like Sentry or BetterStack.", "context": "works at Cronitor", "use_case": "observability data", "switched_from": "", "story": "DuckDB \u2013 Data power tools for your laptop, now in Clojure (2023)"}, {"id": 784375139, "item_id": 49023446, "url": "https://news.ycombinator.com/item?id=49023446", "by": "rgbrgb", "date": "2026-07-23", "stance": "neutral", "quote": "It includes a ClickHouse data lake for ingesting data", "excerpt": "hey hn, I wanted to share a side project we\u2019ve been using and iterating at Hedgy for the past couple weeks. It\u2019s our take on a self-hosted company brain that is powered entirely by our claude subscriptions. It includes a ClickHouse data lake for ingesting data and light knowledge infrastructure for storing knowledge about the data (e.g. this is how we count a user as active, check column X when determining LTV). This", "context": "", "use_case": "data lake", "switched_from": "", "story": null}, {"id": 782383345, "item_id": 48898959, "url": "https://news.ycombinator.com/item?id=48898959", "by": "snikes", "date": "2026-07-13", "stance": "neutral", "quote": "We use ClickHouse PG behind it, and haven't had any issues so far", "excerpt": "PgBouncer works great for us with Vercel Workers. We use ClickHouse PG behind it, and haven't had any issues so far :)", "context": "", "use_case": "database behind PgBouncer", "switched_from": "", "story": "We scaled PgBouncer to 4x throughput"}, {"id": 781442833, "item_id": 48840177, "url": "https://news.ycombinator.com/item?id=48840177", "by": "BajajScooter", "date": "2026-07-08", "stance": "recommend", "quote": "that's why we used clickhouse db here which scales to billions of events easily", "excerpt": "Traditional databases(mysql, postgres) are perfect for transactional data. users, products, orders and the like. but they aren't made for tracking events which is typically huge volume. that's why we used clickhouse db here which scales to billions of events easily. We also have sdks that you can use in your app to publish the events to our services. You can also query these events on our app, create trends, funnels,", "context": "", "use_case": "high-volume event storage", "switched_from": "", "story": "Show HN: Pug.sh \u2013 open-source product analytics"}, {"id": 780168944, "item_id": 48760559, "url": "https://news.ycombinator.com/item?id=48760559", "by": "Petefine", "date": "2026-07-02", "stance": "neutral", "quote": "We use Clickhouse and Python or Go.", "excerpt": "Recycleye | Data Scientist | London | 2-3x/week ONSITE | Mid to Senior level Recycleye and CP Group build recycling plants, and are forming a new team to provide data analytics and optimisation to recycling facility operators. There are optical sorters, AI powered airjets, AI robots and many different types of machines in a waste facility. The waste is constantly varying and the plant can be configured in thousands o", "context": "", "use_case": "data analytics", "switched_from": "", "story": "Ask HN: Who is hiring? (July 2026)"}, {"id": 778740018, "item_id": 48671251, "url": "https://news.ycombinator.com/item?id=48671251", "by": "Imustaskforhelp", "date": "2026-06-25", "stance": "recommend", "quote": "something like clickhouse or redis combined with postgresql might be more than enough for many things", "excerpt": "I agree, the reason why I had submitted this HN submission post was because I was getting way too deep into the weeds of new databases like surrealdb/tigerbeetle/scylladb etc. which while are an interesting problem to think through because well, it makes me feel smarter knowing these databases. I still felt like postgresql was enough, (at best something like clickhouse or redis combined with postgresql might be more ", "context": "", "use_case": "analytics alongside PostgreSQL", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 778639312, "item_id": 48664957, "url": "https://news.ycombinator.com/item?id=48664957", "by": "robbie-c", "date": "2026-06-24", "stance": "neutral", "quote": "we used ClickHouse SQL as a starting point as that's what our underlying DB is", "excerpt": "Our SQL is very similar to ClickHouse SQL, in that we used ClickHouse SQL as a starting point as that's what our underlying DB is. We needed to have our own parser so that we could add additional language features on top.", "context": "works on PostHog", "use_case": "underlying analytics database", "switched_from": "", "story": "I rewrote PostHog's SQL parser, 70x faster, while barely looking at the code"}, {"id": 777714784, "item_id": 48607174, "url": "https://news.ycombinator.com/item?id=48607174", "by": "jaysh", "date": "2026-06-20", "stance": "recommend", "quote": "substantially better performance on the same hardware", "excerpt": "Off the top of my head: - substantially better performance on the same hardware, even moreso for larger range queries (multiple days) - no new query language to learn - significantly more expressive as you said - agents for scraping logs use way less CPU (I used to use grafana-agent which used about 80%, vector uses sub 5%) - very intuitive to manage TTLs - I can keep some logs for 10 years, and some for 1 week based", "context": "", "use_case": "log storage and querying", "switched_from": "Loki", "story": "Ten years of ClickHouse in open source"}, {"id": 777713888, "item_id": 48607118, "url": "https://news.ycombinator.com/item?id=48607118", "by": "mial", "date": "2026-06-20", "stance": "recommend", "quote": "we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never looked back. Much more performant, practical, and a lot less maintenance.", "excerpt": "On top of being a really good OLAP database, what has been a game changer for me is the built-in connectors for bringing in data from remote sources. It can manage automatic recurring import of a s3 folder containing parquet/json files and it can also connect directly to Postgres. For our data warehouse at a medium sized newspaper, we switched from Druid+postgres+trino to just one big clickhouse node and I\u2019ve never l", "context": "data warehouse at a medium sized newspaper", "use_case": "data warehouse", "switched_from": "Druid", "story": "Ten years of ClickHouse in open source"}, {"id": 777619024, "item_id": 48601189, "url": "https://news.ycombinator.com/item?id=48601189", "by": "rozenmd", "date": "2026-06-19", "stance": "recommend", "quote": "Since moving to Clickhouse I think I can grab a full year's data in around 200ms", "excerpt": "I used to keep all of OnlineOrNot's timeseries data entirely in a hot postgres db with the rest of the relational data. Used to take a few seconds to get a week's uptime data and do some useful analysis. Since moving to Clickhouse I think I can grab a full year's data in around 200ms (probably less if I try optimising it). Still completely blows my mind everyday.", "context": "", "use_case": "timeseries uptime data analytics", "switched_from": "PostgreSQL", "story": "Ten years of ClickHouse in open source"}, {"id": 777605936, "item_id": 48600371, "url": "https://news.ycombinator.com/item?id=48600371", "by": "dmix", "date": "2026-06-19", "stance": "recommend", "quote": "The web admin panel they built is great and we\u2019ve had solid performance.", "excerpt": "We use Clickhouse in a rails app for our customer facing dashboard analytics, logging, and datalake type stuff where Postgres is too heavy and expensive. The web admin panel they built is great and we\u2019ve had solid performance.", "context": "uses it in a Rails app", "use_case": "dashboard analytics, logging, datalake", "switched_from": "", "story": "Ten years of ClickHouse in open source"}, {"id": 777583328, "item_id": 48598958, "url": "https://news.ycombinator.com/item?id=48598958", "by": "eklavya", "date": "2026-06-19", "stance": "recommend", "quote": "I use clickhouse AND postgres. Clickhouse is not a replacement for postgres at all.", "excerpt": "Not to mention ACID and CAP and all that. I use clickhouse AND postgres. Clickhouse is not a replacement for postgres at all.", "context": "", "use_case": "analytics alongside Postgres", "switched_from": "", "story": "Ten years of ClickHouse in open source"}, {"id": 776631778, "item_id": 48539486, "url": "https://news.ycombinator.com/item?id=48539486", "by": "marvinblum", "date": "2026-06-15", "stance": "neutral", "quote": "ClickHouse queries are generated on the fly", "excerpt": "I'm rewriting the open-source core [0] of our product [1] to add more flexible reports. This is the first time I'm building with the help of AI (Claude), but I don't really let it write code. It has been really helpful in discussing ideas (I'm mostly working alone), like a rubber duck that actually talks back. The code it generates however has many subtle and sometimes obvious mistakes in them, so I decided to write ", "context": "", "use_case": "analytics queries", "switched_from": "", "story": "Ask HN: What are you working on? (June 2026)"}, {"id": 774572144, "item_id": 48410759, "url": "https://news.ycombinator.com/item?id=48410759", "by": "f311a", "date": "2026-06-05", "stance": "recommend", "quote": "ClickHouse also supports a lot of data sources and has a local mode where you just use a single binary with local-only access.", "excerpt": "ClickHouse also supports a lot of data sources and has a local mode where you just use a single binary with local-only access. Coincidentally, I wrote an article today on how I use it for similar scenarios. It can fetch from S3, multiple databases at once, and so on. And you get all the benefits of a database when you need to join or postprocess data from multiple sources. https://rushter.com/blog/clickhouse-data-pro", "context": "", "use_case": "local data processing across sources", "switched_from": "", "story": "databow: a Rust CLI to query any database with an ADBC driver"}, {"id": 773291249, "item_id": 48330703, "url": "https://news.ycombinator.com/item?id=48330703", "by": "jnbh", "date": "2026-05-29", "stance": "compare", "quote": "rather than ClickHouse-class scans over cold history", "excerpt": "VCI looks promising for the \"don't ship your data to ClickHouse just to run aggregates\" case, and an in-memory columnar index covers a real slice of it. Where I'd temper expectations is that a columnar index bolted onto a row-store engine still inherits that engine's execution model and storage, so you usually land at \"good enough for dashboards on recent data\" rather than ClickHouse-class scans over cold history. Th", "context": "", "use_case": "analytical queries", "switched_from": "", "story": "Ask HN: Could Postgres's VCI proposal become a ClickHouse alternative?"}, {"id": 770142162, "item_id": 48133885, "url": "https://news.ycombinator.com/item?id=48133885", "by": "valyala", "date": "2026-05-14", "stance": "compare", "quote": "We tried using ClickHouse as a database for metrics in 2017, but then decided implementing a specialized database for metrics.", "excerpt": "VictoriaMetrics CTO here. We at VictoriaMetrics took another approach. We tried using ClickHouse as a database for metrics in 2017, but then decided implementing a specialized database for metrics. This database uses ClickHouse architecture ideas for achieving the best performance and the lowest resource usage. The main difference between ClickHouse and VictoriaMetrics is that VictoriaMetrics is optimized solely for ", "context": "VictoriaMetrics CTO", "use_case": "metrics database", "switched_from": "", "story": "Traceway: MIT-licensed observability stack you can self-host in ~90s"}, {"id": 765123699, "item_id": 47820231, "url": "https://news.ycombinator.com/item?id=47820231", "by": "chickensong", "date": "2026-04-18", "stance": "recommend", "quote": "maybe some kind of OTel, wide log, ClickHouse, Grafana thing", "excerpt": "Are you asking about other 3rd party solutions, or thinking of DIY? AFAIK, Datadog is still the best/most expensive. Any provider offering AI analysis is just going to add to your cost. > I love putting time into this stuff > like the reason for using Heroku - I have a lot of other stuff I need to focus on You probably need to pick a side here. Building a robust solution with even a fraction of Datadog and Sentry fea", "context": "promotes DIY", "use_case": "DIY observability storage", "switched_from": "", "story": "Observability Stack \u2013 AI First?"}, {"id": 765086610, "item_id": 47817913, "url": "https://news.ycombinator.com/item?id=47817913", "by": "amcaskill", "date": "2026-04-18", "stance": "neutral", "quote": "built around markdown and clickhouse", "excerpt": "I work on a dashboarding / BI solution that is also built around markdown and clickhouse. www.evidence.dev We moved to stripe's Markdoc variant for the component syntax last year and have been really happy with it. Models are good at writing it, people are good at reviewing it. Here's an area chart that would issue a SQL query for weekly revenue totals: ``` {% area_chart data=\"my_table\" x=\"date\" y=\"sum(revenue)\" date", "context": "", "use_case": "BI backend", "switched_from": "", "story": "Show HN: MDV \u2013 a Markdown superset for docs, dashboards, and slides with data"}, {"id": 763503377, "item_id": 47718961, "url": "https://news.ycombinator.com/item?id=47718961", "by": "hasyimibhar", "date": "2026-04-10", "stance": "neutral", "quote": "I built an MCP over our backend and Clickhouse", "excerpt": "We use MCP at work. In my team of about 6 people, everyone has Claude access, but about half of us are non-engineers. I built an MCP over our backend and Clickhouse, and setup a Claude Project with instruction (I'm assuming this count as skill?). The instruction is mostly for enriching the analytics data that we have, e.g. hinting Claude to prefer certain datasets for certain questions. This allows the non-engineers ", "context": "team of about 6, half non-engineers", "use_case": "analytics data", "switched_from": "", "story": "I Still Prefer MCP over Skills"}, {"id": 762555328, "item_id": 47659708, "url": "https://news.ycombinator.com/item?id=47659708", "by": "KaiLetov", "date": "2026-04-06", "stance": "recommend", "quote": "We use ClickHouse for a trend detection pipeline", "excerpt": "We use ClickHouse for a trend detection pipeline and the agentic coding part resonates. Half my codebase was written with Claude Code at this point. The tricky bit is when the agent makes changes that look right but break some subtle assumption three files away. Curious how they handle that at scale with a codebase the size of ClickHouse.", "context": "", "use_case": "trend detection pipeline", "switched_from": "", "story": "Agentic Coding at ClickHouse"}, {"id": 757104705, "item_id": 47319044, "url": "https://news.ycombinator.com/item?id=47319044", "by": "antonio-mello", "date": "2026-03-09", "stance": "neutral", "quote": "I use ClickHouse for production analytics", "excerpt": "The \"early React\" analogy resonates. I've been seeing the same pattern with MCP (Model Context Protocol) \u2014 the primitive is powerful (AI assistants calling tools via a standard protocol), but most implementations are still gluing things together ad-hoc. There's a gap between \"I can build an MCP server\" and \"this is a polished, opinionated product.\" The DuckDB choice is smart for local-first. I use ClickHouse for prod", "context": "", "use_case": "production analytics", "switched_from": "", "story": "Show HN: DenchClaw \u2013 Local CRM on Top of OpenClaw"}, {"id": 755573224, "item_id": 47223326, "url": "https://news.ycombinator.com/item?id=47223326", "by": "vaibhav2614", "date": "2026-03-02", "stance": "neutral", "quote": "Our tech stack is React, Typescript, AWS, Pulumi, Postgres, Clickhouse and Turbopuffer.", "excerpt": "Nectar Social (https://www.nectarsocial.com) | Software Engineer, Product Designer, Product Manager | Palo Alto, CA | Onsite | Full-time Hi HN. I am an Engineering Manager at Nectar Social, and we're hiring across product, design and engineering. The traditional playbook of buying ads on social media platforms no longer works for most brands. Buyers make purchasing decisions from organic conversations on social media", "context": "Engineering Manager at Nectar Social", "use_case": "company tech stack", "switched_from": "", "story": "Ask HN: Who is hiring? (March 2026)"}, {"id": 754835952, "item_id": 47177247, "url": "https://news.ycombinator.com/item?id=47177247", "by": "dirtbag__dad", "date": "2026-02-26", "stance": "recommend", "quote": "before we switched to clickhouse and it was night and day.", "excerpt": "OLAP conveniently not mentioned. Anyone have any suggestions for this? We tried to get as much mileage as we could out of Postgres before we switched to clickhouse and it was night and day.", "context": "", "use_case": "OLAP analytics", "switched_from": "PostgreSQL", "story": "You Just Need Postgres"}, {"id": 746685792, "item_id": 46667862, "url": "https://news.ycombinator.com/item?id=46667862", "by": "zX41ZdbW", "date": "2026-01-18", "stance": "recommend", "quote": "When a single server is not enough, you deploy ClickHouse on a cluster, up to thousands of machines", "excerpt": "When a single server is not enough, you deploy ClickHouse on a cluster, up to thousands of machines, e.g., https://clickhouse.com/blog/how-clickhouse-powers-ahrefs-the-worlds-most-active-web-crawler", "context": "", "use_case": "large-scale data processing", "switched_from": "", "story": "Command-line Tools can be 235x Faster than your Hadoop Cluster (2014)"}, {"id": 746096979, "item_id": 46631061, "url": "https://news.ycombinator.com/item?id=46631061", "by": "physicles", "date": "2026-01-15", "stance": "recommend", "quote": "we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month.", "excerpt": "I can't get over how expensive these observability platforms are. Last I looked (and looked again just now), if we were to take all our structured logs from all services and send them to Datadog with our current retention policy, it would just about double our current IT spend. Instead, we use Grafana + Loki + ClickHouse and it's been mostly maintenance-free for years. Costs under $100/month. What am I missing? What'", "context": "", "use_case": "log storage", "switched_from": "", "story": "I built Vector. Now I'm answering the question your observability vendor won't"}, {"id": 745911905, "item_id": 46619494, "url": "https://news.ycombinator.com/item?id=46619494", "by": "mr-karan", "date": "2026-01-14", "stance": "neutral", "quote": "routing to different ClickHouse tables in one place", "excerpt": "Just want to say thanks for creating Vector. We use it heavily at Zerodha and wrote about our setup here: https://zerodha.tech/blog/logging-at-zerodha/ It replaced both Filebeat and Logstash for us with a single binary that actually has sane resource usage (no more JVM nightmares). VRL turned out to be way more powerful than we could imagine - we do all our log parsing, metadata enrichment, and routing to different C", "context": "", "use_case": "log storage", "switched_from": "", "story": "I built Vector. Now I'm answering the question your observability vendor won't"}, {"id": 743496865, "item_id": 46468554, "url": "https://news.ycombinator.com/item?id=46468554", "by": "caust1c", "date": "2026-01-02", "stance": "neutral", "quote": "Our stack is Go, NextJS (TS), Postgres and ClickHouse.", "excerpt": "RunReveal (https://runreveal.com) | Systems Software Engineer | Austin, SF (US Work Auth required) | Full-time RunReveal is the Security Data Platform that's building tools to help companies detect and respond to threats in their network. We're a team that values speed, quality and curiosity. Our stack is Go, NextJS (TS), Postgres and ClickHouse. We believe that companies should be able to own their security data and", "context": "", "use_case": "petabyte-scale security data storage", "switched_from": "", "story": "Ask HN: Who is hiring? (January 2026)"}, {"id": 734968067, "item_id": 45935504, "url": "https://news.ycombinator.com/item?id=45935504", "by": "didierbreedt", "date": "2025-11-14", "stance": "recommend", "quote": "We use Vector and Clickhouse for logging and works really well.", "excerpt": "I have found Grafana to be a decent product, but Prom needs a better horizontally scalable solution. We use Vector and Clickhouse for logging and works really well.", "context": "", "use_case": "log storage", "switched_from": "", "story": "I can't recommend Grafana anymore"}, {"id": 734822721, "item_id": 45926420, "url": "https://news.ycombinator.com/item?id=45926420", "by": "faizshah", "date": "2025-11-14", "stance": "recommend", "quote": "I found that clickhouse was the fastest", "excerpt": "I had to do something like this for a few TB of json recently. The unique thing about this workload was it was a ton of small 10-20mb files. I found that clickhouse was the fastest, but duckdb was the simplest to work with it usually just works. DuckDB was close enough to the max performance from clickhouse. I tried flink & pyspark but they were way slower (like 3-5x) than clickhouse and the code was kind of annoying", "context": "", "use_case": "processing TBs of JSON", "switched_from": "", "story": "650GB of Data (Delta Lake on S3). Polars vs. DuckDB vs. Daft vs. Spark"}]}