Icechunk, illustrated
Small browser visualizations that explain how Icechunk behaves, and why it's different from plain Zarr on cloud storage. Each one is interactive and embeddable.
Schrödinger’s chunks
Consistency & isolation
A writer overwrites a cat chunk by chunk while two readers pull it back. Same code, same race; only the storage guarantees differ. Zarr returns a torn image; Icechunk returns a whole one.
Open visualization →The race condition
Concurrent writers & atomic commits
Three writers race to upload their own racer's image to the same array. In Zarr the chunk writes interleave into a patchwork of all three racers, so nobody can say who leads. In Icechunk each writer commits atomically, so the leader is always one whole racer.
Open visualization →Move without moving data
Metadata-only renames
Renaming a Zarr array on cloud storage means downloading every chunk and re-uploading it under the new key. In Icechunk, a move is a tiny edit to the array manifest; the chunks never travel.
Open visualization →Query the archive in place
Virtual chunks: NetCDF / GRIB & slides
A small slice of a big archive used to mean downloading whole files and throwing 99% of the bytes away. With VirtualiZarr and Icechunk, a tiny manifest maps each chunk to its bytes inside the archive, so the reader range-GETs only what it needs. Two examples: NetCDF / GRIB files, and gigapixel microscopy slides.
Open visualizations →Only the chunks that changed
Commits reuse unchanged chunks
A new "version" of a Zarr array on plain cloud storage usually means a fresh copy of every chunk. In Icechunk, a commit writes full new objects only for the chunks that actually changed; the rest keep pointing at the objects already in storage.
Open visualization →