The Brains

A database engine does not get from a Yandex internal tool to a company with a product line around it by accident. This chapter looks at the people and the habits behind that path: who built it, what the engineering culture looks like from the outside (where it can be checked, because the repository, the benchmark and the issue tracker are all public), how the company was founded and funded, and why its acquisitions follow a pattern. Chapter 1 (The Product) covers what the engine is; this one is about who kept making decisions about it, and what they did with the money.

A note on method. Everything below is either from a primary source (the company’s own announcements, the GitHub repository and API, the project documentation) or from a named press report, and each fact carries its link. Where a number is a measurement I took, the date is stated, because these numbers move daily.

The people

ClickHouse began at Yandex. The project’s own history page dates the start of the work to 2009, inside Yandex.Metrica, with the goal of generating analytical reports in real time from non-aggregated data that itself grows in real time; it went into production for Metrica in 2012, and became an Apache 2.0 open-source project in 2016. The GitHub repository agrees with that last date: ClickHouse/ClickHouse was created on 2016-06-02 and is licensed Apache-2.0.

The person most associated with it is Alexey Milovidov. When the company was incorporated in 2021, the announcement named him as creator and CTO, next to Aaron Katz as CEO and Yury Izrailevsky for product and engineering. The same post states why the team left Yandex’s structure at all: Milovidov wrote that ClickHouse’s potential “highly outgrows” the small team of about fifteen people that had been working on it at Yandex, and that combining the core developers with business and cloud engineering talent was how it would reach customers beyond the technically sophisticated ones. Yandex stayed on as an investor.

Public evidence says the founding engineer never stopped being a working engineer, which is unusual for a CTO of a company this size. On 2026-10-14 the GitHub contributors endpoint for the main repository (gh api repos/ClickHouse/ClickHouse/contributors) listed alexey-milovidov first, with 73,023 contributions, against a repository total of 305,247 commits (the commit count is read from the pagination of the commits endpoint). That is roughly a quarter of the project’s entire history under one account. The endpoint lists 312 accounts in total, and I would treat that number as a floor rather than a headcount: it counts only commits that GitHub can attribute to an account. The distribution is the point, not the total. Behind the founder, the next few accounts hold roughly 7,000 to 9,000 contributions each, and the rest taper into a long tail.

The tracker shows how that plays out day to day. The same account that commits to the engine also answers feature requests, often within hours, and sometimes in one line. I will come back to that below, because it is the most direct window on how decisions get made.

The same repository, measured

Taken on 2026-10-14 from the GitHub API:

About 3,500 merged changes in a single month is over a hundred a day, each gated by CI.

Engineering culture, visible from outside

Four habits show in public. None of them is a slogan; each leaves an artifact you can inspect.

Benchmarks come first

The most telling artifact is ClickBench, a benchmark for analytical databases published by the ClickHouse organisation in 2022 (the repository was created on 2022-07-11). Its README states its own limits unusually plainly. It lists reproducibility, compatibility, diversity and realism as goals; the dataset is derived from the traffic of a real web-analytics platform, anonymised; the workload is 43 queries; and the run is a documented shell script per system that any participant can re-run “in as little as 20 minutes”. Among the stated limitations: the dataset is a single flat table, so it favours systems that do well on that shape, and the README says classical data warehouses may be at an unfair disadvantage because of that.

A vendor publishing a benchmark is an obvious conflict of interest, and the design of ClickBench reads like a response to it: open scripts, other systems welcome, limitations written down. Performance is treated as a feature with its own regression tests: the CI documentation describes a performance check on pull requests that measures query-performance changes and is “the longest check”, taking just under six hours.

Public, heavy CI

The same CI page lists what runs on a pull request after a maintainer applies the can be tested label: builds for several architectures (AMD64, ARM64, PowerPC, RISC-V among them) in debug, release and sanitizer configurations; stateless, integration and stress tests; an AST fuzzer that runs randomly generated queries; address, thread, memory and undefined-behaviour sanitizers; and a check against older libc versions. Results appear as status checks on the PR. For anyone who has run a database in production, this is the real answer to “why does it rarely lose data”: a large amount of the engineering effort goes into trying to break it before users do.

A monthly release train

Release cadence is the habit most visible to operators. From the repository’s releases (gh api repos/ClickHouse/ClickHouse/releases, read on 2026-10-14), the first stable tag of each version carried these dates:

Nine versions in nine months of 2026, with a few weeks of slippage in the middle (26.4 landed in early May and 26.5 only sixteen days after it). The repository README also lists a recorded community release call for each version, for instance the 26.9 call on September 17, 2026. The pattern repeats the previous year: the same listing shows 25.1 on 2025-01-28, 25.2 on 2025-02-28, 25.3 (LTS) on 2025-03-20, and so on without a gap. The consequence for operators is real and double-edged: features reach users fast, and the cost of staying current is that every month’s release notes carry a section on backward-incompatible changes. The site’s own write-up of that tension is the upgrade-guard request, discussed below.

An issue tracker that answers

The last habit is how requests are handled. This site has written up 47 feature requests filed against the ClickHouse repository by its author over the years, each with the GitHub link and the outcome. Counting the status field of those posts: 18 implemented, 3 partially implemented, 19 still open, 3 declined and 4 superseded (the feature already existed or arrived by another route). The point is not the ratio, which reflects the author’s taste more than the project; it is the pattern in how maintainers respond. Five threads, all public, show it well.

A one-line decline, with a reason. The upgrade-guard RFC (#97500) proposed that a server remember which versions had touched its data and hold back risky on-disk format changes until an operator allowed them. It was opened on 2026-02-20 and closed about eight hours later. A contributor pointed out that setting changes are already recorded in system.settings_changes and that the compatibility setting exists for safer upgrades; Milovidov then closed the issue with a single sentence: “We use the compatibility setting - it works well.” That is a decline in under a working day, and it is a fair one, because the project did have a mechanism for the common case. It is also characteristic: a general preference for the simplest thing that works over a new subsystem with its own registry to maintain.

A decline that points at the real gap. Native UPSERT on MergeTree (#86779), filed on 2025-09-06, drew an answer the same evening: “While it’s possible to implement upserts using lightweight updates, it is not going to be efficient. It requires another mechanism”, with a link to a still-open RFC for a unique-key constraint (#70589, created 2024-10-11). The reasoning is engineering, not policy: an upsert needs an existence check for every incoming row, and a table with a sparse primary index and immutable parts is built to avoid exactly that. The useful thing for the person asking was to learn which missing mechanism actually blocks the feature.

A “no, for now” with alternatives. An enhanced LIMIT (#40965) got a careful reply the day after it was filed: the parenthesised form was “too ambiguous” because it looks like a table function; a second LIMIT was “too surprising”; the maintainer suggested other spellings and concluded he would postpone the work until more motivation appeared. It sat for two and a half years and was closed in February 2025 after another user pointed out that a parameterised view already covers part of the case.

An accepted request that took three years. REPLACE TABLE (#1102) was opened on 2017-08-15. The next day the maintainer wrote that a family of related statements was planned, with a caveat for replicated tables. In May 2020 he noted that it could now be built on the atomic database engine and that a colleague was ready to take it; the issue closed on 2020-12-27 with the merge of PR #18521. The slowness is real, but so is the paper trail: the request, the design constraint, the dependency that unblocked it and the implementation are all linked from one thread.

Closing as expected behaviour. In #87468, the request noted that system.query_log records the old setting name allow_experimental_analyzer when a query runs with the newer enable_analyzer. A maintainer closed it ten days later: enable_analyzer is an alias for the original and the original name is what is recorded. It is a small case, written up with the other small ones in a roundup post, but it shows a project that closes things instead of leaving them to rot, and that is willing to say “expected”.

There is also the opposite pole, and it is worth being honest about it. Some threads get nothing for years (the LIVE VIEW request had no comments and was closed in 2022 without an implementation; the feature itself was removed in 25.11), and some get a maintainer answer that is a design objection rather than a roadmap (for instance the discussion around grants for user-defined functions, where a maintainer noted on the day it was opened that ClickHouse has no object owners). A direct, fast, sometimes terse answer is the usual shape. Whether that reads as efficient or abrupt depends on what you wanted from the thread.

Taken together these threads say something specific about the culture: decisions are made in the open, by people who write the code, quickly, and with a bias towards reusing an existing mechanism. The cost is that big cross-cutting proposals struggle. The benefit is that you rarely wait long to learn where you stand.

ClickHouse, Inc.

Founding (2021)

Until September 2021 ClickHouse was an open-source project with a Yandex-sponsored team. The company announced itself on 2021-09-20: ClickHouse, Inc., with nearly $50 million of Series A funding led by Index Ventures and Benchmark, with Yandex N.V. participating. The founders listed are Milovidov, Izrailevsky and Katz. Yandex published its own announcement the same day describing the spin-off. The Business Wire release is here.

Funding rounds

Three details are worth noting. The Series B arrived five weeks after the Series A and, in the company’s own words, came with a plan to “double our team this year, and double it again next year”; the same post says the service processed “100+ PBs of data with more than 100 billion records inserted every day”. Those are claims made at the time by the company, and I am citing them as claims. Second, the Series B extension coincided with the first public launch of ClickHouse Cloud: the 2022-12-06 post introduces the cloud service and the extension in the same announcement. A managed cloud service is the commercial centre of the company, and the order matters; the paid product came after the community had already adopted the open-source engine. Third, the valuations are separately sourced because the company’s own posts do not state them for the later rounds: the Series C figure is Bloomberg’s, the Series D figure is TechCrunch’s, and I have kept them in the link column for that reason.

The most recent public numbers come from a TechCrunch article dated 2026-05-27: an annualized revenue run rate of $250 million, tripled from the previous year; more than 4,000 customers; a CFO, Jimmy Sexton, hired in autumn 2025 from Snowflake; and Izrailevsky saying the company is “positioning for an IPO within the next few years”. The same article says six startups had been acquired by then, and that more are planned, of “relatively young, but showing very promising technology” companies. Those are the press’s figures of a company that is not yet public, so treat them accordingly. The six at that date match the first six rows of the next section exactly.

Leadership

As announced in 2021, Aaron Katz is CEO, Alexey Milovidov CTO and Yury Izrailevsky President of Product and Technology (TechCrunch uses the same title for Izrailevsky in 2026, and the Series D release quotes Katz as CEO). I am claiming nothing more about the organisation chart than those sources say.

Acquisitions as a strategy

Every row below is checked against the company’s own announcement; dates are the dates of those posts. All seven candidates from the earlier research list checked out.

Two caveats. The Arctype post is dated by the announcement of the cloud launch (2022-12-06); other secondary sources describe the deal as having happened in October 2022, and I have not found a company post that dates it earlier, so the table gives the date of the primary-source statement rather than the date the deal closed. And no row has a disclosed price: none of the announcements states terms, and I have not seen terms published for any of them.

What each one added

Arctype (2022). Cloud needed a place to type SQL. The cloud launch post says that, following the acquisition of the database client Arctype, users would get “a new SQL console that will enable them to connect, explore, and query their databases easily”. That is a team and a product bought to supply a missing front door to a managed service: the engine was there, the interface was not.

chDB (2024). The most interesting of the early ones, because chDB did not come from a company at all. It is an embedded SQL engine you load as a library inside another process (Python first), and its creator was an individual, working on it in his spare time. The announcement says he now works on it full time and that chDB would be integrated into ClickHouse’s continuous integration, aligned with the release schedule and documented on the main documentation site. This is the same logic as the rest, applied one level lower: rather than leave an in-process use of the engine to someone else, bring the project and its author in. The effect for users is that “ClickHouse inside my notebook or my application” is now a supported deployment shape, not a fork.

PeerDB (2024). Most analytical workloads start with data in a transactional database, and for a large share of users that database is Postgres. The announcement says ClickHouse needed a performant Postgres CDC solution for ClickPipes and that PeerDB’s approach (fast snapshots, reliable replication, minimal impact on the source system) matched what it wanted. It also states that PeerDB Enterprise was released under the ELv2 licence, and that PeerDB Cloud continued for non-ClickHouse users with a one-year transition window. The company’s later year-in-review post on Postgres CDC is the place to see what came of it.

HyperDX (2025). The announcement is candid about the gap: ClickHouse was already a popular database for logs, metrics and traces, but lacked a front-end experience. HyperDX supplied the interface, session replay and OpenTelemetry integration, and the project and its cloud stayed available. The buying pattern is the point: the engine did the hard part, and the acquisition added the part people look at.

LibreChat (2025). A different kind of purchase: a chat interface for LLMs, not a database tool. The announcement frames it as the user-experience layer for what it calls the “open-source Agentic Data Stack”, in which analytics agents sit on top of large datasets in ClickHouse. It quotes a Shopify engineer describing internal adoption, and states that LibreChat remains MIT-licensed. The announcement states the intent; it cannot show the outcome.

Langfuse (2026). The company announced Langfuse together with the Series D. Langfuse was already built on ClickHouse, which the post gives as a reason: it is a category-leading open-source project, running on the engine, in a field (LLM observability, evaluations, prompt management) where, in the words of its CEO Marc Klingen, quoted in the funding release, observability “is fundamentally a data problem”. The post reports more than 20,000 GitHub stars and states the MIT licence is unchanged.

RunReveal (2026). The newest one, announced on 2026-09-01. The post calls security “the largest and fastest growing data workload in the enterprise”, describes RunReveal as a security data platform built on ClickHouse (cloud audit logs, identity events, endpoint telemetry, network flows), and says the model stays bring-your-own-database, with the customer’s security data living in a ClickHouse cluster the customer controls. The stated reason is internal as much as commercial: in-house security expertise should improve reference architectures, schema guidance and roadmap input for the companies building security products on ClickHouse, which the post says will remain a neutral base for others.

The shape of the strategy

Put the dates in order and the direction is clear.

1. Ingest (2022 to 2024). Arctype gave Cloud a console; PeerDB gave it a way in from Postgres. These are the on-ramps.
2. Engine reach (2024). chDB took the engine out of the server and into the process.
3. Observability (2025). HyperDX added the UI that turns a log-and-metric store into a product.
4. LLM operations (2025 to 2026). LibreChat is the interface for agents; Langfuse is the tracing and evaluation layer for the applications built on them.
5. Security (2026). RunReveal applies the same “complete product on the engine” idea to a third large workload.

The uniform pattern is that the acquired thing sits next to the engine rather than inside it. In three of the seven cases the announcement says the product was already built on ClickHouse (HyperDX, Langfuse and RunReveal); chDB is the engine itself, embedded. The company is not buying a different technology and bolting it on; it is buying the layer above or beside the engine that users have to otherwise build or evaluate for themselves, and in each case it states that the open-source licence stays.

Three consequences follow, and they are the practical reasons to care.

First, the engine’s customers become the target market of its own products. A team that runs ClickHouse for logs can be sold an observability product on the same cluster. The same team’s LLM application can send traces to Langfuse, which stores them in ClickHouse. Each product increases the volume of data stored in the engine; the engine is the revenue meter, and the products are the reasons to fill it. That is consistent with the TechCrunch description of a business whose revenue comes from managed cloud services around an open-source database.

Second, the licence promises matter, and they are the part to watch. Every announcement above says the acquired project stays open source (MIT for LibreChat and Langfuse, the existing open-source projects for HyperDX and chDB, ELv2 for PeerDB Enterprise, which is source-available but not an OSI open-source licence). The honest reading is that these are statements of intent at the time of the deal; the useful practice is to check the licence file on the day you adopt each component, not to rely on the blog post from the day it was bought. I have not checked the current licence of each repository for this chapter, and the reader should.

Third, there is a neutrality question. RunReveal’s announcement says ClickHouse will remain a neutral base for other security vendors. HyperDX, Langfuse and LibreChat make the same kind of point about open-source availability. The risk with owning both the engine and products on top of it is that the engine’s roadmap favours the products, or that competitors of those products decline to build on it. Nothing in the sources shows that has happened; it is the structural tension to keep an eye on, and the same tension every database company that moves up the stack has had.

What the culture and the strategy have in common

The two halves of this chapter look unrelated: a terse maintainer closing an RFC in eight hours, and a company buying a security startup. They share a rule. In both, the instinct is to take the thing that already works and extend it, not to invent a new subsystem. compatibility instead of an upgrade guard. A unique-key mechanism as the prerequisite for UPSERT instead of a fast but inefficient shortcut. Buying a UI for the observability stack instead of building a second database. A project built to answer a web-analytics report in real time ended up as a company whose products are all, in some sense, “a report on a lot of data, fast”, and whose habit is to prove it publicly with a benchmark and a CI board.

The next chapter, Artificial Intelligence, picks up the LibreChat and Langfuse threads and asks what the engine itself has gained for AI workloads.

Sources

Primary: the ClickHouse, Inc. announcement, the Yandex announcement, the company posts for the Series B, Cloud and the Series B extension, Series C and Series D, the acquisition posts linked in the table, the project history and CI documentation, the ClickHouse and ClickBench repositories and the GitHub issues linked above. Press: Bloomberg and TechCrunch. GitHub figures were read through the API on 2026-10-14.