Other Table Engines
Log, Memory, Merge, View, Null
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.
"View" and "Materialized View" share a name but do opposite things:
a View is pure syntactic sugar, computed at query time, zero
storage cost, always fresh. A
Materialized View is an insert
trigger that precomputes and physically stores results — real
storage cost, real staleness bounded only by insert timing, much
faster to read. Confusing which one you created is a common and
costly mistake.
None of these engines replicate, shard, or maintain a primary key the way MergeTree does. Reach for them only when the job is genuinely small, temporary, or purely structural (routing/union) — the moment a table needs to hold real analytical data at scale, it belongs on a MergeTree variant.