Chartmetric uses ClickHouse Cloud to deliver real-time analytics on billions of rows of music, playlist, and engagement data. They migrated from Postgres and Snowflake to improve speed and reduce storage; queries now run 10-15x faster at much lower cost. Today, ClickHouse powers a 5.5B-row playlist cache that ingests 15M+ new rows daily, plus LLM-facing queries using batched WHERE + IN filters and projections. 

Summary

[Chartmetric](https://chartmetric.com/) tracks the pulse of the music industry. Every day, the platform ingests millions of rows of data from streaming services, social media, and music charts, powering dashboards for A\&R teams, reports for record labels, and insights for artists navigating their next move. 

By 2024, that data footprint had ballooned into the billions and their systems weren’t scaling fast enough to keep up. [This past March](https://clickhouse.com/blog/chartmetric-uses-clickhouse-to-turn-artist-data-into-music-intelligence), lead engineer Peter Gomez shared how the team tackled the challenge by migrating time-series workloads from Postgres and Snowflake to [ClickHouse Cloud](https://clickhouse.com/cloud). The move sped up slow queries and cut RDS storage by 10 TB.

Since then, the team has gone even further. ClickHouse now powers production workloads across the company, from LLM-ready queries to a massive playlist cache pipeline that refreshes every five minutes. What began as a targeted performance fix has evolved into a foundational part of Chartmetric’s real-time data stack.

At a [September 2025 meetup in Toronto](https://clickhouse.com/videos/toronto-meetupSep1), lead data engineer Umang Sharaf shared what that evolution looks like today. He walked through the team’s architecture, new query patterns, and the tradeoffs of scaling a playlist cache that ingests over 15 million new rows a day.

## Chartmetric’s journey to ClickHouse

Today, Chartmetric handles around 300,000 requests per hour—roughly 80 per second—across a web app, external API, and small public API. The platform tracks more than 12 million artists, 140 million tracks, 45 million albums, and nearly 30 million playlists.

“These numbers are growing rapidly,” Umang says. “The number of artists grew by 13% in just a year as new artists join Spotify, Apple Music, Amazon, and other platforms.”

Before 2024, the team relied on a mix of Postgres, Snowflake, Elasticsearch, and Airflow. Postgres handled core application data and business logic, Snowflake supported analytics, Elasticsearch powered search and filtering, and Airflow orchestrated data pipelines. But none of these systems were built for the scale and flexibility Chartmetric needed.

“Storage was costly, with a lot of infrequent and cold-access data,” Umang says, noting their AWS Aurora RDS footprint included 28 TB of historical data. Snowflake, which ran 700+ cache and transform tables daily, was “very expensive and obviously not suitable for our API latency needs.” Elasticsearch, meanwhile, was fast and responsive, but “only for specific use cases—and writing JSON isn’t as easy as writing SQL,” he adds.

Chartmetric’s ClickHouse journey began with a small EC2 instance. “But as we started using it more,” Umang says, “our usage and our infrastructure needs increased.” In summer 2024, they migrated to [ClickHouse Cloud](https://clickhouse.com/cloud). Today, they use multiple warehouses tailored to specific workloads: “one for the application and the API (read-only), one for data science and analytics, and one for data engineering tasks like sync and ETL,” Umang says.

## The importance of projections

Back in March, Peter described how migrating time-series data from Postgres and Snowflake to ClickHouse led to a 10 TB storage reduction and major improvements in query speed. At the Toronto meetup, Umang dove deeper into the challenges and optimizations that followed.

As Umang explains, the issue they faced wasn’t ingest performance. “ClickHouse is very efficient for ingesting new data,” he says. “That part went off without a hitch.”

The real challenge was sync. The tables had been ordered for API access, not for update patterns. In Postgres, B-tree indexes handled it fine. But in ClickHouse, hourly sync jobs began running into timeouts and memory issues.

The solution was [projections](https://clickhouse.com/docs/sql-reference/statements/alter/projection), which Umang describes as “not quite clustering, not quite indexing… they’re essentially mini-tables that are maintained directly by ClickHouse—a good hands-off implementation, so that instead of creating, maintaining, and referencing multiple views from API code, it all just lives within the base table itself.” 

One projection surfaces the most recently modified rows. Another is sorted by ISRC, the music industry’s equivalent of a book’s ISBN. These allow precise queries without full scans. The team often uses multiple projections per table depending on workload. And while Umang notes that projections can complicate deletes, the tradeoff is worth it. “This provided huge flexibility compared to Snowflake’s single clustering key,” he says.

With this approach, migrating just eight time-series tables cut their RDS footprint from 28 TB to 18 TB—a 36% savings. And even queries scanning back to 2016, which frequently timed out after a minute in Postgres and Snowflake, now run in under three seconds.

## Rethinking JOINs with WHERE + IN

As Chartmetric expanded its use of ClickHouse beyond time-series workloads, they began creating [flattened, denormalized tables](https://clickhouse.com/docs/data-modeling/denormalization) to support an LLM-based interface for querying artist and track data. But joining large datasets—track metadata, metrics, playlist history—was easier said than done. “We frequently ran into out-of-memory issues,” Umang says.

Earlier this year, Peter shared a few initial lessons about limiting JOIN complexity: pre-join wherever possible, avoid joining more than one large table per query, and use projections to speed up scans. Still, the team saw room to improve.

The breakthrough came when they shifted to using [WHERE](https://clickhouse.com/docs/sql-reference/statements/select/where) and [IN](https://clickhouse.com/docs/sql-reference/operators/in) filters instead of joins. Rather than joining directly on artist and track tables, they’d first extract a list of relevant track IDs, then use that list to filter the main table. To reduce memory load, they split queries into smaller batches using [LIMIT](https://clickhouse.com/docs/sql-reference/statements/select/limit) and [OFFSET](https://clickhouse.com/docs/sql-reference/statements/select/offset).

The impact was huge. A query pulling track metadata for Taylor Swift’s songs initially scanned 17,000+ granules and attempted to use nearly 30 GB of memory, resulting in an error. After switching to WHERE \+ IN, the same query scanned fewer than 400 granules, ran in 98 milliseconds, and used just 300 MB of memory.

The team took it further by layering batching on top of those filters. For a query pulling all playlist history for Swift’s tracks since 2016, the raw join took 107 seconds and used 5 GB of memory. After batching, each subquery ran in under 0.5 seconds using just 44 MB of memory. 

“It took 50% less time and over 99% less memory,” Umang says. “In some cases, it was slower than a regular join, but these are overnight queries, so it wasn’t an issue. Reducing memory usage was an important goal for us, and this really helped a lot.”

## Perfecting the playlist cache

The playlist cache is one of Chartmetric’s most important and complex tables. It tracks which artists appear across nearly 30,000 playlists, how often, in what position, and across what types (e.g. editorial, algorithmic, branded). It supports filters by artist, track, album, or playlist ID, and stores data going back nearly a decade. Users rely on it to see near real-time changes, especially on Fridays, when platforms like Spotify refresh top playlists.

At the time of Peter’s talk in March, the table held around 2 billion rows, with more than a million rows added daily. The pipeline ran hourly, with deletion markers generated in Snowflake and synced into ClickHouse. To support this, the team used the [VersionedCollapsingMergeTree engine](https://clickhouse.com/docs/engines/table-engines/mergetree-family/versionedcollapsingmergetree), which let them “invalidate” old rows using a row\_active flag and insert updated versions, without relying on [FINAL](https://clickhouse.com/docs/sql-reference/statements/select/from#final-modifier) queries or background deduplication.

Since then, the system has scaled significantly, and the team has continued to refine it. In July, they moved the entire ingestion pipeline over to ClickHouse. “We’re now able to run it every five minutes, which has scaled very well for us,” Umang says. “In fact, we run it every five minutes, but it frequently takes less than two.”

Today, the playlist cache table holds 5.5 billion rows and ingests 15 million new records daily. It includes 31 columns covering everything from playlist type to position history, yet the entire compressed table size is just 340 GB. “Compare that to Postgres,” Umang says, “where the raw data with only seven columns took up half a terabyte.”

Query performance has also seen a major leap. Whereas in Postgres queries often timed out around the 60-second mark, and Snowflake took around 20 seconds for top-artist queries, those same queries now return in about 1.5 seconds in ClickHouse, even with complex filters. “That’s been great for our application and the API,” Umang says.

## Fast, flexible, and stackable

As Umang puts it, “ClickHouse works very well as part of a multi-system data stack.” Postgres remains essential for maintaining consistency and running complex relational queries, and Snowflake continues to support black-box analytics—but ClickHouse has proven to be “excellent for time series data,” at a much lower cost. 

He calls the VersionedCollapsingMergeTree engine a “game changer” and adds, “A speed-up from 20 seconds to 1.5 seconds was very significant.” While they initially struggled with large JOINs, they overcame those challenges using batching and projections. “ClickHouse was very flexible for us,” he says, adding a shoutout to the ClickHouse Cloud support team. 

For Chartmetric, the result is a system that’s fast, scalable, and perfectly suited to real-time analytics, while integrating cleanly alongside other tools in the stack.

Does your team’s data stack need a boost? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.

Get started today

“ClickHouse works very well as part of our multi-system data stack. It’s excellent for time-series data, and the VersionedCollapsingMergeTree engine was a game-changer for us, speeding up queries from 20 seconds in Snowflake to 1.5 seconds in ClickHouse.”

large_Chartmetric User Story Issue 1213.png

medium_Chartmetric User Story Issue 1213.png

small_Chartmetric User Story Issue 1213.png

thumbnail_Chartmetric User Story Issue 1213.png

Chartmetric User Story Issue 1213.png

Behind the music: How Chartmetric is scaling music analytics with ClickHouse

お客様のデータで ClickHouse がどのように機能するか、ご確認になりませんか。ClickHouse Cloud は数分で利用を開始でき、300ドル分の無料クレジットをご提供いたします。

今すぐ始める

「ClickHouse MCPを使用することで、高度に複雑な分析や、データの監視、きめ細かなコントロールが可能になります。」- ソリューションアーキテクト、孫 セイ氏

large_User Story EMQ Issue 1209.png

medium_User Story EMQ Issue 1209.png

small_User Story EMQ Issue 1209.png

thumbnail_User Story EMQ Issue 1209.png

User Story EMQ Issue 1209.png

EMQとClickHouseの連携: 産業用エッジで機能する、AIを活用したリアルタイム分析

When you hear “industrial IoT,” what comes to mind? Probably sensors ticking away in factories, telemetry from smart vehicles, automated alerts from machines on the line. But what often goes unnoticed are the systems that make it all work—the message brokers, data pipelines, and analytics engines powering real-time intelligence behind the scenes.

For over a decade, [EMQ](https://www.emqx.com/en) has been at the forefront of that infrastructure. Its journey began in 2013 with the launch of [EMQX](https://www.emqx.com/en/platform), an open-source MQTT broker designed to connect devices in low-bandwidth, high-concurrency environments. It quickly became the world’s most scalable MQTT platform, trusted across IoT, IIoT, and connected vehicle applications alike.

Since then, EMQ has grown into a global leader, serving more than 1,000 enterprise customers and connecting over 250 million devices. Its technology powers everything from factory equipment and energy grids to autonomous vehicles and robotic systems, with customers including Geely, HPE, VMware, Verifone, SAIC Volkswagen, Lucid, and Ericsson.

As EMQ’s scale and reach have grown, so have the demands on its platform. Customers aren’t just routing messages between devices; they need to understand what those messages mean. They want real-time insights, flexible analysis, and the ability to act on data the moment it arrives. That shift, from connectivity to intelligence, called for something new.

Earlier this year, solution architect Cheng Sun joined us at a pair of ClickHouse meetups in Tokyo—in [April](https://clickhouse.com/videos/tokyo-meetup-EMQ-15apr25) and again in [June](https://clickhouse.com/videos/tokyo-meetup-emq-29jul25)—to share [how EMQ integrates with ClickHouse](https://clickhouse.com/docs/integrations/emqx) to deliver fast, flexible, end-to-end visibility from the edge to the cloud. From the messaging backbone to the AI-powered observability layer, he showed what it looks like when messaging and analytics are no longer separate systems, but part of the same real-time platform.

## Making MQTT work at scale

EMQ’s flagship product is an MQTT broker called [EMQX](https://www.emqx.com/en). “Whereas Kafka focuses more on data transaction capabilities, our focus is on parallelism and latency,” Cheng explains. “Our challenge is to deliver data from the edge to cloud services with minimal latency.”

[MQTT](https://en.wikipedia.org/wiki/MQTT) is a lightweight protocol originally created at IBM in 1999 and made publicly available in 2010. Unlike HTTP, which uses point-to-point communication, MQTT introduces a broker between publishers and subscribers. “The broker’s role is to route messages correctly, as well as manage the state of each message and connection,” Cheng says.

Developers can also fine-tune message delivery through MQTT’s Quality of Service settings. “You can use level 0 for lightweight, less important data—sending it just once and that’s it,” Cheng explains. “For critical data, you can use level 1 to ensure delivery at least once. And depending on the requirements, you can use level 2 to make sure data is sent exactly once.” 

That flexibility, combined with its ability to support high-concurrency environments, is a big reason MQTT has become the protocol of choice for IoT and industrial workloads. 

But running a large-scale MQTT cluster comes with challenges, particularly around state management. Every connection carries metadata: message headers, footers, connection status between publishers and subscribers. “There’s a lot of data that needs to be monitored,” Cheng says. “That’s why synchronizing data between servers in a cluster is a complex challenge.”

EMQX solves this with a cloud architecture that includes two node types: core nodes that manage session state, and replica nodes that scale out processing. “This allows you to build a cloud environment that can scale infinitely,” Cheng says.

In 2024, the team deployed a cluster capable of handling 100 million concurrent connections. “We achieved extremely high throughput on this cloud, reaching 2 million messages per second,” Cheng says. “At that time, we were running up to 23 nodes. More recently, we’ve been able to build a large-scale IoT cloud with up to 75 nodes.”

## Real-time analytics with ClickHouse

To turn raw device data into real-time insights, EMQ needed a setup that could support high ingestion rates, low-latency queries, and broad compatibility with both industrial protocols and modern analytics tools. For that, they turned to [ClickHouse Cloud](https://clickhouse.com/cloud).

![User Story EMQ Issue 1209 (2).png](/uploads/User_Story_EMQ_Issue_1209_2_8bbcc13f2d.png)

EMQ’s ClickHouse-based analytics setup connects edge devices to cloud dashboards.

ClickHouse sits at the heart of EMQ’s analytics stack, powering everything from ingestion to visualization. It pulls in data from a variety of sources, including relational databases like Postgres and MySQL, streaming systems like Kafka, and industrial brokers like EMQX.

In a typical data flow, industrial devices send telemetry through southbound protocols to [NeuronEX](https://www.emqx.com/en/products/neuronex), EMQ’s edge gateway for data normalization. From there, the data travels via MQTT to EMQX, then through Kafka and finally into ClickHouse Cloud. “With this kind of architecture, you can connect data from the edge all the way to the database,” Cheng says, noting that the setup delivers sub-second analytics, even across public networks.

![User Story EMQ Issue 1209 (1).png](/uploads/User_Story_EMQ_Issue_1209_1_d6d2b3001b.png)

End-to-end data pipeline from edge devices to ClickHouse-powered analytics.

Once inside ClickHouse, the data is immediately available for fast querying. Features like [dictionaries](https://clickhouse.com/docs/sql-reference/dictionaries), [projections](https://clickhouse.com/docs/sql-reference/statements/alter/projection), and [materialized views](https://clickhouse.com/docs/materialized-views) accelerate access and reduce resource usage. Engineers can explore the data using tools like Grafana, Power BI, or Tableau, or work with it directly in Python, Java, Rust, or Go. ClickHouse also integrates with external data lakes like [S3](https://clickhouse.com/docs/integrations/s3) and [Delta Lake](https://clickhouse.com/docs/integrations/deltalake), making it easy to combine real-time streams with historical data.

At the April meetup, Cheng shared a live demo using simulated factory data generated in Python. OPC-UA devices produced sensor readings like temperature and humidity, while Modbus devices sent things like production counts and error codes. The data was normalized using NeuronEX, then streamed via MQTT to EMQX. From there, EMQX’s sink feature routed it into ClickHouse using SQL-configured pipelines.

Once ingested, the data was immediately ready for querying and visualization. Cheng highlighted ClickHouse’s [AI-assisted query builder](https://clickhouse.com/docs/use-cases/AI/ai-powered-sql-generation), which translates natural-language prompts into SQL. “I find the AI features offered by ClickHouse to be very user-friendly,” he says. “The AI can analyze in a single sentence and instantly generate a SQL statement, allowing you to check the data in real time.” 

He also showed off ClickHouse Cloud’s built-in [dashboards](https://clickhouse.com/docs/cloud/manage/dashboards), setting the refresh interval to 10 seconds to display the latest data. “You can instantly see production numbers, defect counts, and more—all in real time,” he says.

## AI at the edge with ClickHouse MCP

<iframe width="768" height="432" src="https://www.youtube.com/embed/eY_kVWsOlOk?si=DVPWbPG224PuK88s" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

At the July meetup, Cheng shared how EMQ has continued to expand its use of ClickHouse’s AI features to build real-time, AI-powered analytics tools for industrial IoT environments. To do that, they first needed to tackle three core challenges facing manufacturing clients.

The first is the complexity of managing diverse edge devices. “With so many different types of equipment and production sites,” Cheng says, “management becomes complicated.”

The second is tracking message latency. “We can’t track the delay of each individual message,” he explains. “We can only monitor average delays or delays for some messages.”

And the third is juggling multiple databases on the northbound (AKA cloud-facing) side of the architecture). “We need a time-series database for each message, a relational database to store detailed equipment information, and a vector database to record internal knowledge.”

The team’s goal, as Cheng puts it, was to “use ClickHouse as a unified data platform and combine the functions of all three databases into one.”

That’s where they turned to the [ClickHouse MCP server](https://clickhouse.com/blog/integrating-clickhouse-mcp). MCP (Model Context Protocol) is a new open protocol designed to let AI agents interact with third-party systems (e.g. databases, APIs, tools) via natural language. Each system is wrapped in an MCP server, enabling developers to trace, debug, query, and analyze events with AI-enhanced workflows. In EMQ’s case, that means giving operators the ability to ask questions like, “Why did the machine fail?” or “Where is the delay happening?” and get answers based on live data from ClickHouse.

During the demo, Cheng showed how MCP enables real-time observability, advanced analytics, and AI-powered troubleshooting. Using trace IDs and vector search, operators can instantly pinpoint the source of a machine error, retrieve the associated error code, and look up relevant solutions, all within the same system. “By using MCP, you can perform highly complex analytics, monitor data, and exercise fine-grained control,” Cheng says. “With this, you can detect changes in latency and errors in real time.”

He also demonstrated new developer tools that simulate sensor data, generate schema recommendations, and automatically configure EMQX rule engines using LLMs. “I’m not very good at SQL,” Cheng admits, “so having features like this is really helpful.” 

The system can stream and process data at scale, with even lightweight edge hardware feeding into cloud dashboards for cross-cluster visibility. And to support more constrained environments, the team is looking at ways to integrate MCP with MQTT. “Since it’s difficult to install MCP on various lightweight devices, we’re exploring new approaches,” Cheng says. “By installing the MCP server proxy on the broker, you can add AI capabilities to even traditional, standard devices. All devices can be enhanced with AI features.”

## Powering the factories of the future

EMQ’s integration of ClickHouse—from real-time pipelines to AI-powered observability with ClickHouse MCP—shows just how far industrial IoT infrastructure has come. Instead of stitching together separate systems for messaging, storage, and analytics, companies can now build a unified stack that’s fast, flexible, and AI-ready from day one.

By making it easier to query, monitor, and act on data, EMQ is helping customers run smarter, more responsive operations. And with seamless integration between EMQX and ClickHouse, plus AI features like MCP, ClickHouse is quickly becoming the platform of choice for the intelligent, data-driven factories of the future.

Learn more about [how EMQX integrates with ClickHouse](https://clickhouse.com/docs/integrations/emqx), and try both [EMQX Cloud](https://www.emqx.com/en/try) and [ClickHouse Cloud](https://clickhouse.com/cloud) for free.


Interested in seeing how ClickHouse works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.

“By using ClickHouse MCP, you can perform highly complex analytics, monitor data, and exercise fine-grained control.” - Cheng Sun, Solution Architect

EMQ and ClickHouse: Real-time, AI-assisted analytics at the industrial edge

We're excited to announce that ClickHouse has achieved the[ AWS Financial Services Competency](https://aws.amazon.com/financial-services/partner-solutions/), recognizing our track record of supporting global financial institutions in turning data into decisions and insights at speed and scale. This milestone reflects our deep and continued investment in the financial services ecosystem.


### Meeting the unique demands of financial data

Financial services organizations face many challenging data requirements, including real-time market data streaming at millions of events per second, complex fraud detection across billions of transactions, regulatory compliance monitoring that demands instant query response, customer analytics that must operate at massive scale while maintaining sub-second latency, to name just a few. 

ClickHouse is designed for this scale. With columnar storage delivering high compression and fast scans, a parallel execution engine that handles massive concurrency, and robust support for time-series operations and window functions make complex financial analysis practical and intuitive.

[Capital One](https://clickhouse.com/videos/open-house-nyc-capital-one) chose ClickHouse for its speed, scalability, and cost efficiency. As a result, they reduced their dashboard load times from 5-6 seconds to under half a second, achieving an 80% improvement in response times, while also cutting infrastructure costs by 50%. As Salim Sayed and Syd Mehmood at Capital One explain: "At Capital One, we want to give teams the data they need, when they need it, to make informed FinOps decisions. With ClickHouse, we can: spot trends early … foster shared accountability … and plan smarter."

Across the financial services ecosystem, organizations are leveraging ClickHouse for mission-critical workloads. Enterprises like [Deutsche Bank ](https://clickhouse.com/videos/big-sensitive-data-warehouse-deutsche-bank-clickhouse)rely on ClickHouse for enterprise-scale analytics of financial services data, while [RBC](https://rbcborealis.com/news/clickhouse-adoption-at-rbc-borealis/) leverages ClickHouse to power AI and machine learning workloads. Fintech innovators like [Longbridge](https://clickhouse.com/blog/longbridge-technology-simplifies-their-architecture-and-achieves-10x-performance-boost-with-clickhouse) use ClickHouse to power real-time market data analytics for traders and quant teams. In the payments space, [Juspay](https://clickhouse.com/blog/juspay-analyzes-payment-transactions-in-real-time-with-clickhouse) and [ProcessOut](https://clickhouse.com/blog/processout-switched-from-elasticsearch-to-clickhouse-cloud) leverage ClickHouse to analyze billions of transactions with high concurrency, enabling better fraud detection and improved operational efficiency.

The cryptocurrency and Web3 sector have also embraced ClickHouse. [Merkle Science](https://clickhouse.com/blog/merkle-science-fights-crypto-crime-at-scale), [Coinhall](https://clickhouse.com/blog/trade-secrets-how-coinhall-uses-clickhouse-to-power-its-blockchain-data-platform), and [Rockset](https://clickhouse.com/blog/rockset-migration-to-clickhouse-lens) use ClickHouse to monitor trading activity, detect anomalies, and deliver real-time insights. Meanwhile, [Seon](https://clickhouse.com/blog/seon-clickhouse-aws) depends on ClickHouse for their fraud prevention and anti-money laundering platform.

Consumer fintech companies such as [Superwall](https://clickhouse.com/blog/superwall-warpstream-clickhouse-cloud-monetization) and [QuickCheck](https://clickhouse.com/blog/how-quickcheck-uses-clickhouse-to-bring-banking-to-the-unbanked) use ClickHouse to track customer transactions, interactions, and behavioral patterns, enabling personalized offerings and deeper customer insights at scale.


### Looking ahead

This AWS Financial Services Competency reflects our ongoing dedication to the financial services ecosystem. We continue to innovate and expand our capabilities to help organizations in this space turn their data into a competitive advantage, delivering the performance they need to power real-time market analytics, fraud detection, regulatory compliance, and customer-facing applications.

ClickHouse has achieved AWS Financial Services Competency, joining a select group of AWS Partners recognized for deep expertise in serving financial services organizations.

large_523152040-51134bb9-5453-438c-8b0b-55adbcd1b131.png

medium_523152040-51134bb9-5453-438c-8b0b-55adbcd1b131.png

small_523152040-51134bb9-5453-438c-8b0b-55adbcd1b131.png

thumbnail_523152040-51134bb9-5453-438c-8b0b-55adbcd1b131.png

523152040-51134bb9-5453-438c-8b0b-55adbcd1b131.png

ClickHouse achieves AWS Financial Services Competency

ClickHouse 25.11 is here! In this post, you will learn about parallel merge for small GROUP BY, projections as secondary indices, and more!

large_Release Blog Cover (30).png

medium_Release Blog Cover (30).png

small_Release Blog Cover (30).png

thumbnail_Release Blog Cover (30).png

Release Blog Cover (30).png

ClickHouse Release 25.11

Pump built their cloud cost visibility platform on ClickHouse Cloud to ingest and analyze 5 billion billing records daily, solving challenges that would have been impossible with Postgres.

The ClickHouse Team

Blog posts by The ClickHouse Team

Behind the music: How Chartmetric is scaling music analytics with ClickHouse

EMQとClickHouseの連携: 産業用エッジで機能する、AIを活用したリアルタイム分析

EMQ and ClickHouse: Real-time, AI-assisted analytics at the industrial edge

ClickHouse achieves AWS Financial Services Competency

ClickHouse Release 25.11

How Pump uses ClickHouse Cloud to bring cloud costs into focus