Apache Iceberg with a versioned catalog, on your own storage

Why the format is the decision that matters

In a classic warehouse your tables sit in a format only that warehouse reads. Moving to another vendor is then not a configuration step but an export project. Iceberg inverts that: a table is Parquet files plus an openly specified metadata layer. Spark, Flink and Trino read the same table without anyone copying anything.

For a product whose promise is data sovereignty, that is not a side detail. Sovereignty is not only about the disk sitting in your own server room — it also means you can keep using the data without the vendor's cooperation.

An open location and an open format are two different things. Only both together add up to independence.

The catalog is versioned

Above the Iceberg tables sits Nessie — a catalog that behaves like Git. There is a main branch, there are points in time, and there is the option to query an earlier state without touching the current one. In practice: a reporting date stays reproducible even though the table has been written to since.

-- Current state
SELECT count(*) FROM lakehouse.raw.orders;

-- The same view, as of August 1
SELECT count(*) FROM lakehouse.raw.orders
FOR TIMESTAMP AS OF TIMESTAMP '2026-08-01 00:00:00';

The difference from a database backup is substantial. Point-in-time recovery rolls an entire cluster back to a moment. Time travel queries a single table as of a moment while everything else stays current — in production, from an ordinary query.

Storage and compute are separate

The data sits in object storage and the engine reaches it from outside. That is the same architectural principle cloud warehouses use — except both halves are yours. Storage grows without compute having to grow with it, and the other way round.

For evaluation lavalake bundles MinIO, so the whole stack runs on one machine. In production you point it at the object storage you already operate instead.

What Trino enforces along the way

Every statement runs under the exchanged token of the logged-in user. Trino's own grants and the row-access and masking policies therefore decide what lands in a result set — not the interface that submitted the query. That chain is why search results and dashboard tiles can differ per viewer.

• ACID transactions at table level
• Schema evolution without rewriting the table
• Time travel and branching through the Nessie catalog
• Partitioning that may change without touching old data
• Elastic compute clusters with auto-suspendIn development