ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →
Engineering

ClickHouse JDBC support — columnar OLAP SQL through the standard database interface

ClickHouse joins the platform's multi-database JDBC layer as the first columnar OLAP engine. A complete SQL dialect covers ClickHouse's distinctive surface — date arithmetic, Nullable column semantics, OLAP aggregates, lateral joins and materialised views — through the same XSQL, workbench and virtual-table interfaces the OLTP engines already use.

ClickHouse is the dominant open-source columnar engine for analytical workloads : insert rates in the hundreds of millions of rows per second, sub-second query latency on billions-of-row datasets, a SQL surface that covers window functions, array processing and OLAP-specific aggregates. Connecting it through the platform's JDBC layer extends every capability the platform builds on top of a database connection — XSQL scripts, the database workbench, virtual tables, schema introspection, the federated query engine — to the columnar OLAP surface without additional integration work per capability.

Dialect implementation

  • Date arithmetic. ClickHouse's date functions differ significantly from the SQL:2003 baseline — toDate, addDays, toStartOfMonth, dateDiff and their typed-argument requirements do not accept the expression forms that work on PostgreSQL, Oracle or SQL Server. The platform's XSQL date-function layer translates to the ClickHouse equivalents transparently ; XSQL scripts that compute date ranges run on ClickHouse without modification.
  • Nullable column semantics. ClickHouse's Nullable(T) wrapping type affects index behaviour, comparison semantics and which function signatures accept the column. The dialect declares and resolves nullable columns so the platform's schema editor and JDBC result-set mapping handle them consistently with the OLTP engines.
  • OLAP aggregate functions. ClickHouse-specific aggregates — quantile, countIf, sumIf, groupArray, uniq — are reachable from XSQL scripts that target a ClickHouse connection. The engine does not attempt to translate these to generic SQL ; on a ClickHouse connection, the script author has the full ClickHouse aggregate vocabulary available.
  • Lateral joins and materialised views. Lateral join support and materialised view creation are included in the initial dialect, covering the two structural constructs most commonly needed in analytical schema design on ClickHouse.

Integration surface

  • Database workbench. ClickHouse databases appear in the Studio workbench alongside the OLTP connections — the same tree browser, the same query panel, the same table editor. Schema introspection covers MergeTree table families, column types including Nullable and LowCardinality, and the distributed table surface.
  • XSQL scripts on ClickHouse connections. An XSQL script that opens a connection to a ClickHouse server operates through the full XSQL language — variables, iteration, conditionals, subqueries — against the ClickHouse SQL dialect. The dialect layer handles translation where translation is possible and passes through ClickHouse-native syntax where it is not.
  • Virtual table coverage. Platform virtual tables can be backed by a ClickHouse query, exposing analytical aggregates as browsable, role-secured tables in the application layer without building a dedicated API surface.

ClickHouse integration complements the platform's existing OLTP engine support. A common architecture places the transactional record of truth in an OLTP engine and the historical analytical dataset in ClickHouse ; the platform now spans both within the same XSQL script, the same workbench session and the same federated query — without a separate integration layer between the two systems.

← All posts