Setting the file. One moment.
Chapter 03 · Clickhouse Architecture Advisor
Subchapter 3.10
rules/decision-join-enrichment.mdMarkdown2 KBView on GitHub
Not every dimension lookup should remain a runtime JOIN. The right design depends on dimension volatility, cardinality, and the cost profile of repeated enrichment.
| Condition | Recommendation | Category |
|---|---|---|
| Small, slowly changing lookup table used in many queries | Dictionary | official |
| Dimension is naturally embedded and storage duplication is acceptable | Denormalize | derived |
| Join logic is complex and refreshed on a schedule | Refreshable MV | official |
| Query is exploratory or infrequent and dimensions change often | Runtime JOIN | official |
Why Dictionaries are often the best fit for repeated key-based enrichment when the lookup data is relatively static.
Official sources
query-join-consider-alternativesWhy If the dimension is stable and queried constantly, denormalization may outperform repeated joins.
Category derived
Official context
Why Precomputed enrichment is often better than expensive runtime joins for recurring production queries.
Official sources