LaunchDarkly uses ClickHouse Cloud to power analytics, experimentation, and observability from raw feature evaluation events in real time. By replacing streaming pipelines and batch warehouses with ClickHouse Cloud, LaunchDarkly reduced data latency to seconds and sped up feature delivery. ClickHouse handles high-cardinality data at scale, enabling per-user analytics, unified signals, faster feature development and new product capabilities that previous systems couldn't support.


Summary

[LaunchDarkly](https://launchdarkly.com/) believes software releases should be boring. After too many chaotic launches and stressful nights, its co-founders decided there had to be a better way. Today, LaunchDarkly helps teams take control of releases and understand how users experience their products, so shipping software becomes safer, predictable, and drama-free.

But as the platform expanded from feature flag management into experimentation, product analytics, and observability, the team ran into a familiar challenge. The more insight they wanted to give customers about how their software behaved, the more pressure landed on their own data systems. “Latencies ranged from seconds to minutes, and querying raw data directly never worked well,” says Matt Wagner. “We wanted something that combined cheap storage of raw events with fast, low-latency queries. That’s what led us to ClickHouse.”

Matt and Joe Karayusuf, software engineers on LaunchDarkly’s data platform team, have been central to that transition. Matt has spent six years at the company, much of that time working on data infrastructure. Joe joined a few years later, focusing on ingesting large volumes of data efficiently and helping other teams derive meaning from raw events. Together, they’ve helped reshape LaunchDarkly’s data architecture from a collection of brittle streaming and ETL pipelines into a scalable foundation powered by [ClickHouse Cloud](https://clickhouse.com/cloud).

“We’re already seeing the impact inside the company,” Matt says. “The themes are consistent: faster iteration, simplified architecture, and the ability to build entirely new product capabilities that weren’t feasible under our old systems.”

## The limits of streams and warehouses

For years, LaunchDarkly built data features on top of streaming systems. Events flowed into Kinesis, then through Lambda or Flink pipelines that performed in-memory aggregations writing the results directly to Postgres or Redis. “This delivered low latency,” Matt says, “but it was expensive and required constant effort to build and maintain new pipelines for every feature.”

Cost was only part of the problem. Once data passed through the stream, it was effectively gone. Engineers couldn’t easily inspect historical events when something went wrong, which made debugging harder. More importantly, the streaming model forced teams to decide up front which aggregations would matter, leaving little room to explore new questions later.

That limitation was especially clear in experimentation. LaunchDarkly’s [CUPED-based features](https://launchdarkly.com/docs/guides/statistical-methodology/cuped) rely on analyzing user behavior *before* an experiment begins to improve accuracy. In a streaming-first setup, that kind of retrospective analysis was hard to support.

To reduce costs and simplify development, LaunchDarkly later built a batch ETL warehouse. It stored Parquet files in S3, used Airflow to orchestrate pipelines, and relied on Athena for querying and lifecycle management. This was cheaper and easier to extend, but it introduced new friction. Latency stretched into minutes, and querying raw data directly for product experiences rarely worked well. In practice, nearly every UI feature still needed a bespoke ETL job and a derived table, often in Postgres, just to stay responsive.

## From experiment to inflection point

Tired of the constant tradeoffs between speed, cost efficiency, and flexibility, the data platform team went looking for an alternative. ClickHouse had been coming up more often internally and in conversations with peers at other companies, so the team decided to take a closer look.

They started with a small set of relatively simple use cases, including a time-series chart showing counts of flag evaluations. “We needed low latency and a stable pipeline, something that was difficult to achieve with Airflow,” Joe says. “ClickHouse delivered the freshness and reliability we were looking for.”

It didn’t take long for ClickHouse’s impact to ripple beyond the data platform team. In the past, building data features meant defining aggregations upfront, scheduling pipelines, running migrations, and maintaining purpose-built derived tables. With ClickHouse, teams could query raw data directly and iterate much faster. Performance tuning still required involvement from Matt, Joe, and others, but the baseline experience was far simpler.

“The biggest shift was that ClickHouse reduced the operational and engineering overhead needed to ship new data features,” Joe says. What started as a “small experiment” turned into half a dozen teams adopting it within four months. “This dramatic drop in friction enabled us to ship features that would have previously taken months to develop.”

## How ClickHouse runs at LaunchDarkly

Today, LaunchDarkly runs ClickHouse as a fully hosted service using [ClickHouse Cloud](https://clickhouse.com/cloud). The decision to go with the managed service was “driven more by operational simplicity than by specific product features,” Matt says. “Spinning up clusters is easy, and the way ClickHouse scales in the cloud has been excellent for us.”

Raw events are sent directly into ClickHouse as they happen, and queries from the application layer are served straight from ClickHouse clusters. There’s no external pre-aggregation pipeline to keep in sync just to power product features. [Materialized views](https://clickhouse.com/docs/materialized-views) are used where they make sense, but they live inside ClickHouse rather than a separate ETL system. The basic idea is simple: store raw events, query them directly, and introduce derived tables only when needed.

Ingestion follows a similar philosophy. Events arrive through an HTTP API, which batches them locally and writes them into S3 using an internal [protobuf](https://clickhouse.com/docs/interfaces/formats/Protobuf)\-based format. A [Lambda function](https://clickhouse.com/docs/use-cases/observability/clickstack/sdks/aws_lambda) converts each batch into standardized Parquet files, and ClickHouse is explicitly instructed to load that data into its own storage using [INSERT INTO SELECT](https://clickhouse.com/docs/sql-reference/statements/insert-into). Rather than querying S3 at runtime, ClickHouse pulls the data in and owns it. The ability to [import common file formats directly into ClickHouse](https://clickhouse.com/docs/integrations/data-formats) makes it easy to evolve ingestion over time without reworking everything upstream.

The platform ingests roughly six petabytes per month of uncompressed JSON events, covering feature evaluations, context metadata, and observability signals from production systems around the world. Once the data lands in ClickHouse, it compresses down to hundreds of terabytes while staying fully queryable. New data is typically available to product features in around 30 seconds, compared to several minutes in the previous warehouse, and retention has grown to roughly 100 days, a big step up from what was possible before.

ClickHouse Cloud’s [separation of compute and storage](https://clickhouse.com/docs/guides/separation-storage-compute) has also shaped how the team runs the system. As Matt puts it, “We can double cluster size or add nodes in minutes with no need to reshuffle data, which stands in stark contrast to systems like Elasticsearch that must rebalance shards before changes take effect.” Separating ingest and query workloads gives the team “cleaner scaling and more predictable performance,” since ingest is more CPU-bound while queries are more memory- and cache-heavy.

LaunchDarkly runs one ClickHouse architecture per region—US, EU, and FedRAMP—with all customers in a region sharing the same services. Multi-tenancy is handled at the row level through access controls rather than physical separation. At the company’s current scale, this model has worked well, with the flexibility to revisit it as needs evolve.

## Unlocking new features and capabilities

ClickHouse has changed the way LaunchDarkly builds, both in terms of the individual features the team can deliver and how it thinks about data as a product foundation.

One of the early breakthroughs, Joe says, was seeing “how well ClickHouse handles high-cardinality data.” Earlier systems forced the team to limit dimensionality. Pushing large volumes of distinct values into relational databases wasn’t practical, so features had to be simplified or avoided entirely. With ClickHouse, that constraint disappeared. “We could suddenly support far more dimensions and much finer granularity without performance issues.”

That shift unlocked “features we simply couldn’t have built before,” including richer filtering, arbitrary dimensions for evaluations, autocomplete powered by distinct attribute discovery, and LaunchDarkly’s new audience feature, which identifies who saw which flag and when at a per-user level. “That level of detail was out of reach in other databases,” Joe adds.

Today, LaunchDarkly has seven features running in production on ClickHouse, including its entire Observability offering and major parts of its Product Analytics capabilities. Several more are in active development or prototyping, and ClickHouse now underpins a significant portion of LaunchDarkly’s analytics and data-driven product functionality. “At this point, nearly any analytics component in the UI that involves time-series or evaluating behavior over time is backed by ClickHouse,” Joe says.

Importantly, all of those datasets now live together. By storing feature flag evaluations, product analytics, and observability signals in the same system, LaunchDarkly can correlate them directly, paving the way for workflows like regression detection and automatic rollbacks. “This aligns strongly with the broader vision of putting product analytics, observability, and warehouse-style data in one place so teams can reason across them,” Joe says.

## Learnings (or unlearnings) along the way

One of the team’s biggest lessons has been the importance of getting schema design right early. In their first months with ClickHouse, they made decisions based on assumptions that later proved incorrect. “For example, we tried to coarsen our ORDER BY keys because we thought high granularity would hurt performance,” Matt says. “Later, we learned that ClickHouse is perfectly happy ordering by full timestamps.” By the time that became clear, adoption had grown quickly enough that changing schemas was no longer trivial.

Another learning involved retraining old mental models. “Almost everyone on our team comes from relational OLTP database backgrounds,” Matt says. “ClickHouse is not an OLTP system, and many ingrained habits lead to bad performance.” Queries that worked fine in Postgres could fall apart in ClickHouse because access patterns, joins, and sorting behave differently.

One common example was fetching the “latest N events” by ordering entire rows. LaunchDarkly addressed this with a two-stage query pattern: first selecting lightweight identifiers and ordering those, then fetching the full rows in a second query. Newer versions of ClickHouse address this pattern through [late materialization](https://clickhouse.com/videos/late-materialization-secondary-indices), but the lesson remains.

Beyond technical adjustments, the data platform team has also had to adapt organizationally, as ClickHouse adoption has grown faster than the team itself. “We now have more teams using it than there are engineers supporting it,” Matt says. That has led to teams sometimes solving similar problems in different ways, and to the risk that one team’s query or schema choice could impact others. “We expect to break things along the way and will need to isolate workloads or overprovision temporarily,” he adds. “These are growing pains, but expected ones.”

## What’s next for LaunchDarkly and ClickHouse

One of LaunchDarkly’s most ambitious new initiatives is [Release Guardian](https://launchdarkly.com/blog/meet-release-guardian/), which pushes ClickHouse into a more unusual role. The goal isn’t just to observe what happens after a release, but to react to it automatically.

To do that, Release Guardian needs to connect feature flag evaluations with downstream signals like errors, latency, and other performance metrics, then detect regressions and trigger responses in near real time. “Historically, we ran this logic in a large Flink application,” Joe says. “But maintaining state in Flink, dealing with serialization, and evolving the pipeline were all painful.”

Now, LaunchDarkly is moving that flow directly into ClickHouse. As events arrive, the system joins feature evaluations with observability metrics and stores the enriched results back in ClickHouse. While performing joins at ingest time isn’t a typical ClickHouse pattern, the tradeoff is intentional. The result is a complete, annotated event history that teams can inspect, question, and recompute analytics over long after the fact. As Joe says, “It produces not only the outcome but also the ‘why,’ which is increasingly important for customers.”

This work also continues LaunchDarkly’s broader consolidation effort. Remaining Elasticsearch-backed workloads, particularly around context metadata and search-heavy experiences, are being migrated into ClickHouse using features like the new [JSON data type](https://clickhouse.com/docs/sql-reference/data-types/newjson), [bloom filters](https://clickhouse.com/docs/optimize/skipping-indexes#bloom-filter-types), and other [indexing techniques](https://clickhouse.com/docs/guides/best-practices/sparse-primary-indexes). “Our expectation is that with some tuning, we will be able to migrate the entire workload from Elasticsearch,” Joe says.

Taken together, these efforts move ClickHouse from being an analytics engine to something closer to a control plane for releases, closing the loop between shipping code, measuring impact, and acting on it automatically.

## Balancing cost, freshness, and speed

As Matt and Joe point out, it’s hard to draw a clear before-and-after comparison of ClickHouse’s impact, since “the biggest benefit hasn’t been improving an existing workload, but enabling whole classes of features we couldn’t build before.” That expansion also makes cost savings difficult to isolate. “The moment we adopted ClickHouse,” Matt says, “teams started proposing new data features far more advanced than we were delivering before.”

They did, however, share a graph that illustrates how ClickHouse balances cost, data freshness, and time to build compared to LaunchDarkly’s streaming pipelines and batch warehouse:

![image1.png](/uploads/image1_ab0f3b53c9.png)

“Our previous streaming architecture was expensive and slow to iterate on, while the batch warehouse was cheaper but had high latency and required extensive ETL work for every new feature,” Matt explains. “With ClickHouse, we can serve fresh data, query raw events directly, lean on materialized views when needed, and build new capabilities in weeks instead of months or quarters.”

Just as important, ClickHouse has unified how LaunchDarkly thinks about data across the organization. By bringing analytics, experimentation, and observability into a single system, the team has reduced architectural complexity while increasing velocity. Engineers can reason across signals, iterate faster, and ship features with more confidence—without rebuilding pipelines every time the product evolves.

Matt sums it up simply: “With ClickHouse, I’ve never seen a technology get adopted for so many big things so quickly, and I’m looking forward to where we’ll be in another year.”

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

Get started today

“With ClickHouse, we can serve fresh data, query raw events directly, lean on materialized views when needed, and build new capabilities in weeks instead of months or quarters.”  Joe Karayusuf, Software Engineer at LaunchDarkly

large_LaunchDarkly Issue 1228.jpg

medium_LaunchDarkly Issue 1228.jpg

small_LaunchDarkly Issue 1228.jpg

thumbnail_LaunchDarkly Issue 1228.jpg

LaunchDarkly Issue 1228.jpg

How ClickHouse Cloud enabled LaunchDarkly to build and ship features faster

Polymarket is a prediction market platform where users can trade on the outcomes of real-world events. As the platform grew, their data needs expanded. We talked to Max "Primo" Mershon, a Senior Data Engineer at Polymarket, about how they built their real-time data warehouse for faster internal insights, and migrated computationally expensive analytical workloads from PostgreSQL to ClickHouse to power real-time, user-facing features that scale with rapid growth.

## Postgres isn’t built to do everything

Like many fast-growing startups, Polymarket started simple. They used PostgreSQL for everything: 

* The trading system used Postgres for core transactional data.  
* Internal dashboards queried the production Postgres directly to power charts and analysis.  
* User facing APIs for stats and other aggregate views also ran against Postgres.

For a while, this worked fine. But as data volumes grew, it became clear Postgres was being asked to do a job it wasn’t built for.

The Polymarket team used Hex dashboards for internal analytics, running queries directly against Postgres. As the database was populated with more trading data, these analytical queries started timing out or taking too long.

> "I knew that ClickHouse was fast and that we could run these aggregates in milliseconds, whereas it would literally time out with Postgres." - Max "Primo" Mershon, Senior Data Engineer at Polymarket

The impact extended to user-facing features in the Polymarket app. The [Polymarket Leaderboard](https://polymarket.com/leaderboard) lets anyone see how traders compare to each other, showing their transaction volume and profit/loss. These aggregate stats were computed on a schedule inside Postgres.

Serving the pre-calculated aggregates from Postgres wasn’t the problem; calculating the Leaderboard was computationally expensive and consumed significant resources on the Postgres cluster. This resource contention threatened the stability of other workloads, including critical transactional flows. As resources were already strained, adding more features and granularity (e.g., categorical leaderboards, like Sports, Politics) wasn’t possible, as it would just make the problem worse.

Polymarket wanted to solve two challenges:

1. Make internal analytical workloads faster and work with larger data  
2. Support more granular user-facing analytical features without impacting transactional workloads

## Designing the solution

The goal was not to replace Postgres, but to complement it with a system that is designed to handle the analytical workloads. The end state would be Postgres + (something), working together.

The team had clear requirements:

* Handle growing on chain and off chain data with room to scale.  
* Run heavy aggregate queries with low latency.  
* Keep the operational surface area small enough for a lean team.  
* Get to value quickly, Polymarket moves fast.

Polymarket evaluated ClickHouse and several other data platforms that the team were familiar with from previous roles. They realized they could get up and running quickly on ClickHouse and it would meet their scale and performance requirements.

ClickHouse offered a distinct advantage in time to value. Max had previous experience with ClickHouse and knew it could handle their scale and performance requirements. ClickHouse was also no stranger in the crypto space: Goldsky, a partner they use for blockchain data, [uses ClickHouse](https://clickhouse.com/blog/clickhouse-redpanda-architecture-with-goldsky) and [offers native integrations for its data streams](https://docs.goldsky.com/mirror/sinks/clickhouse).

> "I had experience with several data platforms, and we looked at them. We landed on ClickHouse because we could get started really quickly. It was fast, it was affordable." - Max "Primo" Mershon, Senior Data Engineer at Polymarket

## Building the data warehouse

Polymarket uses Hex for dashboarding and data exploration. When these dashboards ran on Postgres, deep analysis was difficult because queries would often run slowly or time out.

Polymarket successfully implemented a brand new data warehouse on ClickHouse in just a few weeks: integrating data sources, moving queries and updating dashboards.

> "In the span of a couple months we’ve established ClickHouse as our data warehouse, and integrated it into a production API." - Max "Primo" Mershon, Senior Data Engineer at Polymarket

The warehouse pulls in three main classes of data.

**On chain trading data**  
Polymarket relies on Goldsky to index blockchain data. Goldsky provides a ClickHouse sink, so trades and other on-chain events can be streamed straight into ClickHouse tables. That gives Polymarket high volume, append heavy datasets in the format ClickHouse handles best.

**Web and product analytics**  
Frontend and product analytics data lands in S3 as files. Rather than building a custom loader, Polymarket uses ClickPipes to sync those files into ClickHouse. That keeps ingestion simple while still making all of the clickstream data available for analysis.

**Off chain metadata**  
User profiles, market metadata, and other off-chain data still flows through Postgres. They sync this data into ClickHouse on a schedule using [ClickHouse's native PostgreSQL Table Engine](https://clickhouse.com/docs/engines/table-engines/integrations/postgresql). This engine lets ClickHouse push queries down to Postgres and read the results, then transform and load the data into native ClickHouse MergeTree tables for analytics.

This gave them a single warehouse with streaming on-chain data, batch off-chain metadata, and web analytics, all queryable together.

The data team's Hex dashboards were updated to point to ClickHouse instead of Postgres, and the difference was immediate. No more timeouts. They could query down to any level of granularity they needed. The queries that used to time out in Postgres now ran in milliseconds.

## From internal analytics to user facing features

With the data warehouse running smoothly, Polymarket saw an opportunity to solve another problem: the expensive leaderboard calculation that was bogging down the production Postgres cluster.

> "The leaderboard is aggregated data. We were running these processes in Postgres and it's pretty computationally expensive… that's where ClickHouse thrives." - Max "Primo" Mershon, Senior Data Engineer at Polymarket

In the new architecture, the leaderboard is modeled as aggregated data inside ClickHouse.

* Raw trades and related events flow into ClickHouse from Goldsky.  
* Refreshable materialized views roll those events up into a leaderboard table on a regular schedule.  
* The materialized views handle the heavy lifting, so the production API hits pre-aggregated views.

Because these aggregations are so efficient, they can be infinitely more granular. Previously, the Leaderboard was limited to a single view, where transactions were aggregated across all categories. Now, the Leaderboard can be filtered to new categories and time dimensions.

![polymarket_leaderboard_screenshot.png](/uploads/polymarket_leaderboard_screenshot_b2eb78a3a4.png)

The Polymarket API (written in Go, and using the ClickHouse Go client) queries views that wrap the leaderboard table. These views let them add dynamic parameters, so users can filter by category, time period, or other dimensions on the fly.

The migration of the leaderboard feature from idea to production took approximately two weeks. The [API](https://docs.polymarket.com/api-reference/core/get-trader-leaderboard-rankings) now handles 100s requests per second, with an average latency of approximately 25 milliseconds.

## Impact and benefits

Moving analytical workloads to ClickHouse delivered three major wins:

**Increased granularity**: The efficiency of ClickHouse meant they could build categorical leaderboards (Sports, Politics, P&L, Volume) without overloading Postgres, and enable internal teams to perform larger and more complex analysis without query timeouts.

**Handle future scale**: ClickHouse allows the Polymarket team to continue to scale rapidly, particularly important as their platform has become a social phenomena. The resulting API is performant enough to be used not only by the Polymarket frontend but also by third-party developers building trading bots and analytics tools.

**Reduced load on Postgres**: By moving leaderboard calculations off Postgres, they freed up compute capacity for the core trading platform. No more competing for resources between analytics and transactions.

## What's next

Polymarket is growing rapidly, with every user creating more data and making more requests than ever. New features in the Polymarket app and [public APIs](https://docs.polymarket.com/api-reference/core/get-trader-leaderboard-rankings) continue to evolve how Polymarket uses data. With a U.S. launch coming soon, the pace of growth is set to accelerate even further. ClickHouse will underpin Polymarkets data strategy to handle scale, reduce latency and keep costs in check.

Polymarket migrated computationally expensive analytical workloads from PostgreSQL to ClickHouse to power real-time, user-facing features that scale with rapid growth

large_polymarket_blog_banner.png

medium_polymarket_blog_banner.png

small_polymarket_blog_banner.png

thumbnail_polymarket_blog_banner.png

polymarket_blog_banner.png

How Polymarket scaled their data stack with Postgres and ClickHouse

Want to see our progress?

large_2025 Product Recap Blog Banner.jpg

medium_2025 Product Recap Blog Banner.jpg

small_2025 Product Recap Blog Banner.jpg

thumbnail_2025 Product Recap Blog Banner.jpg

2025 Product Recap Blog Banner.jpg

What’s new in ClickHouse – 2025 roundup

[Ramp](https://ramp.com/)’s engineers have a saying: “Just OLAP it.” It’s shorthand for what’s become second nature: whenever a route is slow or a dashboard starts to lag, they reach for ClickHouse. 

“We’ve done this hundreds of times,” says Ryan Delgado, Director of Engineering and self-proclaimed “ClickHouse enthusiast.” He leads Ramp’s data platform team, which is focused on building infrastructure and tools to help Ramp realize business value from their data. “We use ClickHouse a bunch. It’s been a game-changer for us.”

Today, ClickHouse powers a wide range of customer-facing analytics at Ramp, from AI-powered spend insights to proactive budget controls. But two years ago, none of that existed.

Ryan joined us at our recent [Open House Roadshow in New York City](https://clickhouse.com/blog/open-house-roadshow-nyc-videos), where he shared how the team built a high-performance OLAP platform on [ClickHouse Cloud](https://clickhouse.com/cloud), replacing Postgres bottlenecks with real-time pipelines and helping Ramp scale its analytics.

<iframe width="768" height="432" src="https://www.youtube.com/embed/mPZ7Bck_cMI?si=2N8Fbc_O2O5TaNir" 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>

## Ramp’s journey to ClickHouse Cloud

With more than 50,000 customers, Ramp offers a modern finance operations platform that helps businesses control spend, automate accounting, and manage vendors from a single place. 

“Our goal is to enable companies to reduce spend, while at the same time automating away the tedium that’s historically existed with back-office finance,” Ryan says.

Today, the company is everywhere. In 2025, it aired its first [Super Bowl ad](https://www.youtube.com/watch?v=p1Tgsy7D0Jg), starring Philadelphia Eagles running back Saquon Barkley. Later that year, Ramp went viral after a [marketing campaign](https://briansoffice.com/) that featured “new CFO” Brian Baumgartner (aka Kevin from *The Office*) sitting in a fishbowl in New York’s Flatiron District filing expense reports “the old-fashioned way.”

![image2.png](/uploads/image2_c0e288a8a3.png)

The final count: Ramp 600,000 | Brian 123

“ClickHouse has played a critical role in powering our growth the past two years,” Ryan says.

But back in 2023, Ramp was facing a major problem. The company was growing fast, onboarding larger enterprise customers, each with thousands of cardholders generating huge volumes of transaction data. When those customers tried to run reports on infrastructure powered by Postgres, things started to get slower.

“We had a table that contained every single card transaction,” Ryan says. “When you’re running analytics on that table for a garage-band startup, Postgres works great. But when a larger company tries to run this report, they’re going to wait longer. Sometimes, quite a bit longer.”

At first, the team tried to optimize what they had. They added indexes. They tuned queries. But that made only isolated and incremental improvements.. “We realized the tools we were using weren’t enough,” Ryan says. “We needed to do something else, and fast.”

In September, he reached out to an engineer in his network. He explained the problem and said he was thinking of switching to Apache Pinot or Druid. The engineer’s advice was simple: “You want ClickHouse.”

That night, Ryan spun up a local ClickHouse instance on his laptop. (“If you can do that locally without signing a vendor contract, that’s a huge green flag for any open-source product,” he notes.) He loaded around 60 million card transactions into a [MergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree) table partitioned by business ID, then used the ClickHouse SQLAlchemy library to run 16,000 randomized queries across 32 threads. “And then I just let it cook for a little bit,” he says. 

“Twelve seconds later, it was done,” he explains. “And it was *fast*. I’ve never seen anything like that in my career. I knew we had something really special here.”

He hopped on a call with the [ClickHouse Cloud](https://clickhouse.com/cloud) team to learn more. “They just answered our questions and casually said, ‘Yeah, we have a cloud product.’ They didn’t try to sell it at all,” he recalls. “Needless to say, a week and a half later, we bought the cloud product.”

Immediately after talking with the ClickHouse team, Ramp formed a specialized “OLAP pod” of “four super cracked engineers hyper-focused on solving the problem.” They built a process to denormalize in-flight data, set up a Kafka-based pipeline, and created Ramp’s first analytics-ready ClickHouse table: enriched\_spend\_events.

In just four weeks, ClickHouse was in QA. By Thanksgiving, it was live in production for a handful of customers. Charts that once timed out after 40 seconds were returning in milliseconds. “A lot of the performance issues we saw at the enterprise level—we just erased them immediately,” Ryan says.

## Ramp’s ClickHouse-based architecture

Today, ClickHouse is a foundational part of Ramp’s OLAP platform, serving backend teams and powering real-time analytics across a variety of customer-facing features.

The architecture starts with Ramp’s Postgres monolith, which emits change data capture (CDC) streams via Debezium into Kafka. Each table generates its own Kafka topic, and lightweight, stateless “enrichers” (written in Python) consume those messages, join them with relevant reference data, and emit denormalized records to downstream Kafka topics. The enriched data lands in ClickHouse via a Kafka-to-ClickHouse connector.


![Ramp user story Issue 1219.jpg](/uploads/Ramp_user_story_Issue_1219_e39e491b00.jpg)

Ramp’s OLAP pipeline: CDC from Postgres flows through Kafka enrichers into ClickHouse.

Inside ClickHouse, Ramp uses [ReplacingMergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replacingmergetree) tables to deduplicate incoming data, along with recurring [OPTIMIZE statements](https://clickhouse.com/docs/sql-reference/statements/optimize) and [FINAL query suffixes](https://clickhouse.com/docs/sql-reference/statements/select/from) to ensure consistency. “It works great for online analytics use cases,” Ryan says.

This setup powers features like [Reporting](https://ramp.com/reporting), which enables customers to generate ad hoc and recurring reports in-app.

In addition, ClickHouse enables Ramp Budgets, a forecasting and spend control feature built for large, complex enterprise customers. “A large customer can forecast how much the engineering department will spend on travel and leisure in month one, two, three, four,” Ryan explains. “Then they can track that spending against the allocated budget from the start of the year.” When teams go over budget, Ramp can automatically trigger alerts or apply spend controls.

And the work isn’t done. Over the next year, Ramp plans to expand its OLAP footprint beyond spend data to include tasks, purchase orders, trips, vendors, and more. “I want enriched\_whatever for every single canonical Ramp data type,” Ryan says. “That’s something we’re really focused on and scaling across our product engineering organization.”

## “A classic Ramp story”

Two years into their ClickHouse journey, what began as a scramble to fix slow analytics has become one of Ramp’s most important engineering investments. In just a few weeks, the team built a fast, flexible OLAP platform that underpins some of Ramp’s most advanced features, while scaling effortlessly to support even its largest enterprise customers.

“I’m biased, but I think it’s a great story—a classic Ramp story,” Ryan says. “We love ClickHouse Cloud. It's a great product, a great team, a great slope.”

And if anything’s slow? They just OLAP it.


Ready to scale your team’s data operations?

Building a Postgres-to-Kafka-to-ClickHouse pipeline, enabling millisecond-speed reporting across 50,000 customers.

large_Ramp User Story Issue 1219.png

medium_Ramp User Story Issue 1219.png

small_Ramp User Story Issue 1219.png

thumbnail_Ramp User Story Issue 1219.png

Ramp User Story Issue 1219.png

“Just OLAP it”: How Ramp rebuilt its analytics platform on ClickHouse Cloud

## Company acquires Langfuse to enter LLM observability and introduces a native Postgres service to unify transactional and analytical workloads

**SAN FRANCISCO — January 16, 2026 —** ClickHouse, a leader in real-time analytics, data warehousing, observability, and AI/ML, announced today the close of its Series D financing, raising $400 million. The round was led by Dragoneer Investment Group, with participation from Bessemer Venture Partners, GIC, Index Ventures, Khosla Ventures, Lightspeed Venture Partners, accounts advised by T. Rowe Price Associates, Inc., and WCM Investment Management.

The financing follows a period of sustained, accelerating growth for ClickHouse. The company now serves more than 3,000 customers on its fully managed service, ClickHouse Cloud, with ARR growing more than 250 percent year over year. Over the past three months, customers including Capital One, Lovable, Decagon, Polymarket, and Airwallex have adopted the platform or expanded existing deployments. These customers join an established base that includes AI innovators and major brands like Meta, Cursor, Sony, and Tesla.

"ClickHouse was built to deliver exceptional performance and cost efficiency for the most demanding data workloads, and this momentum validates that strategy,” said Aaron Katz, CEO of ClickHouse. “As we look toward the future, we are adding support for unified transactional and analytical workloads, so developers can build any type of applications powered by AI on the best technical foundation. And we are expanding our offering to include LLM observability, so AI application builders can evaluate the quality and behavior of AI outputs as they move into production. Additional funding, combined with continued product execution, positions us to deliver the leading data and LLM observability platform in the AI era."

![Founders_AMS_2025.jpeg](https://cms.clickhouse-dev.com:1337/uploads/Founders_AMS_2025_df2919ac2a.jpeg)

## A high-conviction investment in data infrastructure and AI at scale
 
Founded by Marc Stad in 2012, Dragoneer takes a highly selective, research-driven approach and seeks long-term partnerships with a small number of category-defining companies. The firm has invested in several of the leading data platforms of the past decade, as well as foundational AI companies.

As AI systems move from experimentation into production, the demands placed on underlying data infrastructure are increasing. AI-driven applications generate significantly higher query volumes, operate with tighter latency requirements, and require continuous evaluation and observability. In this environment, value increasingly accrues to infrastructure platforms that power large-scale, data-intensive production workloads.

"Major platform shifts ultimately reward the infrastructure companies that sit closest to production,” said Christian Jensen, Partner at Dragoneer Investment Group. “As models become more capable, the bottleneck moves to data infrastructure. ClickHouse stood out because it delivers the performance, efficiency, and reliability required for AI systems operating at scale."
 
Dragoneer’s investment followed a rigorous evaluation that revealed the platform to be a category-defining leader in the modern data stack. ClickHouse supports a broad range of mission-critical, real-time workloads embedded in always-on, customer-facing, and AI-driven systems.
 
ClickHouse’s growth has also been driven by its ability to enable net-new workloads rather than simply replacing existing systems. By making real-time analytics cost-effective at scale, the platform supports use cases that were previously impractical due to latency or cost constraints. Unlike many data infrastructure platforms that primarily serve internal analytics teams, ClickHouse is frequently embedded in customer-facing products, where performance and reliability directly impact end-user experience.
 
"We look for platforms that customers rely on when systems cannot go down, and ClickHouse consistently demonstrated those characteristics," Jensen added.

## LLM Observability: ClickHouse enters the market with Langfuse acquisition
ClickHouse is thrilled to announce the acquisition of Langfuse, the open-source LLM observability platform. Unlike traditional observability, which focuses on system health and performance metrics, LLM observability focuses on ensuring that non-deterministic and increasingly complex AI systems produce outputs that are accurate, safe, and aligned with user intent. As AI systems become increasingly embedded in production workflows, LLM observability has emerged as a critical requirement for teams building and operating AI-powered applications.

The Langfuse open source project has seen rapid adoption, ending 2025 at over 20K GitHub stars and more than 26M+ SDK installs per month. 

"We built Langfuse on ClickHouse because LLM observability and evaluation is fundamentally a data problem," said Marc Klingen, CEO of Langfuse. "Now, as one team, we can deliver a tighter end-to-end product: faster ingestion, deeper evaluation, and a shorter path from a production issue to a measurable improvement."

![2025-langfuse-founders.jpg](https://cms.clickhouse-dev.com:1337/uploads/2025_langfuse_founders_75f417565c.jpg)
*Clemens Rawert, Marc Klingen, Max Deichmann, Co-Founders of Langfuse*

## Native Postgres service: ClickHouse announces a unified data stack for AI builders 

ClickHouse is excited to announce an enterprise-grade Postgres service deeply integrated with ClickHouse. To power modern, real-time AI applications that require both transactional and analytical capabilities, ClickHouse is delivering a unified data stack that includes high-performance, scalable Postgres backed by NVMe storage and with native CDC capabilities. In just a few clicks, users can sync transactional data to ClickHouse, unlocking up to 100X faster analytics. With a unified query layer powered by a native Postgres extension, users can build applications that seamlessly span transactions and analytics without managing separate systems. The service is built in partnership with Ubicloud, an open-source cloud company delivering high-performance Postgres, led by a team with a strong track record at Citus Data, Heroku, and Microsoft.

"Postgres and ClickHouse complement each other naturally, and are key for AI applications. Together, we’re delivering an integrated stack that removes complexity for teams, with production-grade Postgres for transactions and ClickHouse for analytics working as one," said Umur Cubukcu, Co-CEO, Co-Founder, Ubicloud. "We’re excited to join forces with ClickHouse at Ubicloud because this is how the open-source ecosystem wins: trusted teams building best-in-class products that work and grow together."

![ubicloud-founders.png](https://cms.clickhouse-dev.com:1337/uploads/ubicloud_founders_4e00466225.png)
*Umur, Ozgun, and Daniel, Co-Founders of Ubicloud*

## Continued global expansion and product momentum

In parallel with its financing and acquisition of Langfuse, ClickHouse continues to expand its global footprint and ecosystem. In the past year, the company has entered the Japanese market through a partnership with Japan Cloud and has announced a partnership with Microsoft Azure focused on OneLake. ClickHouse has also held user events in San Francisco, New York, Amsterdam, Sydney, and Bangalore, attracting over 1000 attendees and featuring speakers from companies like OpenAI, Tesla, Capital One, Ramp, and Canva, and hosted the AWS re\:Invent Chainsmokers customer event for the second consecutive year.

Recent product advancements further strengthen ClickHouse’s position at the intersection of analytics, AI, and observability. The company has made significant investments in data lake support, adding compatibility with Apache Iceberg, Delta Lake, and the most widely used data catalogs. The company has also expanded full-text search capabilities, which are increasingly critical for observability use cases, including AI observability. Finally, lightweight updates have been introduced to support more demanding AI-driven applications. The platform continues to deliver industry leading price-performance, exceeding leading cloud data warehouses according to recent benchmarks.

With the Series D financing, the acquisition of Langfuse, and introduction of a native Postgres offering, ClickHouse is positioned to accelerate growth and further expand its role as a unified data platform and AI observability. 

## Learn more:
- Sign up to experience ClickHouse’s native Postgres service <a href="/cloud/postgres" target="_blank">here</a>. 
- Learn more about the Langfuse acquisition on the ClickHouse <a href="/blog/clickhouse-acquires-langfuse-open-source-llm-observability" target="_blank">blog</a>.
- Stay on top of the latest news and announcements from ClickHouse on <a href="https://www.linkedin.com/company/clickhouseinc/" target="_blank">LinkedIn</a> and <a href="https://x.com/ClickHouseDB" target="_blank">X</a>.

## About ClickHouse
ClickHouse is a fast, open-source columnar database management system built for real-time data processing and analytics at scale. Engineered for high performance, ClickHouse Cloud delivers exceptional query speed and concurrency, making it ideal for applications that demand instant insight from massive volumes of data. As AI agents become increasingly embedded in software and are generating far more frequent and complex queries, ClickHouse brings a high-throughput, low-latency engine, purpose-built to meet this challenge. Trusted by leading companies like Sony, Tesla, Memorial Sloan Kettering, Lyft, and Instacart, ClickHouse helps teams unlock insights and drive smarter decisions with a scalable, efficient, and modern data platform. For more information, visit <a href="https://clickhouse.com/">clickhouse.com</a>.

## About Dragoneer Investment Group
Dragoneer is a growth-oriented investment firm with over $30 billion in assets under management. The firm partners with founders and management teams building category-defining companies in both the public and private markets. More than 50 Dragoneer-backed companies have gone public. Dragoneer investments include Airbnb, Amwins, Atlassian, Databricks, Datadog, Meta, Nubank, OpenAI, Revolut, ServiceNow, Snowflake, Spotify, and Uber.

## About Langfuse
Langfuse is an open-source platform for building, testing, and monitoring LLM applications/agents. Teams use Langfuse to trace and debug agent workflows, run evaluations, and continuously measure and improve the quality of AI outputs in production. Langfuse is available as a managed cloud service and can be self-hosted at production scale. Langfuse is one of the fastest growing LLM engineering platforms, with 20,470 GitHub stars, 26M+ SDK installs per month, and 6M+ Docker pulls, and is trusted by 19 of the Fortune 50 and 63 of the Fortune 500 companies. For more information, visit <a href="https://langfuse.com" target="_blank">langfuse.com</a>.

## About Ubicloud
Ubicloud is building the open-source AWS, delivering core cloud services across bare metal and public clouds. Founded by the team that built distributed PostgreSQL with Citus Data (acquired by Microsoft), Ubicloud’s flagship database offering, Ubicloud PostgreSQL provides an enterprise-grade managed Postgres experience with industry-leading price-performance. Ubicloud services across AI, Compute, PostgreSQL, and Kubernetes power more than 1 million VMs every week, cutting cloud costs by up to 70%. Ubicloud is backed by Y Combinator and other prominent Silicon Valley investors. To learn more, follow Ubicloud on X <a href="https://x.com/ubicloudHQ" target="_blank">@ubicloudHQ</a> or visit <a href="https://www.ubicloud.com" target="_blank">ubicloud.com</a>.


ClickHouse acquires Langfuse to enter LLM observability and introduces a native Postgres service to unify transactional and analytical workloads

large_ClickHouse-raises-400m.png

medium_ClickHouse-raises-400m.png

small_ClickHouse-raises-400m.png

thumbnail_ClickHouse-raises-400m.png

ClickHouse-raises-400m.png

ClickHouse raises $400M Series D led by Dragoneer to accelerate expansion across analytics and AI infrastructure

If you've been to the Netherlands, Germany, or France lately, you’ve probably seen [Picnic](https://picnic.app/)’s little electric trucks zipping through neighbourhoods. The company calls itself an “online everything store,” but in practice it behaves like a million tiny supermarkets—one for every customer.

As software engineer Max Sumrall explains, people don’t come to Picnic once a year to buy a new laptop or TV. They show up every week, often for just a few minutes, to order the exact mix of diapers, vegetables, snacks, and treats that fits their life at that moment. “Someone might only want to order vegan food, or maybe someone really likes hamburgers,” he says. “You need to customize this ecommerce experience for everyone individually.”

Not only is that a lot of customer data to parse, the entire experience runs on a tightly orchestrated supply chain. Picnic is a fully integrated operation with highly automated fulfillment centres, each with kilometers of conveyor belts and robot arms picking orders, not to mention a fleet of more than 5,000 trucks handling the last mile. And they don’t just say “we’ll be there in the afternoon.” As Max says, “We promise a specific 20-minute delivery slot. There’s a lot of data we need to keep track of to make sure we’re there on time.”

At our Open House Roadshow in Amsterdam, Max walked through how Picnic coordinates all of this information across 20+ fulfillment centers—and how they use [ClickHouse Cloud](https://clickhouse.com/cloud) to power a real-time analytics platform that keeps the entire operation running on schedule.

## Why real-time matters for Picnic

Picnic’s fulfillment centers are unique ecosystems, each with their own layout, product assortment, staffing structure, and quirks. But one thing they all share is *pressure*. Orders need to be picked, packed, loaded, and dispatched fast enough to fit within those specified delivery windows. On the warehouse floor, there’s no shortage of questions: Are we on time or running behind? What products are in stock? What’s out of stock? Who’s working where? Which orders are already in progress, and which ones need attention now?

“You have all these people working to get your orders fulfilled,” Max says. “We need real-time analytics to make sure that process happens on time.”

For Picnic, the major challenge was scale and variability. From Utrecht to Oberhausen, each warehouse has its own requirements, particularly when it comes to data. “You need a lot of customization to get every warehouse running,” Max says. “It’s not going to be sustainable for a team of engineers to build custom solutions for every single warehouse. Because we’re not working on the warehouse floor, we don’t know exactly what they need.”

So Max and the team built a self-service platform that provides real-time information on supply chain operations. They call it the real-time insights (RTI) platform—a system that ingests operational events from across the business and turns them into metrics and dashboards that warehouse teams can use without developer support.

Analysts and floor teams can define the views they need themselves, tracking everything from progress against forecasted order volumes to zone-level performance in chilled and ambient areas. These dashboards give teams immediate, shift-by-shift feedback on whether they’re ahead or behind schedule and what needs attention next.

## Picnic’s ClickHouse-based architecture

The RTI platform’s architecture is “not exactly rocket science,” Max says. Even so, it gives Picnic a scalable, reliable foundation for turning a continuous stream of operational events into real-time insight across the entire fulfillment network.

![Picnic User Story Issue 1220 (2).jpg](/uploads/Picnic_User_Story_Issue_1220_2_56adc0da5a.jpg)

Picnic’s real-time data pipeline, with events processed in ClickHouse and visualized in Grafana.

It starts with the event sourcing layer. This includes Java backend services emitting operational events, mobile apps sending clickstream data, and slow-moving dimensional data tracking things like product assortment, vehicle information, and warehouse layout.

Next is a transport layer built on RabbitMQ and Apache Kafka, with the occasional direct HTTP call when that’s the simplest operation. Rather than wiring every application directly to ClickHouse, Picnic runs a dedicated Java ingestion service (“essentially our own version of [ClickPipes](https://clickhouse.com/cloud/clickpipes),” Max calls it, adding, “maybe we’ll switch one day”) that knows how to read from each queue, topic, or endpoint and land data consistently in ClickHouse.

Once data is inside ClickHouse, the event processing layer transforms and aggregates the raw events. As Max explains, [materialized views](https://clickhouse.com/docs/materialized-views) act like “database triggers”—data lands in a source table, and the view immediately inserts a parsed, query-ready version into a downstream table. “Every event always comes first through a [materialized view](https://clickhouse.com/docs/materialized-views),” he says. Because this system predates ClickHouse’s [JSON data type](https://clickhouse.com/docs/sql-reference/data-types/newjson), raw payloads are stored as strings for now. For more complex transformations and aggregates, Picnic uses [refreshable materialized views](https://clickhouse.com/docs/materialized-view/refreshable-materialized-view).

ClickHouse also acts as the serving layer, with different [table engines](https://clickhouse.com/docs/engines/table-engines) tailored for different jobs. Given the team’s familiarity with Postgres and Snowflake, they were able to ramp up quickly. “ClickHouse is written in SQL, so it’s really easy for analysts to get up to speed,” Max says. “It works really well for experimental use cases and people trying new queries on the fly, while also being there for all of the use cases we’ve developed that are operationally crucial.”

On top of that sits the visualization layer. Grafana connects directly to ClickHouse, and teams build panels using SQL. “We use Grafana for our operational dashboards to keep track of what’s going on,” Max says. “It’s pretty capable, and the [integration with ClickHouse](https://clickhouse.com/docs/observability/grafana) works well.”

To keep the platform self-service, Picnic treats all data models as code. Analysts define new models in dbt, submit them through GitHub pull requests, and automated checks validate schemas, business rules, and downstream dependencies. “We wanted something a business analyst can use themselves, not something an engineer has to maintain,” Max says. He adds that [dbt and ClickHouse](https://clickhouse.com/docs/integrations/dbt) “work really well together,” allowing the team to redeploy models or even replay the entire pipeline from Kafka retention when needed. Slack notifications close the loop, alerting analysts when models are deployed or when data quality issues arise.

## The advantages of ClickHouse

Picnic’s RTI platform actually didn’t start with ClickHouse. The first version ran on TimescaleDB, which Max calls “very fast with good query performance.” But, he says, “it’s very complex to get going and can be hard to use as a platform because you need a lot of expertise.”

ClickHouse offered the combination of performance, cost-efficiency, and usability they needed. As Max puts it, “ClickHouse is very easy to operate. It’s very cost-effective, with things like TTLs. Scaling is really simple with ClickHouse Cloud. We’re very happy with it.”

Since rebuilding around ClickHouse two years ago, adoption has surged. “It basically unhooked adoption from needing developer support,” Max says. “You can see that with the amount of data we store in ClickHouse versus Timescale, which really took off once we switched.”

![Picnic User Story Issue 1220.jpg](/uploads/Picnic_User_Story_Issue_1220_5730066c08.jpg)

Picnic’s dbt model count accelerated sharply after adopting ClickHouse for real-time analytics.

![Picnic User Story Issue 1220 (1).jpg](/uploads/Picnic_User_Story_Issue_1220_1_edea0aa714.jpg)

ClickHouse unlocked rapid dbt model growth across warehouse and app analytics workloads.

ClickHouse’s flexibility has also proved to be an advantage. When Picnic needed fine-grained access control to support GDPR, for example, the team used the [getClientHTTPHeader function](http://getClientHTTPHeader) alongside Grafana’s Keycloak integration and ClickHouse [row-level policies](https://clickhouse.com/docs/sql-reference/statements/create/row-policy). User identity flows in via HTTP headers; [dictionaries](https://clickhouse.com/docs/sql-reference/dictionaries) and policies translate it into table-level and row-level permissions. It’s an unusual pattern, but one ClickHouse already had the pieces to support.

“What’s cool about ClickHouse is there are lots of random little things they’ve built over the years,” Max says. “If you need something, you can always start searching GitHub pull requests and issues, and you’ll see some long discussion from 10 years ago with Alexey and other engineers, and then you find out, ‘Oh, there’s a tool for that.’”

## What’s next for Picnic’s real-time platform

Today, ClickHouse ingests and aggregates events; tomorrow, it may also act as a stream processor. The Picnic team is currently experimenting with [RabbitMQ](https://clickhouse.com/docs/engines/table-engines/integrations/rabbitmq) and [Kafka table engines](https://clickhouse.com/docs/engines/table-engines/integrations/kafka) hooked up to [materialized views](https://clickhouse.com/docs/materialized-views) that transform events and write their outputs into downstream Kafka topics. In that model, ClickHouse becomes both the brain of the analytics platform and an active participant in event-driven workflows. “If this takes off, we might have some future requests to the ClickHouse team,” Max says with a smile.

The team is also exploring how AI can support developers and analysts inside Picnic’s workflow. A new experiment combines dbt’s rich metadata (e.g. models, dependencies, examples) with ClickHouse data using the [ClickHouse MCP server](https://clickhouse.com/blog/integrating-clickhouse-mcp) and a GitHub action powered by Claude Code. As Max explains, “You can give the context of all your dbt models to the AI and see if it can help you generate new models, validate the models you want to create, or suggest answers to queries.”

These new initiatives, he says, are a “natural step forward” from what Picnic has already built: a powerful real-time analytics platform that keeps operations running smoothly across 20+ fulfillment centers, with ClickHouse at its core.


“ClickHouse is very easy to operate, very cost-effective, and scaling is really simple with ClickHouse Cloud. We’re very happy with it.”  Max Sumrall, Software Engineer

ClickHouse

Blog posts by ClickHouse

How ClickHouse Cloud enabled LaunchDarkly to build and ship features faster

How Polymarket scaled their data stack with Postgres and ClickHouse

What’s new in ClickHouse – 2025 roundup

“Just OLAP it”: How Ramp rebuilt its analytics platform on ClickHouse Cloud

ClickHouse raises $400M Series D led by Dragoneer to accelerate expansion across analytics and AI infrastructure

How Picnic uses ClickHouse for real-time analytics across 20+ fulfillment centers and 1 million unique stores