Mintlify uses ClickHouse Cloud to give tens of thousands of companies real-time visibility into how tens of millions of developers engage with their content. After replacing PostHog with ClickHouse, dashboard load times dropped from tens of seconds to sub-one-second, driving an estimated 30% NPS improvement. ClickHouse Cloud requires zero ongoing maintenance and runs at 60% lower cost than PostHog, with an architecture built to scale well beyond Mintlify's current size.

Summary

[Mintlify](https://www.mintlify.com/) is the intelligent knowledge platform powering help centers, support centers, and developer documentation sites for companies like Anthropic, Microsoft, Coinbase, and Perplexity, serving tens of millions of developers each month.

Over the past year, the company has seen a major shift in who—or what—is reading those docs. Traffic that was once 90% human and 10% AI crawlers is now split evenly, and Mintlify expects AI agents to account for 90% of all traffic by the end of 2026.

As tools like ChatGPT, Claude, and Cursor increasingly rely on documentation, Mintlify's customers need fast, reliable insight into how both humans and agents are engaging with their content, so they can make informed decisions about what to improve. But as usage grew, serving that data quickly and reliably turned out to be harder than expected.

"Prior to using ClickHouse, opening the analytics page in the Mintlify dashboard could take tens of seconds to load," says engineering manager Nicholas Khami. "After using ClickHouse, we've gotten that latency down to sub-one-second—it's almost instant."

We caught up with Nick to learn why Mintlify migrated from PostHog, what made them choose [ClickHouse Cloud](https://clickhouse.com/cloud), and how it's helping them scale to meet a future dominated by AI agents.

## Outgrowing PostHog

Before migrating to ClickHouse, Mintlify initially used PostHog for product analytics, and it was a relatively easy lift to embed it into their dashboard for customer use. The setup worked well at first, but as their customer base grew, it began to show its limits.

The core issue was architectural. "PostHog is a great product," Nick says, "but it just doesn't support [incremental materialized views](https://clickhouse.com/docs/materialized-view/incremental-materialized-view), which was causing really high latency." For a multi-tenant SaaS platform like Mintlify, where tens of thousands of companies are each querying analytics on their own traffic, that caused serious problems.

Without incremental materialized views, every dashboard triggered raw queries against the full dataset, resulting in sluggish load times and rate limit errors that caused dashboards to fail entirely. "It was very slow and would error out due to those rate limits," Nick says.

At the height of the problem, the limitations of the existing analytics setup became increasingly clear. Dashboard performance and reliability issues began to significantly impact the customer experience and required ongoing attention from the engineering team. The team knew it was time for a more scalable solution.

## Choosing ClickHouse Cloud

Nick wasn't coming to ClickHouse cold. Before joining Mintlify, he had co-founded [Trieve](https://www.trieve.ai/), a search API startup that used ClickHouse for search analytics at over 100 requests per second. When Mintlify acquired Trieve in 2025, Nick—and ClickHouse—came along with it, effectively powering Mintlify's own search analytics. When the team began evaluating alternatives to PostHog, that positive firsthand experience gave him a strong starting point.

Still, the team did their due diligence, considering two other options. "DuckDB didn't meet our needs, as we had real-time analytics that needed to horizontally scale to a larger growing customer base," Nick says. "BigQuery was very expensive and difficult to get started with relative to ClickHouse."

Ultimately, Nick and the team's familiarity with ClickHouse, combined with its ease of use, strong open-source community, and wealth of real-world examples made the decision easy.

The next question was whether to self-host it or use [ClickHouse Cloud](https://clickhouse.com/cloud). Nick had self-hosted at Trieve, so he knew what that entailed. For Mintlify, three things tipped the decision toward the managed service. First was ClickHouse Cloud's [Query Insights](https://clickhouse.com/docs/cloud/get-started/query-insights) tool. "The fact that you can put a query into ClickHouse Cloud and it can tell you whether or not that query is optimal was really huge for our team," Nick says. "It really carries a lot of the burden for us."

Second, the team wanted to use MSK, Amazon's managed Kafka service, to handle data ingestion. At Mintlify's volume, Nick says, "ClickHouse Cloud made it a lot easier to set up MSK with VPC peering than it would have been to do that on our own infrastructure."

Third, Mintlify simply is an ECS rather than Kubernetes shop, so self-hosting on EKS would have added meaningful overhead to managing their own deployment. "As a result," Nick says, "it just made a lot more sense to use the cloud product."

## A two-week migration

The migration took place in the fall of 2025 over a period of about two weeks.

Rather than cutting over all at once, the team dual-wrote events to ClickHouse and PostHog simultaneously, querying both in parallel to compare results. To minimize disruption, they replicated PostHog's event schema directly in ClickHouse, mapping the same handler functions and API surface area one-to-one. "That made our migration super smooth," Nick says. "We didn't have to change much of our API surface area or integration."

Today, all of Mintlify's events flow exclusively through MSK into ClickHouse via [ClickPipes](https://clickhouse.com/cloud/clickpipes), ClickHouse's native ingestion service. Previously unavailable in PostHog, [incremental materialized views](https://clickhouse.com/docs/materialized-view/incremental-materialized-view) are now at the core of how Mintlify serves analytics data to its customers, powering real-time dashboards without expensive raw queries against the full dataset.

Along with customer-facing analytics, the data powers an internal AI Slack bot that gives Mintlify's go-to-market team read-only access to customer data, helping them spot high-growth accounts and make more informed product decisions. "ClickHouse is great for that," Nick says. "These queries happen a lot faster than our previous solution, where we were hitting rate limits."

## Faster analytics, happier customers

For Mintlify's customers, ClickHouse delivered benefits right away. Dashboards that took tens of seconds to load in PostHog now return results in under a second. "Migrating to ClickHouse brought latency down and removed all of those rate limits," Nick says. "Now our analytics consistently show up correctly for our customers every single time—and show up quickly—which is just huge for improving satisfaction."

That satisfaction is evident in Mintlify's NPS score, which Nick estimates has increased by roughly 30%. "We went from around 10% of customers raising issues about analytics every week to zero reports per week of analytics bugs," he says. "We no longer get customer support messages about it not working, which was the best outcome."

Perhaps just as impactful from an operational standpoint, ClickHouse Cloud requires zero ongoing maintenance from Mintlify's engineering team. "We set up the thing and the thing runs," Nick says. "No one is full-time managing it. It's straight-up zero hours of work a week on average. That's the beauty of using ClickHouse Cloud."

Cost turned out to be a welcome bonus. Nick estimates that ClickHouse Cloud runs at around 60% less than what Mintlify was spending on PostHog for the same workload—though he's quick to note that cost was never the driving factor. "We really wanted product quality over anything else," he says. "Cost savings were just an added benefit."

## Lessons learned along the way

Having implemented ClickHouse twice now—first at Trieve, now again at Mintlify—Nick has a few recommendations for teams considering a similar move.

First, if you're dealing with high event volumes, use [ClickPipes](https://clickhouse.com/cloud/clickpipes) for MSK. "It's a lot more efficient than writing data directly, and ClickHouse Cloud with ClickPipes works really well and allows you to scale more smoothly," Nick says. It's a lesson he learned the hard way—Trieve didn't use MSK, and fixing that was one of the first things he did differently at Mintlify.

Second, start with a single events table and build [materialized views](https://clickhouse.com/docs/materialized-views) on top. As Nick explains, materialized views are a first-class primitive in ClickHouse—essentially tables in their own right—so there's little benefit to managing a sprawl of separate tables. "You'll have a much easier time if you create one giant table for all your events and then create materialized views on top of that," Nick says.

Finally, he suggests using existing migration tooling rather than building your own. "Having migrations as code is important, and ClickHouse has recently invested in more tooling around that, which has been great." Starting from scratch, he adds, isn't worth the effort.

## Scaling for an agentic future

For Nick and the team, the migration to ClickHouse achieved exactly what they set out to accomplish. "There are thousands of companies who are now able to look at traffic statistics for tens of millions of developers every month and figure out what in their product is working well, what's confusing, and where they should polish or spend time improving their documentation," he says. "As a developer myself, I'm super proud of that."

The executive team agrees. "Our CTO and CEO deeply care about the customer experience," Nick adds. "I can tell you they were quite happy and they trust ClickHouse to power our growth."

Looking ahead, the challenge—and the opportunity—is only getting bigger. With AI agent traffic growing exponentially, Mintlify is investing heavily in making sure the experience is as good for agents as it is for humans. That means analytics will only become more important, not less. "I think businesses that use Mintlify will need really fast, reliable analytics on how agents are using their product versus how humans are using it," Nick says. "As we figure out what the best insights are, we're going to continue using ClickHouse to make them easily available."

With ClickHouse Cloud, Mintlify's infrastructure is built for growth. "We've future-proofed the architecture for many years of scaling beyond where we're at now," Nick says. "We're growing really fast, and it's not even close to the limits of what we see it doing."

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

Mintlify replaced PostHog with ClickHouse Cloud, cutting dashboard load times from tens of seconds to under a second, eliminating rate limit errors, and achieving a 30% NPS improvement at 60% lower cost.

large_Mintlify Customer Story.png

medium_Mintlify Customer Story.png

small_Mintlify Customer Story.png

thumbnail_Mintlify Customer Story.png

Mintlify Customer Story.png

Mintlify boosts NPS 30% and saves 60% with real-time analytics on ClickHouse Cloud

Eisan built a real-time ID-POS analytics platform for multiple retail clients, supporting basket analysis, cross analysis, and personalized recommendations at scale They replaced a QlikView-based BI stack with ClickHouse Cloud to improve reliability and performance while reducing licensing and infrastructure costs. The system now supports hundreds of millions of records per client today, with a clear path toward tens of billions through ongoing optimization.


For nearly four decades, [Eisan System Development](https://eisansystem.jp/) has built highly specialized software in domains where precision matters, from medical and healthcare systems to large-scale data matching, and more recently, IoT-enabled platforms. Much of that work runs quietly behind the scenes, supporting mission-critical workflows for organizations that can't afford mistakes.

That mindset carried into a recent challenge Mamoru Ubukata, Eisan's Representative Director, shared at a [July 2025 ClickHouse meetup in Tokyo](https://www.youtube.com/watch?v=fKP-6-_PiZQ). It started simply, with a client asking for help. Their existing analytics system, built on a traditional BI tool, was starting to strain under growing data volumes and rising expectations for real-time insight.

"They reached out to see if we could find a better solution," Mamoru explains. What followed was a pragmatic, engineering-led search for a platform that could scale without sacrificing reliability—one that ultimately led Eisan to [ClickHouse Cloud](https://clickhouse.com/cloud).

<iframe width="768" height="432" src="https://www.youtube.com/embed/fKP-6-_PiZQ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## The old system: costly and unreliable

At the heart of the challenge was ID-POS data: point-of-sale records tied to individual customer IDs, collected from supermarkets and drugstores. For retail clients, this data powers basket analysis and cross analysis, as well as real-time personalization, where products are recommended as customers identify themselves in-store. Over time, that data adds up, with some clients accumulating close to 200 million records per year.

The analytics platform Eisan had been using for this workload was built on QlikView and designed for speed—in theory, at least. Because everything was processed in memory, simple aggregations often came back in just a few seconds. "However," Mamoru says, "as the data increased, some processes could take minutes to process." Worse, the system began failing in ways that were hard to anticipate or control. "Recently, we've been seeing more and more cases where we don't even get analysis results back anymore. This is a very serious issue."

As more clients came onto the platform, cost pressures intensified. QlikView's licensing model meant expenses rose with every new deployment—something Mamoru describes as a "real burden and major concern for our users." The system's memory-heavy design only amplified the problem. "Since QlikView processes everything in memory, it inevitably consumes a huge amount of memory," he says. "As a result, our server costs keep rising as well."

## ClickHouse to the rescue

The team's first instinct was to look for an open-source alternative. The goal was to cut costs while regaining control over performance and scalability. They evaluated familiar options like PostgreSQL and distributed systems such as YugabyteDB. "None of them delivered the results we were looking for," Mamoru says. Discouraged, the team began to wonder if a better solution really existed. "You could call it a defeatist mindset, but we were just about ready to give up."

Then, almost by chance, they discovered ClickHouse. "Its speed was absolutely incredible," Mamoru says. "We thought, 'maybe this could actually work.'" That initial impression was enough to justify a deeper evaluation, and eventually, a move toward production.

At the Tokyo meetup, Mamoru shared a side-by-side comparison of the old QlikView-based system and the new ClickHouse setup. While ClickHouse was clearly faster, the results didn't look dramatic on paper. But context, he says, matters. "QlikView is processing everything in memory. That's not the case with ClickHouse, which is really impressive."

Even compared to so-called general configurations, ClickHouse produced stable results with fewer resources. "The ClickHouse server actually has slightly lower specs compared to typical setups, and we are running it under high-load settings. Even so, the performance does not deteriorate and the results are very stable. With conventional products, if you want to do the same thing, you tend to decide to increase the hardware, but with ClickHouse I feel like you can solve the problem before that happens," says Ubukata.

Perhaps most importantly, ClickHouse behaves predictably under pressure. "With QlikView, it's pretty common for results to not come back at all," Mamoru says. "So far, we've never had a case where ClickHouse failed to return a result."

## The subtle art of server balance

Once ClickHouse proved itself, a new question emerged: how to run it efficiently. Mamoru and the team began testing different configurations in [ClickHouse Cloud](https://clickhouse.com/cloud), focusing on the balance between CPU cores and memory. One setup used 30 cores and 120 GB of RAM, following a [1:4 core-to-memory ratio](https://clickhouse.com/docs/guides/sizing-and-hardware-recommendations#how-many-cpu-cores-should-i-use) commonly used as a starting point for ClickHouse workloads.

At first glance, the metrics raised questions. CPU utilization looked healthy, but memory usage appeared surprisingly low. "That led to a discussion about whether this balance is actually optimal," Mamoru says. After speaking with the ClickHouse Japan team, the picture became clearer. "That's when I learned that a fair amount of memory is being used for caching."

Once they accounted for that behavior, effective usage was closer to 100 GB, making the setup feel more balanced than it first appeared. The takeaway wasn't a fixed answer, but more of a process. "Of course, there are still a lot of different scenarios to consider," Mamoru says. The team continues to run load tests, adjusting server specs and observing how ClickHouse behaves under different conditions, refining the setup step by step.

## What's next for Eisan and ClickHouse

Eisan's plans for ClickHouse extend well beyond the current system. "Ultimately, we're expecting the number of users to grow," Mamoru says. "Our goal is to be able to handle data on the scale of 100 billion records." Achieving that scale will take smart architectural decisions, along with continued testing and iteration as workloads evolve.

The team is also taking a closer look at how the system is used day to day. Right now, most analytics jobs run during business hours. "As a result," Mamoru explains, "the system is hardly used at night." To make better use of available capacity, they're exploring ways to shift weekly or monthly processing to off-hours, smoothing resource usage over time.

[Autoscaling](https://clickhouse.com/docs/manage/scaling) is part of that conversation as well. So is the idea of more intentional, scheduled scaling. "I'm not sure if 'scheduled scaling' is the right term," Mamoru says, "but I think it could be possible to, say, completely shut down operations on Sundays. That could be useful."

For Eisan, ClickHouse is less a finished project than a foundation for what's ahead. Processing times are already improving, and new capabilities continue to expand what's possible. The real challenge is now operational: how to keep large-scale, real-time analytics systems running smoothly as both data volumes and expectations continue to grow.


Rill uses ClickHouse to power real-time operational BI for 100B+ daily events, enabling instant exploration and conversational analytics directly against live datasets through a declarative, BI-as-code workflow.

large_Eisan User Story Issue 1247.jpg

medium_Eisan User Story Issue 1247.jpg

small_Eisan User Story Issue 1247.jpg

thumbnail_Eisan User Story Issue 1247.jpg

Eisan User Story Issue 1247.jpg

How Eisan made POS analytics faster, cheaper, and more reliable with ClickHouse Cloud

- Respan uses ClickHouse Cloud to power high-throughput LLM observability across 50 million daily events.
- After outgrowing Postgres at 50-100 writes per second, the team migrated ingestion and analytics to ClickHouse Cloud.
- Incremental materialized views and trace aggregations keep dashboards fast even as datasets scale into the billions of rows.


[Respan](https://www.respan.ai/) (formerly Keywords AI) is building an AI gateway with built-in observability. Designed for LLM applications running in production, the platform routes requests across models and providers while giving teams visibility into performance, evaluations, and prompt management.

Part of YC’s W24 cohort, the company quickly gained traction with thousands of developers, and traffic grew from a few hundred requests per day to roughly 30 million requests per day, or close to one billion requests per month. Alongside live LLM calls, cached requests also generate observability data, pushing overall event volume even higher.

Today, Respan processes around 50 million events per day. At that scale, activity is constant. "There are thousands of events going through our pipeline as we speak," said co-founder and CTO Raymond Huang at a [December 2025 meetup in San Francisco](https://clickhouse.com/videos/meetupsf_dec_20251).

At the meetup, Raymond walked through a live demo showing how Respan’s backend evolved from a simple Postgres-based setup to [ClickHouse Cloud](https://clickhouse.com/cloud), which now powers high-throughput ingestion, fast analytics, and production-grade LLM observability.

## From Postgres to ClickHouse

Respan is a lean team with a true startup mentality. "We move fast and we build fast," Raymond says. Early on, the platform’s backend reflected that scrappy mindset: a Django app backed by Postgres, logging each request as it arrived. "One request comes in, it goes into Postgres, and we store it," Raymond explains. "It’s that simple."

At low volumes, the approach worked. The system handled tens of events per second without trouble, and the mental model was easy to reason about. But as workloads climbed into the 50 to 100 requests per second range, transactions started to contend with one another.

Postgres was behaving exactly as it should, serializing work to preserve correctness, but under steady write pressure, each insert had to complete its transaction and be recorded in the write-ahead log before subsequent writes could proceed. As Raymond puts it, “Things start to pile up, and from there they escalate quickly.”

There was a clear mismatch between Postgres’s transactional model and the demands of real-time observability at scale. Squeezing more out of their current setup wasn’t an option, so the team decided to look for a better solution. They found it in ClickHouse Cloud.

"We decided to move to ClickHouse," Raymond says. "That helped significantly. We can now easily handle the scale that we couldn’t before."

## Designing logs for sustained ingestion

As they began migrating to ClickHouse, the team focused on getting the schema right. They knew it could handle the write volume, but only if the data model supported it.

Logs were designed to be compact and structured, storing only the fields that would actually be queried or aggregated. Metrics and metadata—latency, throughput, routing time, cost—are written as typed columns optimized for analytical workloads.

Larger text fields, like prompt inputs and model outputs, are deliberately truncated before ingestion. The goal isn’t to capture full transcripts, but to preserve enough context for debugging and analysis without letting row size grow unchecked.

"We don’t store big data in ClickHouse because memory efficiency is important," Raymond says. "We store minimal information so we can keep each message small and the ingestion rate as high as possible."


## Building fast analytics with materialized views

Ingesting data at scale is only useful if the analytics layer can keep up. Respan's customers expect dashboards that load quickly and support common slices of data without delay. To make that happen, the team relies heavily on [incremental materialized views](https://clickhouse.com/docs/materialized-view/incremental-materialized-view).

Raw logs are first aggregated into minute-level windows, partitioned by organization, then cascaded into hourly rollups. Each materialized view targets a specific dimension—organization and API key, customer identifier, environment, deployment or model—so dashboards query pre-aggregated data instead of scanning raw logs.

"This way, we don’t have to recompute all the aggregations," Raymond says. "That saves us a lot of query power."

By aggregating early and limiting recomputation, the team keeps query costs predictable and avoids full-table scans as the dataset grows. “With this breakdown, we can easily grab data and have optimal performance,” Raymond adds.

## Separating real-time metrics from user metadata

Not every query needs to be real-time. Some dashboards require sorting and joining against user-level metadata—customer IDs, names, email addresses—alongside aggregated metrics. Grouping by every metadata column would make queries heavier and more expensive, especially as row counts grow.

Instead, the team uses [refreshable materialized views](https://clickhouse.com/docs/materialized-view/refreshable-materialized-view) for this layer of analytics. These views aggregate the necessary fields and refresh on a fixed cadence—every 10 minutes in Raymond’s demo—rather than updating on every insert.

"The user data doesn’t have to be real-time," Raymond explains. By separating high-frequency metrics from slightly delayed metadata, the system avoids wide [GROUP BY](https://clickhouse.com/docs/sql-reference/statements/select/group-by) clauses and keeps joins efficient.

Everything is written into [MergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree) tables, partitioned by time, so queries can filter aggressively before joining. The result is dashboards that remain fast and sortable, even when combining behavioral metrics with user attributes.

## Traces without expensive reconciliation

Understanding complex LLM workflows doesn’t end with logs. Respan also supports tracing to show how individual requests move through the system. Each trace is composed of spans, which may arrive out of order in distributed environments.

Rather than enforcing strict ingestion order, the system encodes relationships directly in the data. Spans reference their parents, and those relationships are resolved analytically at query time. "Everything can be asynchronous as long as eventually they meet each other in the database," Raymond says. By avoiding coordination at write time, the pipeline remains fully asynchronous.

When building trace aggregations, the team is equally deliberate. They avoid using the [FINAL](https://clickhouse.com/docs/sql-reference/statements/select/from#final-modifier) modifier, which can force ClickHouse to recompute and merge large portions of a table at query time. Instead, trace metrics such as span counts, token usage, cost, and error rates are computed using aggregate functions. Functions like [argMax](https://clickhouse.com/docs/sql-reference/aggregate-functions/reference/argmax) allow the system to select the latest point-in-time values without triggering expensive full-table processing. The result is trace analytics that remain predictable and memory-efficient as span volume grows.

## A system that’s easier to operate at scale

As Respan’s system scaled, operational simplicity became increasingly important. One of ClickHouse’s biggest strengths, Raymond says, is the simplicity of its [indexing model](https://clickhouse.com/docs/guides/best-practices/sparse-primary-indexes), which reduces what engineers have to manage day to day.

"This enables me to sort really quickly without having to worry about index-tree structure," he says. "I only have to worry about if the partition is right and whether the querying data fits into the memory. If it doesn’t, I just scale the instance—it’s that simple."

That predictability extends to everyday workflows like log search. Even without relying on advanced full-text search features, straightforward string queries can scan tens of millions of rows in sub-second time. As Raymond says, "That’s pretty impressive."

Today, ClickHouse underpins Respan’s observability stack from ingestion through customer-facing analytics. Most importantly, it provides a solid foundation that scales with the product, without forcing constant architectural revisions as usage grows.

"Big shoutout to the ClickHouse team," Raymond says. "We built one of the best products in the LLM observability space—this wouldn’t have been possible without ClickHouse’s support."

Respan AI uses ClickHouse Cloud to power high-throughput LLM observability across 50 million daily events. After outgrowing Postgres at 50-100 writes per second, the team migrated ingestion and analytics to ClickHouse Cloud. Incremental materialized views

large_respan-ai-banner.jpg

medium_respan-ai-banner.jpg

small_respan-ai-banner.jpg

thumbnail_respan-ai-banner.jpg

respan-ai-banner.jpg

How Respan is scaling LLM observability with ClickHouse Cloud

Modern business is becoming increasingly granular. Cloud providers record usage down to individual operations. Payment platforms track transactions in real time. AI systems meter tokens, requests, and compute consumption. What started as observability inside IT systems has spilled outward, turning the rest of the business into a living stream of events.

"We have this sort of mirror digital universe, where everything we do is an event," says Mike Driscoll, co-founder and CEO of [Rill](https://www.rilldata.com/), an operational BI-as-code tool focused on [real-time analytics](https://clickhouse.com/resources/engineering/what-is-real-time-analytics). "And when we have this data, we want to make sense of it."

As Mike puts it, the challenge isn't collecting data so much as understanding how it fits together. A company might see cloud costs in AWS or Google Cloud, revenue in Stripe, and product usage tracked somewhere else entirely, yet none of these systems explain how the business is doing as a whole. "You can't rely on another company's dashboard to make sense of your business," he says. "Ultimately, you have to integrate all of that data yourself."

BI tools like Rill have emerged as a way to bridge that gap, bringing operational and financial data together so teams can understand what they're spending and why. But that approach requires analytics systems capable of aggregating huge volumes of data quickly and efficiently. "ClickHouse is amazing at doing aggregation at massive scale," Mike says.

At a [December 2025 ClickHouse meetup in San Francisco](https://clickhouse.com/videos/meetupsf_dec_20253), Mike shared how Rill combines declarative ingestion with dlt, high-performance aggregation in ClickHouse, and a metrics-first operational BI layer to build a system designed to make sense of a metered world.

<iframe width="768" height="432" src="https://www.youtube.com/embed/ejOKXO2159M" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## A fast BI tool for real-time databases

Rill's approach to analytics grew out of more than a decade spent working on real-time event data at scale. In 2010, Mike co-founded Metamarkets, the company behind Apache Druid, one of the first databases built for interactive analytics on streaming data. After Metamarkets was acquired by Snap in 2017, Mike and Nishant Bangarwa founded Rill in 2020, applying what they had learned building analytics infrastructure to rethink BI for a real-time world.

Today, Rill processes more than 100 billion daily events across thousands of users, serving digital media giants such as Bloomberg and Comcast, large enterprises like AT&T, and a growing number of fintech and ecommerce companies. "A lot of our customers look like the kinds of customers that love and use ClickHouse," Mike says. "So it's no accident that we found a great fit using ClickHouse as our database."

Rill takes a BI-as-code, developer-friendly, and agent-first approach. Data sources, transformations, and business logic are defined as code, allowing teams to develop with modern tools like Cursor, version changes through Git, and deploy analytics the same way they ship software. "We really are proponents of this declarative data stack," Mike says. "Between SQL and YAML, you can build [data applications](https://clickhouse.com/resources/engineering/data-application), not just dashboards."

That philosophy extends into Rill's metrics-first design. Teams declare metrics using SQL expressions, creating a shared semantic layer from which dashboards are generated, not created. As Mike says, this becomes increasingly relevant as AI and conversational analytics enter the workflow. "SQL is valuable," he explains, "but it turns out agents do a lot better when they've got something like a semantic layer to interact with."

Underneath it all is real-time performance. Traditional BI tools often treat heavy queries as something to be avoided, relying on caching to keep dashboards responsive. "But when you're using something like ClickHouse," Mike says, "there's no need to avoid hitting the dashboard hundreds or thousands of times." For Rill's customers, that translates into instant drilling, slicing, and dicing, alongside fast conversational agents that operate directly on live data.

As Mike puts it, "Because we've built around a real-time database like ClickHouse, we're able to do things other dashboards wouldn't even attempt to do."

## Inside Rill's ClickHouse-based architecture

Rill's architecture keeps analytics close to the database while defining everything else as code. Instead of introducing new layers between ingestion, modeling, and analysis, the system connects them into a single workflow built around declarative configuration.

![](/uploads/Rill_User_Story_Issue_1250_0_7064f28ae6.png)

*Rill's architecture: declarative data ingestion, ClickHouse-powered aggregation, and operational BI.*

Data ingestion is orchestrated using software like dlt (data load tool), an open-source Python framework for declarative data loading. Operational databases, object stores, data lakes, and warehouses are extracted through reusable connectors, with transformations and source credentials defined in SQL and YAML. Rather than maintaining custom pipelines, teams describe how data should move, and dlt handles extraction and loading into ClickHouse automatically.

Once loaded, ClickHouse serves as the [analytical engine](https://clickhouse.com/resources/engineering/what-is-columnar-database), with queries executing directly against large-scale event data. Business logic is expressed through measure expressions and dimension metadata, compiled into SQL models that power aggregations at query time. These definitions form the shared metrics layer, ensuring dashboards, APIs, and programmatic access all rely on the same logic.

Atop this foundation sits Rill's operational BI layer, where role-based security policies and dashboard configurations are also defined as code. Because dashboards are generated from metric definitions rather than built manually, analytics applications remain lightweight interfaces querying ClickHouse in real time.

The result is a composable system where data flows from source systems into ClickHouse, delivering interactive analysis to product, operations, and finance teams, as well as external partners, without duplicating business logic across tools.

## How BI-as-code works in practice

At the meetup in San Francisco, Mike fired up his laptop and walked through a live demo. "We were inspired by how easy it is to launch ClickHouse on your local machine," he said, noting that, like ClickHouse, Rill lets developers start a local instance that runs in the browser, connecting to either a local ClickHouse database or [ClickHouse Cloud](https://clickhouse.com/cloud).

The demo centered around three core building blocks inside Rill: sources, metrics, and dashboards. Mike began by loading roughly a million rows of Google Cloud usage data from a Parquet file. He then used an agent-assisted workflow to generate the YAML configuration needed to ingest the dataset into ClickHouse.

Once connected, Rill analyzed the table structure and generated metric definitions and dashboards automatically. Within seconds, he could explore cloud spending trends—drilling into services, zooming across time ranges, and slicing costs by dimension—all backed by ClickHouse queries. "What's great is how easy and fast it is," Mike says.

With Rill, developers can use AI-assisted coding tools to define configurations as code. In his demo, Mike used Cursor to generate ingestion syntax, adjust formatting, and modify dashboards. Tasks that once required extensive UI configuration, like changing currency formatting across dashboards, can be done in seconds. "That's the difference between BI-as-clicks and BI-as-code," he says.

As Mike explained, development happens locally first. Teams iterate against small data partitions, validate metrics, and commit changes to Git before deploying to the cloud. Once deployed, the same definitions power conversational analytics layered on top of the data.

Mike demonstrated this by asking natural-language questions about cost increases across cloud providers. While conversational BI, he notes, has become relatively common ("everyone's seen a demo of a chatbot slapped over some data"), he emphasized two constraints that determine whether it actually works in practice.

First, text-to-SQL approaches don't always scale in real production environments. "If you've got hundreds of tables, you just see the agent get lost," Mike says. "It's like throwing a data engineer at a problem and saying, 'Hey, figure out why our cloud costs are up.'"

Second, interaction speed matters as much as correctness. "You've got to have high performance in the back end," he says. "If you were to throw Rill at [Snowflake or Redshift or BigQuery](https://clickhouse.com/resources/engineering/top-5-cloud-data-warehouses), the answers would just take forever to come back."

At the end of the day, trust comes from traceability as much as intelligence. In Rill, each generated insight links back to the underlying dashboard and query results, allowing users to verify conclusions rather than treating AI responses as opaque outputs. "You've got to have trustworthy results," Mike says. "You've got to have verifiability."

## Analytics for a fully metered world

Imagine the workflow Mike described running continuously inside a real organization. Cloud billing exports land in object storage, operational data flows in from APIs, and declarative pipelines stream everything into ClickHouse, where aggregations happen in real time. Metrics defined once become dashboards automatically, and teams across product, operations, and finance explore the same underlying data through a shared analytical layer.

What once required a patchwork of ETL jobs, semantic layers, and dashboard tooling converges into a unified workflow, defined and maintained largely as code.

![](/uploads/Rill_User_Story_Issue_1250_1_59c5095254.png)

*FinOps in practice: declarative ingestion, real-time aggregation, and operational BI in Rill.*

Taken together, Rill and ClickHouse point toward a new model for analytics, built for a world where every business process generates events. Teams can stay on top of operations by querying live systems, iterating locally, and deploying analytical logic the same way they ship software.

As organizations become increasingly measured in real time, analytics shifts from retrospective reporting to operational decision-making. Declarative data movement, high-performance aggregation, and metrics-first design make it possible to treat analytics not as a separate destination, but as infrastructure running alongside the business itself.

large_Rill User Story Issue 1250.jpg

medium_Rill User Story Issue 1250.jpg

small_Rill User Story Issue 1250.jpg

thumbnail_Rill User Story Issue 1250.jpg

Rill User Story Issue 1250.jpg

Rill and ClickHouse: real-time operational BI for a metered world

[Padlet](https://padlet.com/) builds tools that help teachers turn lessons, prompts, and activities into something students can engage with directly. The product is inherently visual, designed to make classroom materials feel approachable rather than formal or rigid. It's all in service of a mission the company describes as "making software for a good education."

"We believe a good education is when kids learn to be curious and creative, and when they learn to collaborate," says Zoheb Jamal, Padlet's VP of Growth. "We want to make a product that teachers can use to make visually stunning content that kids find fun and engaging."

Today, Padlet is used in 242 of 246 countries worldwide. "There are still four holdouts," Zoheb jokes. "We're confident we're going to get them." As that reach expanded to tens of millions of unique users, the team began to see a growing gap between how teachers wanted to use classroom data and how analytics were being delivered.

Zoheb spoke at our [recent ClickHouse meetup in Singapore](https://clickhouse.com/jp/videos/singapore-meetup-padlet-25sep25), where he shared how Padlet used [ClickHouse Cloud](https://clickhouse.com/cloud) to build a real-time analytics stream, giving teachers immediate insight into how students are engaging, rather than waiting on delayed reports.

<iframe width="768" height="432" src="https://www.youtube.com/embed/vM_0B2LT8-4" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## Why real-time matters in the classroom

For teachers using Padlet in the classroom, questions naturally started to come up around engagement. Were students interacting with a lesson? Which activities were resonating? How long were students spending on a page? For a long time, getting answers meant writing to Padlet and waiting for someone to crunch the numbers and send back a snapshot.

"That's not great," Zoheb says. "Imagine you want to know how much money you have in your bank account, and you have to write an email to your bank and get a number back two days later. That's the kind of poor experience we wanted to fix."

So the team focused on giving teachers access to a small set of core metrics on demand. The goal was less about advanced reporting and complex dashboards, and more about letting teachers see what was happening as lessons unfolded.

At Padlet's scale, however, delivering that experience came with real technical constraints. The product serves around 40 million unique monthly users, generating billions of events. "If the event volume was any lower, we could have just used a simple solution like Postgres," Zoheb says. "That's probably the only time I wish we had fewer users."

There was a clear gap between what teachers needed and what Padlet's existing stack was built to support. "What we needed was a more robust solution," Zoheb says.

## What Padlet needed from an analytics system

As they kicked off their search for a new database, Padlet put together a simple rubric covering both functional and non-functional requirements.

On the functional side, real-time was non-negotiable. "If a teacher is doing an activity in the classroom, we want them to get numbers then and there, not a day later," Zoheb says.

Speed mattered just as much. "By fast, I mean you click and get results," Zoheb says. Performance, he explains, is a core focus across the product, with a "dedicated speed team" whose sole job is to keep Padlet fast. "There was no way I could have shipped a slow analytics service under the radar," he jokes.

Operationally, the bar was just as high. With a team of around 65 people and no dedicated data team, Padlet wanted something that would largely run on autopilot. "We didn't want to maintain servers, we didn't want to do patches, we didn't want to manage pipelines," Zoheb says. "We just wanted to set up a solution and then let it run."

Cost was another factor. Padlet wasn't looking for the cheapest possible option, but they did want something that would remain affordable as usage grew. As Zoheb puts it, "We wanted something sustainable, which we could use today and continue to afford in the future."

Finally, longevity mattered. The team had been burned before by analytics and BI tools that were abandoned or shut down after an acquisition. "We needed something that would at least last us through the 21st century," Zoheb says. "So just 70 to 80 more years."

## Why Padlet chose ClickHouse Cloud

Over the course of a few weeks, the team ran a series of POCs to see which options could deliver. In the end, Zoheb says, "ClickHouse ticked all the boxes."

Ingestion speed stood out first. ClickHouse delivered "crazy-fast ingestion," making it possible to support live classroom use cases without lag or batching delays. "That's what you need for real-time—the ability to ingest all those events very quickly," Zoheb says.

Query performance was another plus. The team was drawn to ClickHouse's specialized engines like [MergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree) and [AggregatingMergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/aggregatingmergetree), which store data compactly and prune aggressively at query time, so only a small subset of data needs to be loaded into memory. Strong support for [materialized views](https://clickhouse.com/docs/materialized-views) added what Zoheb calls a "further boost in our performance."

Running infrastructure in-house was never the plan, so Padlet chose [ClickHouse Cloud](https://clickhouse.com/cloud). "It's been running on autopilot for the past year," Zoheb says. When the team did encounter an early issue tied to [partitioning](https://clickhouse.com/docs/partitions), it was identified and resolved quickly. "That's the kind of turnkey solution we're looking for, and that's what we got with ClickHouse."

The managed service is reasonably priced, Zoheb adds, and getting started was straightforward. "When we wanted to try it, we didn't have to talk to a sales team," he says.

ClickHouse's maturity sealed their decision. Open-sourced more than a decade ago, the database is now used by many of the world's largest companies for [real-time analytics](https://clickhouse.com/resources/engineering/what-is-real-time-analytics). As Zoheb puts it, "That gave us confidence we can continue to use this product for a while—if we do the implementation right."

## Padlet's ClickHouse-based analytics pipeline

With ClickHouse Cloud in place, Padlet got to work wiring up its real-time pipeline. Rather than starting from scratch, the team built on top of their existing event infrastructure, extending it where needed and keeping the overall design simple.

Padlet already tracked core interactions like page views and visits, but engagement time required a different approach. Instead of relying on complex client-side logic to infer whether a student was actively engaging with a page, they opted for a simpler, more reliable model based on "heartbeat" events. Every 30 seconds, an active session emits a small event, with each event representing a fixed slice of engagement time.

Those engagement events are ingested into ClickHouse using [ClickPipes](https://clickhouse.com/cloud/clickpipes), ClickHouse's native ingestion service. The team chose ClickPipes to avoid standing up and maintaining additional infrastructure, and to keep ingestion simple. "It was easy to set up and quite cost-effective," Zoheb says. Existing view and visitor events continue to flow through Padlet's internal event pipeline, with both streams converging in ClickHouse for analysis.

![](/uploads/Padlet_User_Story_Issue_1249_86a2a47bad.png)

*Padlet's event pipeline feeding ClickHouse for views, engagement time, and unique visitors.*

Once the data lands in ClickHouse, Padlet relies on materialized views to keep queries fast and predictable. Views and engagement time are pre-aggregated by date, while unique visitors rely on [HyperLogLog](https://clickhouse.com/docs/sql-reference/aggregate-functions/reference/uniqcombined) sketches for efficient aggregation across time ranges. "We didn't do any fancy maths," Zoheb says. "ClickHouse has this natively available, so using it was a breeze."

From initial setup to production, the entire pipeline came together in about a month. "We're fortunate to have a great engineering team, and we also got a very solid product in ClickHouse," Zoheb says. "That's how we were able to move so quickly."

## Blazing-fast and built for what's next

Ultimately, Padlet's goal wasn't to build a sprawling analytics system, but something fast, reliable, scalable, and easy to operate. The results speak for themselves.

As Zoheb shared at the [Singapore meetup](https://clickhouse.com/jp/videos/singapore-meetup-padlet-25sep25), Padlet ingested roughly 8 billion events into ClickHouse in a single month. The system now supports around 14 requests per second (up from their original goal of 10) with a median query latency of 45 milliseconds and a P99 response time of 690 milliseconds. For teachers, engagement data feels like a natural extension of the lesson itself, not something that arrives after the moment has passed. "When someone clicks it, they're going to see results immediately," Zoheb says.

Looking ahead, Padlet plans to expand its analytics well beyond this first version. As new features and AI-driven tools roll out across the product, teachers are asking for deeper insight into how those features are being used and how students are interacting with them. "We intend to use ClickHouse to power pretty much all of these use cases," Zoheb says.

With ClickHouse Cloud, what began as a way to surface a few core metrics has grown into a real-time analytics layer that remains lightweight enough for a small team to operate. As Padlet continues to grow, ClickHouse is set to remain a central part of how the company—and the teachers who rely on it every day—understand and improve learning in the moment.


Padlet uses ClickHouse Cloud to deliver real-time classroom analytics at scale, supporting billions of events per month with sub-second queries and no dedicated data team.

large_Padlet User Story Issue 1249.jpg

medium_Padlet User Story Issue 1249.jpg

small_Padlet User Story Issue 1249.jpg

thumbnail_Padlet User Story Issue 1249.jpg

Padlet User Story Issue 1249.jpg

How Padlet uses ClickHouse Cloud to power real-time classroom analytics

Cogent Security uses ClickHouse to serve billions of security findings at sub-second speeds, powering an AI-native vulnerability management platform. Migrating from Postgres to ClickHouse reduced P90 query latency from 5 seconds to less than 1 second at 100 million rows, without caching. Cogent's Chart Agent went from 40% to 94% accuracy by combining an agentic loop architecture with ClickHouse projections.

As AI makes it faster and easier to exploit software vulnerabilities, enterprise security teams are falling behind, hamstrung by point solutions that are often hard to deploy and clunky to use.

"Our goal is to make sure enterprises are able to keep up as the threat landscape changes rapidly with AI," says [Cogent Security](https://www.cogent.com/) founding engineer Karan Gugle.

Just six months since the platform's launch, Karan says two things are already clear: enterprises are understaffed and dealing with millions or even hundreds of millions of findings; and the road to actually remediating these findings requires a huge amount of organizational context and a deep understanding of the systems on which they were found.

"Users need to filter through their findings, ask questions about their data, and start remediating their risk—all actions that need to feel instant, accurate, and magical on Cogent's platform to really stand out," Karan says. "This applies even more to agents, who crunch massive amounts of data for users who may be hunting for the latest threats in their environment, generating compliance reports, or remediating a vulnerability on their most critical assets."

At a March 2026 ClickHouse meetup in San Francisco, Karan and machine learning engineer Sagar Maheshwari shared how Cogent built its data platform on ClickHouse, and what that unlocks for agentic vulnerability management.

## The growing threat gap

The vulnerability management problem is getting measurably worse. The National Vulnerability Database currently tracks over 320,000 CVEs, a figure that has grown fivefold in just the last decade. And with the rise of LLM-powered toolkits, the threat is accelerating in a new way.

"The floor of knowledge required to try to exploit has gone from a seasoned systems engineer to anyone with intent and access to a coding agent," Karan says.

The numbers bear this out. In 2018, the mean time-to-exploit (TTE)—the window between a vulnerability being disclosed and being actively exploited—was around 2.3 years. In 2026, that number has collapsed to just 1.6 days.

![](/uploads/cogentsecurity_mar2026_image1_dcb11c08b5.png)

*Since 2018, mean time-to-exploit (TTE) has dropped from 2.3 years to 1.6 days.*

On the defender side, security teams are chronically understaffed, while the "scan → contextualize → prioritize → remediate" loop is slow, manual, and full of friction. Most teams are nowhere near meeting their own internal SLAs, and 50% of the most critical vulnerabilities remain unresolved after two months. "That's a pretty scary reality," Karan says.

Once a vulnerability is found, remediation—communicating to engineering why it matters and finding the right owners to actually fix it—is, as Karan puts it, like "walking a tightrope," an organizational and process challenge as much as a technical one.

"Everything in this loop needs to be done at machine speed to counter AI-enabled attackers," he says. "That's exactly what we're trying to solve."

## Security data at scale

Fortune 500 customers can generate more than 10 billion data points in just 90 days, with up to 100 million changelog events per day. To serve that data reliably across charts, filters, agent queries, and backend APIs, Cogent gives each customer their own [ClickHouse](https://clickhouse.com/resources/engineering/what-is-columnar-database) database with over 100 tables optimized for different product surfaces.

Data arrives from over 50 sources, including cloud providers, vulnerability scanners, and business tools like Slack, Confluence, and Jira. Because these sources are disconnected, Cogent's platform first performs entity resolution, finding the right join keys between a customer's data sources to produce a unified view of their environment. The result is a Knowledge Graph that enables graph-like traversals across the data.

From there, dbt projects denormalized tables into [Iceberg](https://clickhouse.com/resources/engineering/apache-iceberg)—pre-joined, pre-aggregated views of the Knowledge Graph. Those projections are then loaded into ClickHouse via the [ClickHouse Spark Connector](https://clickhouse.com/docs/integrations/apache-spark/spark-native-connector), which provides cheap, tunable, and highly scalable compute for the load path. All table schema and layout decisions are defined using the ClickHouse dbt library.

![](/uploads/cogentsecurity_mar2026_image2_5f4b32e866.png)

*Cogent's data pipeline, from ingestion through to the ClickHouse-powered serving layer.*

"This is great because we can co-locate the Iceberg dbt transformation pipelines with the ClickHouse optimizations we need," Karan explains. "For example, setting up the right indexes, ClickHouse projections, compression types, and so on." The result is a clean hot/cold [data lakehouse](https://clickhouse.com/resources/engineering/data-lakehouse) architecture with Iceberg on S3 as the source of truth, and ClickHouse as the serving engine.

## Designing for speed

Before presenting results, Karan shared the five design principles that underpin Cogent's approach to making reads fast at scale.

The first is query-driven design. "This is probably the single biggest mindset shift coming from a traditional relational world," he says. "You don't start with your entity model. You start with the queries your product needs to run, and you design your tables backwards from there."

The second principle is to [denormalize everything](https://clickhouse.com/docs/data-modeling/denormalization). Cogent's dbt projections pre-join and pre-aggregate data before it reaches ClickHouse, eliminating expensive JOIN operations at query time.

Third is the use of [projections](https://clickhouse.com/docs/sql-reference/statements/alter/projection) and [indexes](https://clickhouse.com/docs/primary-indexes). "This is one of ClickHouse's superpowers," Karan says. "You're essentially trading minor insert amplification and additional storage for dramatically better filter performance." Every projection is an additional physical sort order on the same data, enabling completely different query patterns to be served from a single table.

Fourth is choosing the right [compression codec](https://clickhouse.com/docs/data-compression/compression-in-clickhouse) for each column type—Delta for timestamps, LZ4 for strings, ZSTD for cold data—to reduce read I/O and storage footprint.

Finally, [benchmark everything](https://clickhouse.com/resources/engineering/clickhouse-query-optimisation-definitive-guide). "[system.query_log](https://clickhouse.com/docs/operations/system-tables/query_log) is your friend," Karan says.

## Sub-second performance

The gap between Cogent's old Postgres-based setup and where they are now shows what the right infrastructure can do for a product where speed is a massive differentiator.

"I want to underscore how important this is—not just as a benchmark exercise, but to our product and customers," Karan says. "Security tools routinely crumble under this kind of load. When you're a security engineer trying to triage millions of findings across your org, the last thing you need is a 25-second page load."

|  | P50 | P90 | P99 |
| :---- | :---- | :---- | :---- |
| Postgres | 2 seconds | 5 seconds | 25 seconds |
| ClickHouse (100M rows) | 0.3 seconds | 0.9 seconds | 2.5 seconds |
| ClickHouse (500M rows) | 0.6 seconds | 1.8 seconds | 4.2 seconds |
| Goal | 0.5s | 1s | 3s |

Today, 98.7% of queries complete in under three seconds at 100 million rows, while 86.3% do so at 500 million rows. And as Karan adds, "That's without any sort of backend or even database-level caching."

## Making reporting conversational

With the infra story told, Sagar took the mic to walk through what Cogent built on top of it.

"Almost every customer we work with needs charts and dashboards to monitor current and historical risk posture," he says, "whether it's for GRC, board presentations, SLA tracking, day-to-day observability, you name it." Traditionally, meeting those needs has meant exporting CSVs from data silos, manually configuring BI tools, and scrambling to pull data together before meetings. That's days of analyst time for what should be a quick answer.

Cogent's approach is to make reporting conversational. Their Chart Agent takes a natural language request and generates the ClickHouse SQL needed to render a chart, querying Change Data Capture logs in [real time](https://clickhouse.com/resources/engineering/what-is-real-time-analytics). "If you can say what you want, we can create the chart," Sagar says. "Overall, we want reporting to be possible in seconds, not days, all without sacrificing accuracy."

The first version used a single-shot approach—stuff all context into the system prompt, send the user request, and, as Sagar puts it, "pray we get the right SQL back." On a golden dataset of around 100 text-to-SQL examples, this achieved 40% accuracy. The failure modes were clear: without the ability to run queries to validate its assumptions, the LLM "confidently writes incorrect SQL" and also gets distracted by irrelevant context.

The solution was an agentic loop with three key components: agentic RAG to search the data model and pull relevant context on demand; a live SQL execution tool to run queries directly against ClickHouse and see actual data; and interleaved thinking to reason between tool calls rather than planning everything upfront and becoming obstinate when intermediate results suggested a different approach. The result: 94% accuracy on the same dataset where single-shot got 40%.

## Iterating toward accuracy

Since the Chart Agent's SQL is non-deterministic, evaluation is tricky but not impossible. Cogent uses two complementary evaluation approaches. Trace evaluations use an LLM-as-a-judge to assess whether the agent behaved correctly—pulling relevant schemas, running intermediate queries, validating SQL.

SQL output validation is the harder eval. Given the same dataset, it checks whether the agent's generated SQL produces the same data output as the expected SQL. Cogent evaluates data output equality rather than SQL string equivalence, using a small language model to map expected columns to generated columns. And each test case runs three times with majority voting. "It's not enough to get it right once," Sagar says. "It needs to be consistent."

When it came time to iterate, adding tools to dynamically explore the data model and run queries—the first agentic version—pushed accuracy to 58%. A curated query bank of golden SQL patterns brought it to 75%, freeing the agent to anchor on proven patterns rather than devising query logic from scratch. A tenant memory bank, letting the agent reference lessons from past runs, took it to 82%.

The most notable jump came not from changes to the agent, but from the data. "Rather than force the agent to construct these from scratch each time, we created pre-computed aggregations in ClickHouse, which we call projections," Sagar explains. "Just by simplifying the queries the agent had to write, we saw the accuracy jump to 94%."

## One source of truth

Underpinning all of this is a piece of infrastructure Cogent built in-house: the Ontology Service.

"When the data model changes, the agent hits a 'WTF' moment because it's confused by discrepancies between its context and the actual data," Sagar says. The Ontology Service solves this by co-locating the data model and its semantics—descriptions, enums, relationships—directly with the physical schema. As Sagar puts it, "One source of truth, no drift."

Enterprise security adds another layer of complexity. "Customers always have unique environments," Sagar explains. "Without an ontology service, the agent has a really tough time trying to understand custom fields and their semantics." Per-tenant overlays in the Ontology Service ensure agents automatically see each customer's full effective schema.

"Making the data model agent-friendly is a new paradigm," Sagar says, "that I think will shift how the industry thinks about data modeling going forward."

## A virtuous cycle

"The key thing that ClickHouse unlocks for AI is speed," Karan says.

At Cogent, that speed propagates benefits at every level. Sub-second queries enable iterative agentic loops that simply don't work if the database can't keep up. Low latency per query compounds across an entire agent run. And fast eval loops let the team ship improvements to customers faster; running 100 data output comparisons, each with three-run majority voting, needs a database that doesn't turn iteration into a slog.

The virtuous cycle Cogent has found is straightforward: a fast database enables more tool calls, more tool calls produce better accuracy, and better accuracy unlocks more sophisticated agentic patterns. For a company racing to help enterprises keep up with AI-accelerated attackers, that cycle is the foundation everything else is built on.


"The key thing that ClickHouse unlocks for AI is speed. Everything we do needs to be done at machine speed to counter AI-enabled attackers.”  Karan Gugle, Founding Engineer

ClickHouse

Blog posts by ClickHouse

Mintlify boosts NPS 30% and saves 60% with real-time analytics on ClickHouse Cloud

How Eisan made POS analytics faster, cheaper, and more reliable with ClickHouse Cloud

How Respan is scaling LLM observability with ClickHouse Cloud

Rill and ClickHouse: real-time operational BI for a metered world

How Padlet uses ClickHouse Cloud to power real-time classroom analytics

Intelligent security at ClickHouse speed: How Cogent Security built an AI-native vulnerability management platform