ClickHouse's LowCardinality type applies dictionary encoding to columns, replacing repeated string values with compact integer indices. It delivers significant storage and query performance gains on columns with fewer than ~10,000 distinct values (e.g., log level, service name, region, HTTP method). However, it actively hurts performance on high-cardinality columns like trace IDs, span IDs, user IDs, and raw log messages, where the dictionary grows as large as the data itself, adding overhead with no compression benefit. Production data from Last9 shows LowCardinality columns like ServiceName and SeverityText achieving ~372-376x compression, while plain String columns like TraceId achieve only ~25x. A key nuance: pod_id looks low-cardinality at any instant but accumulates high cardinality over time as pods are recreated. The guidance is to measure column cardinality with uniqExact() before deciding, and to apply LowCardinality column-by-column rather than as a blanket optimization.
