Other Table Engines

Almost everything in this module assumes MergeTree — and for real analytical tables, that assumption is correct. But ClickHouse ships several other table engines for narrower jobs, and knowing they exist saves you from reinventing them with a MergeTree table that doesn't need any of MergeTree's machinery.

Log family — simple, single-writer, no index

TinyLog, Log, and StripeLog store columns with no sorting, no primary key, and no support for concurrent writes. In exchange, they have almost no overhead — no merges, no index to maintain. They fit small, rarely-written tables: staging data mid-pipeline, lookup tables loaded once at startup, temporary scratch tables in a script.

CREATE TABLE staging_batch
(
    id    UInt64,
    value String
)
ENGINE = StripeLog;

Memory — no disk at all

Memory tables live entirely in RAM and are wiped on restart. Useful for genuinely temporary data within a session or a script — never for anything that needs to survive a restart, by design.

Null — a table that discards everything

Null accepts any INSERT and keeps nothing. That sounds useless until you pair it with a materialized view: the view's trigger still fires on every row inserted into the Null table, so you get the transform-and-store behavior of the view without ever paying to store the raw input itself.

CREATE TABLE raw_events (payload String) ENGINE = Null;

CREATE MATERIALIZED VIEW raw_events_mv
TO events_summary
AS SELECT count() AS cnt, toStartOfMinute(now()) AS minute
FROM raw_events;

Merge — a query-time union, not a materialized copy

Merge defines a virtual table over every existing table whose name matches a regular expression — typically a family of tables sharded by month or by source. Querying it is a live UNION ALL across the matching tables; nothing is precomputed or stored, which is the key difference from a materialized view.

CREATE TABLE events_all
ENGINE = Merge(currentDatabase(), '^events_2026_');

View — a named query, nothing more

View stores a SELECT statement under a name; querying it re-runs the underlying query every time, identically to just writing that SELECT out by hand. It holds no data of its own.