ClickHouse’s most revealing signal is not its 50,220 GitHub stars. It is the gap between 11,012 commits in the last 30 days and zero recorded release events in the same window. ToolVitals also counts 30 GitHub releases in 90 days and 37 active contributors. The defensible thesis is that ClickHouse is in a high-output, release-managed phase: a lot is happening in public code, while the public release surface is selective.

For an engineering lead, release interpretation matters as much as release count.

A lot of engineering, not constant public releases

The ToolVitals fields are clear, but they need to be read separately. github_commits_30d is 11,012, github_releases_90d is 30, and release_events_30d is 0. Thirty releases over 90 days can coexist with zero release events in the latest 30-day interval because the measurement windows do not cover the same period.

The zero does not mean that ClickHouse stopped changing. It means ToolVitals recorded no event matching its 30-day release measure. That distinction matters for a database project, where changes may move through long-lived branches, maintenance channels, and staged release processes before users receive them.

The recent event list shows four release tags dated August 20 and 21, 2026: v25.8.32.4-lts, v25.8.31.9-lts, v26.3.20.7-lts, and v26.7.5.10-stable. The supplied v25.8.32.4-lts release page and v26.7.5.10-stable release page expose the release titles, but their supplied excerpts do not include detailed notes.

That supports a narrow conclusion: ClickHouse publishes multiple release lines, including LTS and stable channels. It does not support a feature-by-feature judgment about those releases. The GitHub repository also points readers to monthly release and community calls, including calls for versions 26.7, 26.8, and 26.9. The project therefore presents a cadence built around recurring release communication, even if the ToolVitals event counter shows no release activity in its most recent 30-day window.

What ClickHouse says it is building

The official ClickHouse website describes the product as a fast, open-source, column-oriented database management system for real-time analytical reports using SQL. Its examples focus on billions of rows, millisecond query results, logs, metrics, traces, machine learning, vector search, and applications that need real-time analysis.

The site explains the core design in familiar OLAP terms. Data is stored by column rather than by row, compression reduces storage and query work, and vectorized execution uses available CPU resources for analytical queries. The site also presents ClickHouse as something that can run locally or in the cloud, query files such as CSV, TSV, and Parquet without a server, and connect to common clients and data tools.

The repository uses a shorter description: ClickHouse is a real-time analytics database management system. It links to installation instructions, a cluster tutorial, documentation, ClickHouse Cloud, community channels, and release material. That combination says more than the marketing homepage alone. The project is positioned as software users can run themselves, with a managed service and a substantial operational and community layer around it.

ToolVitals classifies ClickHouse as OSI-approved open-source software and lists Apache-2.0 as the license. That is different from an open-core classification. The license signal makes self-hosted use and direct inspection part of the product’s public identity, but it says nothing by itself about operational effort, support quality, or whether a particular workload belongs on ClickHouse.

The product surface has also widened. The homepage highlights ClickStack, an open-source observability stack powered by ClickHouse, a public beta of ClickHouse Managed Postgres, vector search, GenAI workloads, and Langfuse as part of the ClickHouse offering. This is a broader direction than a single-purpose analytical database, but breadth should not be mistaken for equal maturity across every product area.

The recent direction is visible in the details

The August 2026 newsletter provides the clearest first-party view of recent engineering priorities. It describes ClickHouse 26.7 as a particularly large release and calls out more efficient hash joins, automatic join arrangement for multi-table queries, token positions in text indexes, and EXPLAIN ANALYZE for measuring actual query execution phases.

The newsletter reports that a phrase query on a Hacker News dataset ran 40 times faster after token positions were added to the text index. That is a concrete result, but it is tied to the described dataset and query. It should be read as evidence of a targeted feature improvement, not as a universal text-search benchmark.

The same newsletter highlights community contributor Manuel Raimann’s work. It reports improvements of up to 7 times for wide-integer comparisons, up to 5 times for Delta decompression, and up to 4 times for statistical and bitwise aggregates. Those numbers point to work below the SQL surface, where execution costs and data representation affect a wide range of analytical workloads.

The newsletter also announces Andy Pavlo joining ClickHouse to establish ClickHouse Labs. The stated purpose is applied database research that can turn into technology for users, with work extending into ClickHouse’s PostgreSQL team. The newsletter’s description of an interactive playground for more than 100 database systems, backed by a 100-million-record ClickBench dataset, adds a second research signal: ClickHouse is investing in ways to compare database behavior, not only in new product features.

Other first-party posts show the same expansion into operations. The Managed Postgres reliability article explains how supporting services such as PgBouncer, backup agents, exporters, Prometheus, and log collectors can compete with PostgreSQL for memory, CPU, and disk. It describes cgroup limits, GOMEMLIMIT, CPU weighting, bounded buffers, and a separate cgroup for PostgreSQL so that a memory event in supporting services does not select a database process.

That article is not evidence that ClickHouse’s analytical engine is faster than another database. It is evidence that the company is treating database operation as a systems problem. The product direction includes resource isolation and failure containment, not only query execution.

The Shopify observability case study gives a customer example at a different scale. ClickHouse reports that Shopify’s internal Observe platform unified metrics, logs, traces, profiles, and exceptions on ClickHouse, with a 16 times query improvement out of the box and peaks above 30 times. The case study says the system ingests around 100 million events per second, about 110 GB per second of telemetry, while keeping the data queryable in under a minute.

Those Shopify figures come from a vendor-authored case study, so they describe one architecture and one workload. They do show why ClickHouse keeps emphasizing observability: the same columnar and event-oriented model can support more than dashboards over conventional business tables.

The POSETTE recap adds an infrastructure angle. It describes a 3.3-billion-row PostgreSQL workload tested across eight clusters, with four using local NVMe and four using baseline gp3 EBS provisioned at 3,000 IOPS. The subject is PostgreSQL storage behavior, not a direct ClickHouse benchmark, but it reinforces the company’s interest in the boundary between database performance and the machine underneath it.

Taken together, the announcements point in three directions: faster execution inside the engine, broader observability workloads, and more controlled operation of managed database services. That is an interpretation of the first-party material, not a claim that every direction is equally mature.

What the ToolVitals metrics show

ToolVitals assigns ClickHouse a hot score of 205.3, a health score of 99, a shipping score of 99, and an overall ToolVitals score of 99. The repository has 50,220 GitHub stars, 11,012 commits in the last 30 days, 30 GitHub releases in the last 90 days, and 37 active contributors. ToolVitals reports data confidence of 90.

Those numbers support a straightforward conclusion: ClickHouse is an active and maintained public project. The combination of recent commits, releases across a 90-day window, recent contributors, and high health and shipping scores is much stronger than a repository that has accumulated stars but stopped moving.

The numbers do not support every conclusion readers may want to draw. Stars are cumulative attention, not current usage, reliability, or user satisfaction. Commits are engineering activity, not a count of completed features. A commit may be a fix, refactor, test, documentation change, merge, or internal step toward a later release. The 37 active contributors measure recent participation, not the distribution of knowledge across the project or the support available to a production team.

The 99 shipping score should also be treated as a ToolVitals indicator, not as a promise that every change reaches users quickly. The zero release-event figure makes that especially clear. A project can have intense repository activity while maintaining a quieter release surface. ToolVitals’ confidence score strengthens confidence in the measurement snapshot, but it is not a probability that ClickHouse will work well for a particular workload.

How the signal compares with other databases

Elasticsearch is the closest comparison in the related database data. ToolVitals lists Elasticsearch with a hot score of 207.0, 78,184 GitHub stars, a shipping score of 98, and zero release events in the last 30 days. ClickHouse has fewer stars and a slightly lower hot score, but its shipping score is 99 in the same snapshot.

The license distinction also matters. ToolVitals classifies Elasticsearch as open core and notes AGPLv3, SSPL, and Elastic License 2.0 options alongside separate commercial capabilities. ClickHouse is classified as OSI-approved open-source software with an Apache-2.0 label. That is not a quality ranking, but it changes how teams should evaluate redistribution, modification, and deployment boundaries.

Turso provides another reference point. ToolVitals lists 24,507 stars, a hot score of 180.8, a shipping score of 98, and zero release events in the last 30 days. These comparisons show why star count alone is a poor way to select a database. ClickHouse is not the largest related repository by stars in this snapshot, yet its measured activity and shipping indicators remain high.

What this data does not tell you

ToolVitals can observe repository activity, stars, contributors, releases, license signals, and public project evidence. It cannot observe code quality in your workload, data correctness under failure, query latency on your schema, recovery behavior, operational toil, user satisfaction, revenue, or whether a team can maintain the system successfully.

The official site claims millisecond analytical results at large scale, and the Shopify case study reports major speed improvements. Neither source is an independent evaluation of your data, concurrency, retention policy, hardware, or query patterns. The supplied GitHub release excerpts also do not expose detailed release notes, so no feature-level conclusion should be attached to the release tags beyond their names and channels.

A skeptical buyer should run a representative test before committing. Include append-heavy ingestion, concurrent analytical queries, joins, text search, schema changes, retention and TTL behavior, replicas, backup and restore, and failure injection. Record p95 and p99 latency, ingestion lag, recovery time, resource consumption, and the operational steps required to diagnose problems. If the primary workload is transactional, test transaction semantics and contention separately instead of assuming that an analytical engine replaces an OLTP database.

What maintainers should make clearer

The maintainers have a strong activity story, but the 11,012-commit and zero-release-event gap is easy to misread. Release notes that connect major changes to release lines would help readers distinguish work in progress from behavior available in stable or LTS builds. The August newsletter does this well for 26.7 by explaining join changes, text indexes, EXPLAIN ANALYZE, contributor work, and the research program.

The same level of explanation would improve the individual LTS and stable release pages. It would also help to state how release events are counted across maintenance branches, release calls, and tagged builds. Clearer boundaries between the core database, ClickStack, Managed Postgres, Langfuse, and related services would make the expanding product surface easier to evaluate without weakening the project’s broader direction.

Recommendation

If your team needs real-time OLAP over large event tables, logs, metrics, traces, or a speed layer beside an existing OLTP system, put ClickHouse near the front of your evaluation list. The recommendation rests on concrete evidence: the official product scope matches those workloads, ToolVitals records 11,012 commits and 30 releases across its windows, the project scores 99 for health and shipping, and recent first-party material shows work on joins, text search, query inspection, observability, and database operations.

Start with a workload test, not the star count. If your team primarily needs transactional storage, keep an OLTP database as the baseline and evaluate ClickHouse or Managed Postgres against the specific boundary you need to cross. ClickHouse’s public evidence is strongest for high-volume analytical work and the systems built around it. That is enough to justify a serious evaluation, but not enough to skip one.

Sources