OCSF storage strategies for your security lakehouse
arrow_backTo the overview07 August 2026 | Tenzir GmbH
How should you lay out OCSF events in Iceberg? We survey the storage strategies the OCSF community is converging on, explain why wide sparse tables are cheap in Iceberg but expensive in ClickHouse, and show how one line of TQL turns the recommendation into a running lakehouse.
The Open Cybersecurity Schema Framework (OCSF) defines what a normalized security event looks like: its normative form is JSON. It deliberately says nothing about how to store events for analysis. That question lands on every security data engineer the moment the first OCSF-mapped events flow: one table or many? Flattened or nested? Partitioned by what?
The OCSF community is now tackling this head-on. Paul Agbabian’s storage strategies article surveys the table layouts practitioners use for OCSF events in Parquet and Iceberg. We contributed to that discussion and want to expand on one aspect here that deserves more attention: the choice of storage engine changes which strategy is right, and the answer for Iceberg differs from the answer for OLAP engines like ClickHouse. We conclude with a blueprint for shipping OCSF into an Iceberg lakehouse with Tenzir.
This article is written by:
Tenzir GmbH
In a world where security data is often locked behind rigid platforms, soaring expenses, and proprietary formats, we believe in a different future, one where data flows freely, without constraints.
Security data should be a strategic asset, not a vendor-controlled burden. Every organization deserves powerful, intuitive tools that make security data accessible, illuminating, and actionable, without the headaches of complexity, silos, or unpredictable costs.
We exist to redefine how security teams process, analyze, and act on their data. Our approach is simple: build composable pipelines t