Apache Iceberg: registret du kan ta med dig

En koncern förvärvar ett företag. Köparen kör sin rapportering på Snowflake; det förvärvade företaget höll sin data i sitt eget datacenter och frågade den med Trino. Integrationsplanen har en rad som säger “migrera datan”, och alla vet vad den raden kostar: ett år av kopiering, två uppsättningar siffror under tiden, och ett beroende av den plattform kopian landar i.

Alternativet är att registret finns i ett format båda sidor redan läser, med en katalog som koncernen kontrollerar. Apache Iceberg är för närvarande det format som flest rivaler är överens om, och skälet är inte sentimentalitet. Det är formen på dess metadata. Hurukans register är utformat för att vara flyttbart i precis den meningen, och datalagret som rymmer det är under uppbyggnad.

En tabell som ett träd, med en pekare

Iceberg beskriver en tabell som ett träd av filer som aldrig redigeras. Överst finns en tabellmetadatafil; den pekar på en ögonblicksbild; ögonblicksbilden pekar på en manifestlista; varje manifest listar datafiler och raderingsfiler med deras statistik. En ändring av tabellen skriver nya löv och en ny rot, och gör sedan en liten sak: den byter pekaren i katalogen från den gamla roten till den nya. Specifikationen gör det bytet atomärt.

Två konsekvenser följer. Varje rot som har funnits är fortfarande en komplett, läsbar version av tabellen, vilket är tidsresa (time travel), och i Hurukan är det svaret på “vad såg agenten när den föreslog det här”. Och flera motorer kan skriva till samma tabell säkert, eftersom det enda de tävlar om är pekaren.

Aktuell version är Iceberg 1.12.0 från september 2026 (kontrollerat den 21 oktober 2026). Version 3 av specifikationen är antagen: raderingsvektorer lagrade i Puffin-filer, radhärkomst, en typ VARIANT, geometrityper, nanosekunders tidsstämplar och standardvärden för kolumner. Version 4 är under utveckling och inte antagen.

Dold partitionering, och varför en analytiker aldrig frågar om den

Iceberg härleder partitionsvärden från kolumntransformer — dagen i en tidsstämpel, en hink av en identifierare — och registrerar transformen i metadatan. En fråga som filtrerar på tidsstämpeln beskärs till rätt partitioner utan att den som skriver den vet att partitioner finns. När volymen ändras kan partitionsspecifikationen utvecklas utan att datan skrivs om; gamla filer behåller den gamla layouten, nya filer får den nya, och båda läses korrekt.

För ett register som är tänkt att läsas av superintelligensen snarare än av människor som känner lagringslayouten spelar den egenskapen större roll än det låter. Ontologin kan kalla en tabell “betalningar” och lämna layouten till datalagret.

Katalogen är där suveräniteten sitter

Allt ovan är filer. Filer kan ligga på vilket objektlager som helst, även ett i företagets egen byggnad. Vad filerna inte kan göra är att tala om för en läsare vilken rot som är aktuell och om den här personen får läsa den. Det är katalogens jobb, och det är platsen där ett företag antingen äger sitt register eller hyr det.

Iceberg publicerar en öppen REST-katalogspecifikation: namnrymder, tabeller, vyer, commits, skanningsplanering och utdelning av autentiseringsuppgifter bakom ett HTTP-gränssnitt. Apache Polaris, en implementation av den, blev ett Apache-toppnivåprojekt i februari 2026 och släppte 1.8.0 i september 2026 (kontrollerat den 21 oktober 2026). Andra implementationer finns. Poängen är att en katalog kan köras på infrastruktur som företaget väljer, och att en motor från vilken leverantör som helst kan tala med den.

Så behandlar lagret för säkerhet och suveränitet registret: behörigheter upprätthållna i katalogen, på företagets egen server, för människor och agenter lika. En leverantörs motor som läser registret gör det med de autentiseringsuppgifter katalogen ger den, och inte mer.

Vem som läser det

Listan, från leverantörernas egen dokumentation den 21 oktober 2026: Snowflake läser och skriver Iceberg-tabeller upp till specifikation v3 och kan använda en extern REST-katalog; Amazon S3 Tables lagrar Iceberg inbyggt, inklusive v3; Googles lakehouse-katalog exponerar en Iceberg-REST-ändpunkt; Databricks erbjuder hanterade Iceberg-tabeller i Unity Catalog med en REST-ändpunkt. Spark, Flink, Trino och DuckDB läser det direkt.

För förvärvet i inledningen är den listan planen: ett register, på koncernens lagring, bakom koncernens katalog, läst av Snowflake på ena sidan och Trino på den andra, utan någon migreringsrad i budgeten.

Vad agenter gör här, och vad människor behåller

En agent kan utarbeta jobbet som utvecklar en partitionsspecifikation när volymen växer, komprimeringen som slår ihop små filer, utgången av gamla ögonblicksbilder när det bevarande företaget satt är nått. Vart och ett är ett förslag med ett testresultat, godkänt av en människa, registrerat som vilken annan ändring i Hurukan som helst.

Människor behåller de beslut som inte kan härledas: vilken katalog, och var den körs; vem som får läsa vilken namnrymd; hur länge historik behålls och när en persons data raderas för gott; och om en tabell ska flyttas till en nyare specifikationsversion, eftersom en läsare som inte känner v3 inte läser en tabell som använder det. Frågan om vilken data som alls får lämna byggnaden är en annan, som tas upp i Vilken data som inte får lämna huset.

Ett test du kan göra i dag

Fråga vem i ditt företag som den här veckan skulle kunna rikta en ny motor mot er viktigaste tabell och få den läst korrekt utan export. Om svaret innefattar ett supportärende hos en leverantör är registret ännu inte ditt.