September 2026 Summaries

ClickHouse Cloud has introduced SCIM 2.0 provisioning to automate organization membership and role management through identity providers such as Okta and Microsoft Entra ID, complementing existing SAML SSO authentication. After configuring SAML, administrators can enable SCIM, generate endpoint-scoped API credentials, and connect their identity provider so user assignments, removals, and group changes are synchronized automatically. IdP groups can map to ClickHouse custom roles, with stable external group IDs preserving mappings through group renames, while default SAML-assigned roles continue to apply to provisioned users. SCIM is limited to verified-domain SSO users and custom roles, cannot assign system roles such as Admin, does not manage manually invited members or passwords, and records provisioning actions in the organization audit log. The feature is generally available for Enterprise and BYOC organizations and supports any compliant SCIM 2.0 identity provider.

ClickHouse’s PostgreSQL extensions have required careful integration of C++ components into PostgreSQL’s C-based runtime, whose MemoryContext allocation model and setjmp/longjmp error handling are incompatible with C++ destructors and exceptions. The post explains that PostgreSQL errors can bypass C++ cleanup, while uncaught C++ exceptions can abort backend processes and potentially trigger cluster-wide recovery. Each extension adopts a different containment strategy: pg_clickhouse eliminated C++ by replacing its dependency with C libraries, pg_re2 confines C++ allocations and logic to a wrapper that never calls PostgreSQL code, pg_chdb runs its C++ ClickHouse engine in a separate helper process, and pg_stat_ch isolates C++ within a background worker while adding exception and termination handling. Although these measures reduce risk, the discussion notes that worker-level safeguards cannot fully guarantee crash isolation or shared-memory safety, and describes fixes for ownership bugs plus ongoing work to move pg_stat_ch’s C++ dependencies toward stronger process separation.

pg_clickhouse v0.11.0 and chdb extension v0.1.2 expand PostgreSQL–ClickHouse compatibility through improvements to encoding validation, data-type mappings, query pushdown, and nested data support. The releases introduce configurable handling of invalid text and JSON encoding bytes, allowing users to fail, remove, replace, or truncate malformed data, while bytea mappings preserve raw values when needed. ClickHouse interval types can now import as PostgreSQL intervals or bigints and support pushed-down expressions such as timestamp-plus-duration filters. Parameterized ClickHouse JSON columns now map to jsonb or json and permit property-based ordering, while unflattened Nested types can be represented either as multidimensional text arrays or arrays of compatible PostgreSQL composite types. Additional mappings cover large integers, time, tuples, maps, and geographic types; deprecated clickhouse_raw_query() has been removed in favor of newer query functions; PostgreSQL 13 support has ended; and cryptographic hash and digest functions can now be pushed down to ClickHouse.

ClickHouse announced an expanded collaboration with Microsoft that introduces a native ClickHouse workload for Microsoft Fabric in public preview, generally available OneLake reads for Apache Iceberg tables, public-preview OneLake writes, and ClickHouse Bring Your Own Cloud availability through the Microsoft Marketplace. The Fabric workload enables teams to use ClickHouse’s query engine for sub-second analytics on OneLake data without leaving Fabric, moving data, provisioning separate clusters, or maintaining ETL pipelines. Direct OneLake integration allows organizations to query governed Iceberg tables in place and write ClickHouse-transformed results back to OneLake for use across Fabric tools such as Power BI and notebooks. The Azure BYOC offering lets customers operate managed ClickHouse Cloud within their own Azure tenants while retaining control over data, identity, networking, encryption, compliance, and residency requirements, with purchases eligible for existing Microsoft agreements and Azure consumption commitments.

ClickHouse announced direct write support for Apache Iceberg tables in Microsoft OneLake, allowing data produced in ClickHouse to be registered in the OneLake catalog, governed by OneLake Security, and accessed by compatible analytics tools. The integration uses ClickHouse’s DataLakeCatalog engine and Microsoft Entra ID service-principal authentication, enabling users to query existing OneLake data and publish query results or application data back into the same catalog without a separate ingestion layer. Example use cases include AI agents that analyze operational data in ClickHouse and publish anomaly reports to OneLake for use in Power BI, Fabric Spark, and other tools, as well as applications landing managed Iceberg tables directly in OneLake. OneLake provides a unified Microsoft Fabric data layer with governance, lineage, permissions, shortcuts to external storage, database mirroring, and interoperability between Iceberg and Delta Lake formats. ClickHouse plans to add write support for additional catalogs and deepen integration with OneLake’s fine-grained security APIs.

ClickHouse workload for Microsoft Fabric is now available in public preview as a native acceleration layer that syncs OneLake tables into dedicated ClickHouse Cloud services on Azure, targeting high-concurrency, low-latency workloads such as AI agents, interactive dashboards, and customer-facing applications. It allows Fabric users to create a ClickHouse item, provision a service through Microsoft Entra identity and workspace-role mapping, copy selected Lakehouse tables through point-in-time snapshot syncs, and run analytical SQL queries across billions of rows with sub-second performance while retaining OneLake as the source of truth. The workload offers embedded querying, connectors for Power BI, Fabric notebooks, standard protocols and language clients, and governed read-only access for Copilot Studio, GitHub Copilot, Microsoft Foundry, and MCP-compatible tools. ClickHouse Cloud compute is separate from Fabric capacity, scales independently, supports Azure regional deployment and default idling, and avoids Azure egress charges for OneLake transfers. Planned enhancements include OneLake write-back, continuous replication, synchronized permissions, deeper Power BI integration, shared collaboration features, private networking, and built-in ClickHouse capabilities such as full-text search, vector search, and materialized views.

chDB Durable Layer is presented as a way to preserve embedded chDB analytical databases across laptops, CI jobs, and short-lived sandboxes without turning local memory recall into a remote database call or requiring a database server. It addresses the limitation of local MergeTree directories by retaining a local working copy for fast queries while storing authoritative recoverable state in user-owned object storage, using explicit flush operations for durability, checkpoints to compact write-ahead logs, and conditional writes on a head record to enforce a single-writer lease. The approach is intended for append-heavy, analytical workloads such as agent memory, telemetry, replay buffers, and preprocessed research datasets, where SQL queries over history, evidence, revisions, traces, and conflicts are more useful than simple transactional checkpointing. The text contrasts it with SQLite, Litestream, hosted databases, vendor-managed durable objects, and local DuckDB or chDB, positioning Durable as a middle ground that offers portable columnar OLAP without a service, sidecar, or persistent volume. It recommends append-only table designs, typed columns, compressed cold evidence, external storage for binary blobs, flushing after meaningful batches, and using server databases instead when multi-writer collaboration or high-frequency transactional updates are required. Durable V1 is described as available across Python, Node, Go, and Rust bindings, with support for S3-compatible storage, Google Cloud Storage, and Azure Blob Storage.

Postgres memory management can be difficult to predict because work_mem applies to individual plan nodes and parallel workers rather than imposing a query-wide limit, while some executor structures, such as recursive CTE deduplication hash tables, cannot spill to disk and may grow until completion or memory exhaustion. Using a recursive graph query designed to consume roughly 1 GiB per connection, the comparison tested ClickHouse Managed Postgres, Google Cloud SQL, PlanetScale Postgres, and Amazon RDS under increasing concurrent load. The reported results found that ClickHouse Managed Postgres enforced a lower committed-memory ceiling and returned recoverable out-of-memory query errors while keeping clusters available, whereas RDS allowed memory use to rise further but could trigger Linux OOM events, database restarts, and crash recovery under severe pressure. Cloud SQL and PlanetScale used supervisory mechanisms to terminate sessions before kernel-level exhaustion, preserving service in some cases but experiencing session failures and, at higher loads, instability or crashes. The source concludes that reserving memory for database and operating-system caches while limiting runaway query memory sacrifices some throughput at moderate load but can favor cluster uptime over allowing individual workloads to consume most available RAM.

ClickHouse 26.9 introduces 56 features, 135 performance improvements, and 464 bug fixes, with notable additions aimed at query flexibility, efficiency, security, and observability. New capabilities include arithmetic between DateTime and Time values with configurable overflow handling; expanded PromQL and TimeSeries support in private preview for ClickHouse Cloud; and CREATE TOKEN, which generates time-limited, privilege-restricted credentials for applications and automation. Conditional LIMIT boundaries using AFTER, UNTIL, and ALL enable queries to return ordered ranges around matching events, supporting use cases such as log incident analysis. Append-only refreshable materialized views can now refresh incrementally, processing only data committed since the prior run and supporting efficient replication to targets such as Iceberg tables. Performance enhancements allow min, max, and count queries to use column statistics without scanning data, while high-cardinality DISTINCT operations can spill intermediate states to disk to reduce memory pressure. Other additions include session query-ID tracking, controls on individual table sizes and database table counts, and bracket syntax for JSON paths, including keys containing dots or spaces.

Fountain replaced its multi-vendor, batch-oriented analytics stack based on database replication, S3/Iceberg, and BigQuery with ClickHouse Cloud and ClickPipes to support Cue, its agentic AI platform for frontline hiring operations. The new architecture continuously streams data from Postgres and MongoDB into ClickHouse, uses native JSON for nested MongoDB documents, and applies more than 2,000 incremental materialized views to transform data without external orchestration. This reduced data-refresh latency from three hours to under two minutes, with most queries completing in under a second, while lowering operating costs by about 66%. Fountain also shifted expensive calculations, including transition-time window functions, to ingestion-time transformations, reducing query memory use by 60–98%, and implemented database-level role-based access controls and row policies intended to prevent Cue’s LLM from accessing or influencing tenant security rules. The platform now supports billions of CDC and analytics rows across 15 deployments, and Fountain plans to extend its real-time semantic data model to internal teams through an MCP-based interface.

ClickHouse appointed former Snowflake, ServiceNow, and Data Domain CFO Michael Scarpelli to its Board of Directors as an independent director and Audit Committee chair, adding financial and IPO experience as the company expands. The company reported surpassing $350 million in annualized revenue, up from about $200 million at the end of 2025, and serves more than 4,000 customers, including DoorDash, Meta, Tesla, Cisco, and Visa. Valued at $15 billion in a Series D earlier in 2026, ClickHouse employs nearly 800 people in 27 countries, generates over half its revenue internationally, and plans to reach 1,000 employees by year-end. The company positions its open-source real-time analytical database as infrastructure for AI, analytics, warehousing, observability, and transactional workloads, while Scarpelli’s appointment follows other efforts to strengthen its finance and governance functions.

PostgreSQL performance issues at large scale often stem from storage latency once the working set exceeds memory, affecting ingestion, read consistency, VACUUM, checkpoints, and logical replication. A benchmark using a 482 GiB pgbench dataset found that local NVMe storage delivered 9.2 times the throughput of baseline gp3 EBS, with median update latency falling from 36.9 ms to 4.0 ms, largely because EBS-backed processes spent most of their time waiting for data reads. Although local NVMe is ephemeral, the proposed design combines synchronous quorum replication across availability zones with continuous WAL archival to provide resilience, recovery, and point-in-time restore capabilities. The discussion also argues that faster disks improve transactional PostgreSQL workloads but cannot make its row-oriented layout efficient for large analytical scans, for which a columnar system such as ClickHouse is more suitable. It recommends retaining PostgreSQL for ACID transactions and point lookups while using WAL-based change data capture, query pushdown, and schema synchronization to replicate data to ClickHouse for near-real-time analytics, including a newer physical-WAL-based WalShadow option intended to enable sub-second replication.

ClickStack’s August update, spanning versions 2.34 through 2.38, centers on dashboard improvements, expanded Prometheus support, alerting enhancements, and observability tooling. Dashboard variables are now generally available, allowing filters to be inserted into SQL, Lucene, and PromQL queries, including dependent filters and cross-source mappings, while chart formulas enable calculations such as rates and ratios directly in visualizations. New dashboard capabilities include a metrics explorer, deployment release markers, static and PromQL label-based filters, query replay in Search, customizable PromQL legends, and heatmap percentile tooltips. ClickStack also introduced experimental TimeSeries storage and PromQL querying for Prometheus workloads, a beta LLM observability dashboard for tracing model usage, token consumption, latency, and errors, and OIDC authentication for the standalone telemetry collector. Alerting now supports up to ten notification targets, custom names and tags, detailed evaluation histories, and richer webhook payloads. MCP server additions help agents detect emerging log patterns, validate multiple dashboard tiles at once, favor builder tools over raw SQL, and distinguish read-only from modifying operations, while trace navigation now supports span links in both directions.

ClickHouse has released an official upstream Apache Airflow provider, apache-airflow-providers-clickhousedb, simplifying orchestration of ClickHouse ingestion, transformation, and analytical workflows in self-managed Airflow and managed services such as Astronomer. Built on the ClickHouse Connect HTTP(S) client and Airflow’s common SQL framework, the provider supports standard SQLExecuteQueryOperator tasks for DDL, DML, and queries, while ClickHouseHook enables bulk inserts, streaming, and direct client-specific operations. The release provides an officially maintained upgrade path from the widely adopted community airflow-clickhouse-plugin created by Anton Bryzgalov, whose work established many conventions for ClickHouse-Airflow integrations. ClickHouse cites production use across customers and internally, including Astronomer’s Astro Observe platform, Chartmetric’s high-volume playlist pipeline, and ClickHouse’s own warehouse, where Airflow coordinates 76 DAGs and more than 40 sources processing roughly 6 billion rows daily. Users can install the provider with pip, configure a ClickHouse connection through the Airflow interface or environment variables, and deploy the same setup locally or through Astro, with TLS connections typically using port 8443 and secure mode enabled.

A three-day Netherlands trip included presentations at PGDay Lowlands in Utrecht and Percona Live Amsterdam, despite a nationwide public transport strike ending just before the first event. At PGDay Lowlands, the author delivered a five-minute talk on ClickHouse’s open-source PostgreSQL extensions: pg_clickhouse, which lets existing PostgreSQL queries access and push analytical workloads to ClickHouse through foreign tables, and pg_stat_ch, which records detailed per-query execution history in ClickHouse without delaying PostgreSQL. The conference also featured lightning talks on speaking, partitioning, encryption, and conference music, alongside a session on PostgreSQL plan stabilization tools that constrain the planner to preserve known plans. At Percona Live, a multi-database event, the author presented PostgreSQL 19 monitoring enhancements, including expanded logging, WAL and I/O statistics, wait events, new recovery and lock views, multixact statistics, and revised transaction wraparound warnings, while noting future monitoring work planned for PostgreSQL 20.

ClickHouse’s newsletter highlights the 26.8 release, which introduces custom HTTP handlers, dynamic query filtering, pipelined SQL transformations through the |> operator, a user-specific query log, a URL database engine, and Japanese and Chinese text-index tokenizers. It recognizes PostHog engineer Rory Shanks for contributions including replica mutation-data fetching, absent-token caching, and improved JSON subcolumn reads, while also covering technical resources on replication queues, query-plan analysis, and CostBench’s cloud data warehouse performance-per-dollar comparisons. The update announces private previews for On-Demand Compute, featuring dedicated workers, a cost-based optimizer, and distributed query execution, as well as PromQL support and a TimeSeries engine intended for Prometheus-compatible metrics workloads. It also reports expanded PostgreSQL initiatives, including WAL-based replication through WalShadow, Managed Postgres on Google Cloud, and a chdb PostgreSQL extension, alongside previews of AI SQL functions and other community projects. The newsletter concludes with a broad schedule of webinars, training sessions, Open House Roadshow stops, and industry events across the Americas, EMEA, and APAC.

ClickHouse and dbt Labs announced a public beta of the ClickHouse adapter for dbt v2, a Rust-based rewrite of dbt that uses the Apache Arrow Database Connectivity driver and ships directly with the dbt binary, alongside a private beta that makes ClickHouse a natively supported connection on dbt Platform. The existing Python-based dbt-clickhouse adapter, maintained since 2021 and used by more than 2,000 production teams, will continue to be supported in parallel while the v2 adapter approaches feature parity. The integration is intended to bring dbt’s testing, documentation, contracts, and lineage capabilities to ClickHouse’s real-time analytical workloads, including materialized views, streaming ingestion, high concurrency, and deployment across self-managed ClickHouse, ClickHouse Cloud, and BYOC environments. dbt Labs reports that dbt v2 can parse projects up to 30 times faster than v1, while the beta adapter currently passes more than 81% of the dbt v1 integration suite and 92% of applicable ClickHouse Cloud tests. The v2 adapter is not yet recommended for production workloads, and both companies are seeking beta feedback to prioritize remaining capabilities such as distributed materializations, ON CLUSTER DDL, Fusion features, and broader dbt Platform functionality.

ClickHouse Cloud has announced a private preview that adds PromQL support and a TimeSeries table engine, allowing organizations to ingest Prometheus metrics through the remote-write v1 protocol and query them without rewriting existing PromQL dashboards, alerts, or queries in SQL. The offering is intended to let teams consolidate metrics alongside logs and traces in ClickHouse while preserving Prometheus semantics for counters, gauges, histograms, irregular scrape intervals, resets, and range-query calculations. Metrics can be queried through Prometheus-compatible HTTP APIs, Grafana, ClickStack, the ClickHouse client using a PromQL dialect, or SQL table functions, while existing Prometheus servers, agents, and OpenTelemetry collectors can retain their collection configurations. ClickStack’s preview integration supports PromQL-based charts, dashboards, series and scalar queries, including variables for coordinated filtering across telemetry data, although it does not yet include a visual query builder or PromQL alerting. Current PromQL coverage exceeds 85%, and planned work includes broader language support, downsampling, native histograms, recording and alerting rules, additional protocols such as remote-write v2 and OpenMetrics, and possible unified support for OpenTelemetry metrics.

ClickHouse Cloud’s replica-aware routing, available in public beta for Enterprise customers, keeps related requests directed to the same replica by consistently hashing a user-provided routing key. This addresses issues in multi-replica deployments where temporary tables, named sessions, local caches, recent writes, or schema changes may exist on one replica before being visible on others. HTTP clients can provide an `X-ClickHouse-Replica-Tag` header, while native clients can use a TLS SNI override that separates the routing hostname from certificate validation. Built using Istio and Envoy, the feature evolved from an impractical subdomain-based approach and avoids using ClickHouse session IDs because they permit only one query at a time. Replica-aware routing can improve read-after-write behavior and cache locality, but it is best-effort rather than guaranteed, as upgrades, restarts, or scaling can remap keys to different replicas; it also directs traffic without providing workload isolation.

ClickHouse’s clickhouse-local tool can transfer Parquet data into MySQL and query the imported results without leaving the ClickHouse environment. The walkthrough starts a local MySQL 8.4 instance in Docker, configures ClickHouse with MySQL connection details, and examines a Stack Overflow votes Parquet file hosted in S3 before creating a compatible InnoDB table in MySQL. Using ClickHouse’s url and mysql table functions, it loads roughly 2.3 million vote records into MySQL in about 17 seconds, then demonstrates querying MySQL through ClickHouse. Queries supplied as structured subqueries are parsed and translated from supported ClickHouse syntax into MySQL SQL, whereas queries passed as strings must already use valid MySQL syntax, as illustrated by the incompatibility of ClickHouse’s tuple function. The post also shows how named collections can store reusable connection settings and concludes with an aggregate query identifying Stack Overflow posts that received both upvotes and downvotes, while noting that ClickHouse provides comparable table functions for systems including PostgreSQL, SQLite, and MongoDB.

ClickHouse has introduced beta AI Functions that let SQL queries directly call LLM and embedding providers, allowing classification, extraction, generation, translation, filtering, redaction, embedding, and semantic similarity operations to run alongside data stored in the database. Released incrementally through versions 26.4 to 26.8, these functions use remote provider APIs and return native ClickHouse values, while ClickHouse Cloud offers them as a private-preview plug-and-play feature and open-source deployments require configured credential collections. The approach is intended to reduce the operational complexity of traditional AI and retrieval-augmented generation workflows by keeping data storage, vector indexing, retrieval, and response generation within ClickHouse. Examples using Hacker News data show how the functions can categorize stories, identify incident-related comments, summarize or translate text, and support RAG pipelines through embeddings and vector search. Because LLM calls add latency and token-based costs, ClickHouse provides per-query limits for API calls, input tokens, and output tokens, along with monitoring through query logs and options to either halt or return partial results when quotas are reached. Production use also requires attention to prompt injection, nondeterministic outputs, cost scaling, provider data exposure, HTTPS, and endpoint access controls.

ClickHouse 26.8 is a long-term support release that introduces 98 features, 128 performance optimizations, and 556 bug fixes, alongside contributions from a large group of new community members. Major query enhancements include background execution that continues after client disconnection, PostgreSQL-compatible regular-expression operators and psql commands, array-based subscripting, JSON abstract syntax tree conversion and execution for safer programmatic query generation, relative user-expiration syntax, pipelined SQL, streaming HTTP API capabilities, and per-user query history. The release also fixes materialized-view population race conditions through atomic snapshots, adds Japanese, Chinese, ICU multilingual, and regular-expression-based text tokenizers, and broadens remote-data access through a URL database engine, BigQuery integration, Amazon S3 Tables, Snowflake Horizon, and Apache Iceberg Puffin support. Performance work improves Iceberg metadata loading, native Parquet pruning and lazy materialization, spatial GeoParquet queries, GROUP BY execution, and join planning and algorithms, including parallel merge joins and a cost-based optimizer for distributed queries.

ClickHouse has announced WalShadow, an open-source replication engine that transfers PostgreSQL data to ClickHouse by consuming physical write-ahead log (WAL) streams rather than using logical replication. It decodes changes outside the source database, tracks schema through a shadow PostgreSQL catalog, batches records into ClickHouse-native blocks, and inserts them concurrently, aiming to reduce source overhead while supporting initial loads, recovery, switchovers, and schema changes. In reported benchmarks, WalShadow delivered roughly 200-millisecond commit-to-visible latency and sustained 289,000 rows per second, compared with about 10 seconds and 120,000 rows per second for PeerDB under the tested conditions. Because managed PostgreSQL services generally do not expose physical WAL, WalShadow is also entering private preview for ClickHouse Managed Postgres, where ClickHouse can integrate it into the replication layer. The launch builds on ClickHouse’s broader effort to combine PostgreSQL transactional workloads with ClickHouse analytics in a more unified data stack.

ClickHouse Managed Postgres is now available in private preview on Google Cloud, extending the NVMe-backed managed PostgreSQL service previously launched on AWS to GCP environments. The service combines PostgreSQL for transactional workloads with ClickHouse for analytics through in-region change data capture replication via ClickPipes and a unified query layer provided by the pg_clickhouse extension, allowing applications to access both systems through one PostgreSQL connection. Running PostgreSQL on GCP Local SSD aims to reduce disk latency and improve performance for update-heavy, vacuum-intensive, and high-load workloads, while managed features include high availability across zones, backups and point-in-time recovery, read replicas, PgBouncer pooling, extensions, monitoring, and scheduled upgrades. Customers can provision services through APIs, Terraform, or the ClickHouse CLI, and can migrate from Cloud SQL, AlloyDB, AWS services, or self-managed PostgreSQL using continuous replication and controlled cutovers. Access is invitation-only during the preview, available across GCP regions supported by ClickHouse Cloud, while the AWS version remains in public beta.

ClickHouse has launched a plugin for OpenAI’s ChatGPT Work Data agent and Codex, enabling users to connect ClickHouse Cloud through OAuth and analyze data using natural-language questions. The plugin combines ClickHouse’s managed Remote MCP server, which offers 13 read-only tools for exploring databases, schemas, SELECT queries, service details, ClickPipes, backups, billing, and related information, with open-source Agent Skills that guide models toward ClickHouse best practices for schema design, ingestion, and query optimization. Users and workspace administrators can install the plugin through the shared directory, provided their ChatGPT workspace supports plugins and their ClickHouse Cloud service has Remote MCP enabled. ChatGPT Work can use query results to produce reports and branded interactive dashboards while retaining access restrictions tied to the connected user’s ClickHouse Cloud permissions. The integration is positioned as part of an agentic analytics approach, with ClickHouse’s low-latency performance supporting iterative exploration of large, continuously ingested datasets and ChatGPT Work providing conversational analysis and dashboard creation.

ClickHouse has announced a private preview of ClickHouse On-Demand Compute, a ClickHouse Cloud capability that lets eligible queries use a shared, managed pool of workers outside a service’s primary cluster, allowing users to request compute resources directly for intensive ad hoc, offloaded read, and supported Iceberg or Delta Lake workloads. Built on multistage distributed query execution and a new cost-based optimizer, the feature is enabled through query settings that specify distributed planning and worker counts, with workers leased for at least 60 seconds and reused during active lease periods to avoid cold starts. Concurrent queries share the worker pool, which expands according to the largest request, and queries can still run with fewer workers if capacity is limited. In a TPC-H benchmark using SharedMergeTree, On-Demand Compute used capacity only during demand bursts and outperformed an autoscaling cluster for the tested workload, although performance gains varied by query type and narrowed at higher concurrency. ClickHouse notes that complex joins, grouping, and ordering workloads may benefit most, while short, simple read queries may perform better on stateful clusters, and it plans to gather feedback as preview access begins after its September 24, 2026 webinar.

CostBench evaluates real-time analytics performance per dollar by measuring the continuous path from low-latency ingestion through data preparation and concurrent query serving, arguing that systems must maintain columnar layouts, pruning-friendly organization, and current pre-aggregations to keep fresh data efficient to query. Its first benchmark streamed 113.2 billion stock-market quote records at a target rate of one million rows per second into ClickHouse Cloud, Snowflake, BigQuery, and Redshift Serverless using vendor-recommended push-based ingestion paths, while scheduled aggregate and event-level drill-down queries ran throughout. The benchmark used a shared client and workload, aligned resources where possible, disabled result caching, and scored platforms by combining fresh-data-path cost, normalized query-serving cost, and total query runtime, while excluding database storage and several billing-related factors. According to the reported results, ClickHouse Cloud had the lowest ingestion-preparation cost, query-serving cost, and accumulated runtime, with the other tested platforms scoring 412 to 1,996 times worse on the end-to-end metric, compared with a previously reported 32 to 101 times worse gap in query-side-only testing. The authors state that forthcoming provider-specific analyses will examine how architectural and billing differences contributed to these outcomes, while future benchmark rounds may include pull-based ingestion and Databricks after its Lakehouse/RT offering becomes generally available.

CostBench compared ClickHouse Cloud and Snowflake under continuous ingestion of 113.2 billion stock-market quotes, using the same schema, workload, approximate 16-CPU query-serving capacity, sorting or clustering keys, and target ingest rate of one million rows per second. The benchmark found that ClickHouse Cloud integrated asynchronous ingestion, ordering, incremental pre-aggregation, and background merging within its storage engine, keeping raw data and aggregate summaries synchronized, while Snowflake’s Snowpipe Streaming ingestion and Interactive Materialized View refresh operated as separate services, leaving the view an average of 1.4 minutes behind during active ingestion. According to the results, Snowflake’s current aggregate queries then required query-time reconciliation of unrefreshed data, with compilation accounting for 85% of aggregate-query time, whereas querying raw tables avoided reconciliation but required more scanning and aggregation work. ClickHouse reported substantially lower aggregate latency, a smaller advantage on drill-down queries, and lower fresh-data-path costs; the benchmark’s combined cost-and-runtime scoring model calculated ClickHouse Cloud’s end-to-end real-time performance per dollar as 412 times better than the tested Snowflake configuration. The analysis also notes Snowflake alternatives involving asynchronously refreshed tables and dedicated refresh warehouses, which can improve query speed but introduce additional cost and a minimum freshness lag.

ClickHouse has introduced chdb, a PostgreSQL extension built on the in-process chDB ClickHouse engine that broadens PostgreSQL import and export capabilities across numerous data formats and cloud storage systems. In benchmarks loading a one-million-row NYC Taxi dataset from Amazon S3, chdb showed consistently faster performance than DuckDB-backed pg_lake and pg_duckdb for CSV, JSON, and Parquet imports, while aws_s3 was competitive but supported fewer formats. The package includes a chdb extension for executing individual chDB queries and a chdb_hook module that integrates with PostgreSQL COPY commands to read and write data through URLs for S3, Google Cloud Storage, Azure Blob Storage, HTTP, local files, and HDFS, including wildcard-based multi-file imports and table creation with inferred schemas. It supports a broad range of ClickHouse formats and compression methods, maps most PostgreSQL and ClickHouse data types, and uses an on-demand helper process rather than embedding chDB directly in PostgreSQL backends to limit persistent resource use and isolate failures. Planned work includes expanded type mappings, credential-chain support, additional COPY features, Iceberg compatibility, and direct querying of storage files.

Google’s open-source MCP Toolbox for Databases provides an MCP server and YAML-based framework for exposing database tools to AI agents, including native support for ClickHouse semantic search using Gemini embeddings. Developers can define a ClickHouse source, an embedding model, and curated SQL tools in configuration, allowing Toolbox to embed document text during insertion and embed natural-language queries during retrieval while agents interact only with text and ranked rows. The setup supports generic exploratory SQL tools as well as safer production-oriented parameterized tools, although ClickHouse values are driver-escaped and interpolated client-side rather than server-side prepared statements. A demonstrated implementation stores 768-dimensional Gemini vectors in an Array(Float32) ClickHouse column, optionally indexes them with HNSW for approximate search, and ranks documents through cosine distance. Tests on a small synthetic corpus showed strong semantic matches for queries about database performance, Kubernetes failures, and hill safety, but also illustrated that top-k retrieval can return irrelevant results when no suitable content exists, making distance thresholds advisable. The discussion notes operational limitations, including Gemini as the only supported embedding provider, a hardcoded semantic-similarity task type rather than retrieval-specific embedding modes, potentially large query logs from inlined vectors, and the need for offline batch pipelines at high ingestion volumes.

ClickHouse 26.8 introduces pipelined SQL, extending its existing FROM-first syntax with a |> operator that expresses queries as sequential transformations such as reading data, filtering rows, aggregating results, sorting, and limiting output. Using UK property-price data, the examples show that conventional SQL, FROM-first SQL, and pipeline syntax produce equivalent results, while pipelines can be easier to construct and inspect incrementally because every stage represents a complete intermediate query. ClickHouse translates pipelines into nested standard SQL internally, but optimizes the entire query rather than materializing every intermediate result. The new syntax supports EXTEND for adding computed columns while preserving existing ones and enables subsequent stages to reuse aggregation aliases, avoiding manually written subqueries or common table expressions. Pipeline-stage order is significant, as applying a limit before a later aggregation changes the underlying data and can produce nondeterministic results when no ordering is specified. Pipelines can also be used in subqueries, views, and INSERT ... SELECT operations, offering a processing-order alternative to conventional SQL without replacing it.

ClickHouse 26.8 introduces capabilities for building read-oriented HTTP APIs directly in the database, potentially removing a thin pass-through application layer when no business logic, orchestration, or custom validation is required. Using a UK property-price dataset of more than 30 million transactions, the walkthrough creates a MergeTree table, ingests and transforms CSV data, and configures a restricted API user with JSON output and result limits. Named HTTP handlers can expose predefined GET, POST, PUT, or DELETE endpoints with typed query-string or URL-path parameters, while result-modification settings allow clients to apply controlled filtering, field selection, sorting, ordering, pagination, limits, and output formats without altering the handler query. Tables can also be exposed directly through URL paths when server and user settings permit it. Framing output formats support streaming data alongside progress, totals, logs, and exceptions, including Server-Sent Events with Base64 encoding for arbitrary result payloads. API activity can be inspected through query logs, and access remains governed by the authenticated user’s permissions; SQL SECURITY DEFINER views can safely expose curated or aggregated data without granting access to underlying tables.

ClickHouse describes how three organizations—logistics startup Shipsidekick, social intelligence platform socialpruf., and educational publisher Infinitas Learning—migrated production PostgreSQL workloads from Neon to ClickHouse Managed Postgres after reporting reliability, performance, support, scaling, and network-transfer-cost concerns. The companies said the move improved uptime, query consistency and speed, connection handling, cache performance, and infrastructure costs, with Infinitas reporting p99 latency falling from seconds to single-digit milliseconds and socialpruf. reporting roughly 30% faster queries overall. Each used ClickPipes for schema transfer, parallel initial loading, and change data capture before scheduling production cutovers, completing migrations ranging from several hours to under 16 hours for databases as large as 750 GB. The account attributes the reported performance gains partly to local NVMe storage and notes that colocating PostgreSQL and ClickHouse can remove transfer charges for analytics pipelines, while also outlining migration considerations involving replication setup, application drivers, connection pooling, unsupported schema changes during CDC, and differences in branching behavior.

ClickHouse Managed Postgres now offers scheduled maintenance windows, allowing customers to choose a two-hour UTC period for platform upgrades, patches, feature updates, and underlying system maintenance rather than receiving them whenever releases are ready. Scale plan customers can select a time window, while Enterprise customers can also restrict maintenance to specific days of the week; Basic users can view the feature but must upgrade to use it. Schedules are configured through a service’s Settings and Configuration page and can be edited or removed, after which maintenance resumes as releases become available. The window applies only to provider-initiated maintenance, while user-requested changes occur immediately, urgent storage scaling proceeds if disk use exceeds 90%, and read replicas follow their primary service’s schedule.

PostgreSQL 19, still in beta at the time of writing, introduces four system views aimed at improving observability: pg_stat_lock provides cluster-wide cumulative lock-wait, wait-time, and fast-path exhaustion statistics by lockable object type, helping identify contention and partition-heavy workloads that may benefit from higher max_locks_per_transaction; pg_stat_recovery consolidates standby recovery details into a single atomic snapshot, including replay positions, timelines, pause state, transaction replay time, and promotion status; and pg_stat_autovacuum_scores reveals the per-table scoring system behind a new autovacuum prioritization model that ranks relations by transaction age, dead tuples, inserts, and analyze staleness, with configurable component weights. The smaller pg_dsm_registry_allocations view exposes dynamic shared memory registry allocations used increasingly by extensions that need shared state without requiring preload configuration or a server restart. Together, these additions expand SQL-accessible monitoring data for locks, replication, maintenance, and extension memory, though final behavior and naming may still change before the PostgreSQL 19 general release.

ClickHouse has announced the general availability of its MySQL and MariaDB CDC connector for ClickPipes, enabling managed replication of operational database data into ClickHouse Cloud for analytical workloads. The release follows production use across hundreds of customers and more than 1 PB of transferred data, and introduces automatic parallel snapshotting that detects primary-key partitioning options, including string and UUID keys, reducing large initial loads and resyncs substantially. New production safeguards require GTID-based replication by default and at least 72 hours of binlog retention for new pipelines, improving recovery after failures and failovers compared with legacy file-position replication. Enhanced UI and Prometheus metrics provide CPU, memory, network throughput, and source, destination, and end-to-end replication lag visibility to support troubleshooting and scaling decisions. MySQL CDC ClickPipes can also be provisioned and managed through the Cloud API and Terraform version 3.14.0 or later, while billing became active on September 1, 2026 under a volume-based model with shared service compute costs.

ClickHouse has acquired RunReveal, a security data platform built on ClickHouse, to bring its security expertise in-house while continuing to support independent companies building security products on the database. The acquisition reflects the demanding nature of security workloads, which require high-throughput ingestion of diverse telemetry, long-term retention, efficient storage, and rapid querying for investigations and threat detection. ClickHouse says the combined team will improve security-focused reference architectures, schema and retention guidance, and product roadmap feedback, while RunReveal will remain available through its bring-your-own-database model and existing customers will retain support and contract terms. The companies also emphasize the growing importance of security data for monitoring AI agents and defending against machine-speed threats, with RunReveal’s agentic investigation capabilities expected to help inform future analytics support across the ClickHouse platform.

ClickHouse has released data-agent-mnist, an open, reusable benchmark harness for evaluating agentic analytics models against a company’s own data warehouse, using 201 anonymized and synthetically reconstructed questions drawn from production traffic of its internal DWAINE assistant. Unlike conventional text-to-SQL tests, the benchmark evaluates agents that must discover schemas, plan across multiple steps, execute queries, and return correct result sets, with ground truth established through agreement among models from Anthropic, OpenAI, and Google and answers judged by a provider-diverse panel. In tests of 28 models, Claude Fable 5.1 achieved the highest correctness score at 76.6%, while several open-weight frontier models ranked highly and DeepSeek V4 Flash offered a much cheaper option, scoring 65.7% for roughly $1 per full evaluation compared with $52 for Fable 5.1. The findings suggest that model performance depends strongly on the specific warehouse and workload, that discovering relevant tables is often more difficult than writing executable SQL, and that incorrect planning accounts for most failures. The project also includes privacy safeguards, contamination testing, deterministic data generation, and scripts intended to let organizations create repeatable, tailored benchmarks and compare future models under consistent conditions.

Uken Games, a Toronto-based mobile game studio serving millions of players, replaced Datadog with an observability stack centered on ClickHouse, OpenTelemetry, SigNoz, managed Prometheus, Grafana, and CloudWatch, cutting annual monitoring costs by 87% to about $12,000. The company distinguishes product analytics, which measures engagement and retention, from technical observability, which tracks infrastructure performance, errors, and latency across hundreds of containers, machines, disks, databases, and service deployments. Its new vendor-agnostic trace pipeline uses lightweight OpenTelemetry agents on ECS instances and scalable gateway collectors to filter, batch, and send data through SigNoz to a single ClickHouse node, which stores all traces in roughly 170 GB. Uken retained CloudWatch for logs, used AWS-managed Prometheus for metrics, and automated Grafana alerts through code, enabling hundreds of alerts and frequent queries across its systems. The migration also prompted the team to reduce unnecessary telemetry by retaining errors and slow requests, sampling successful traces, basing alerts on unsampled aggregate metrics, and limiting retention to two weeks, while achieving feature parity with its former platform without downtime.