By Matthieu Caillaud · Founder, oceanographer
"Zarr is faster than NetCDF" is not a question that a single number can answer. We took ten years of ERA5 reanalysis over the North Atlantic (2014-2023, five variables: significant wave height, direction and period, and 10 m wind), rechunked the same dataset three different ways, and measured six read scenarios representative of maritime routing across all four sources — the monolithic NetCDF and the three Zarr stores. The result is not "Zarr wins": it is that the chunk layout that wins depends entirely on the access pattern, and a poorly chosen Zarr chunking can be markedly slower than the plain NetCDF it was meant to replace.
Three ways to chunk the same dataset
A NetCDF4 file can also be written with configurable chunking, compression, and dimension layout; this benchmark compares a monolithic NetCDF with three Zarr organizations. xarray can load the file lazily, but the physical data on disk is not organized around any particular access pattern. Zarr, by contrast, requires choosing chunk sizes along each dimension (time, latitude, longitude) at write time. That choice fixes how every subsequent read will hit the disk. We wrote the same ERA5 dataset under three chunk layouts:
- routing
- chunks (time=1, lat=40, lon=40) — built for an instantaneous map or a corridor extraction at a given time.
- timeseries
- chunks (time=-1, lat=1, lon=1) — built for the full history at a single point (waypoint).
- balanced
- chunks (time=24, lat=20, lon=20) — a compromise that does not favor either axis.
The six measured scenarios reproduce real routing workflows: rendering a significant-wave-height (Hs) map at a given time, a full time series at a waypoint, extracting a wide bounding box covering a route, extracting a narrow corridor (±1°) along a Brest → Azores → Canaries → Dakar polyline, reading four waypoints simultaneously (typical of an isochrone computation), and a seven-day weather window over a restricted domain. Each measurement is the median of five reads, with the dataset reopened between runs.
When the chunking matches the access pattern: two clear gains
For an instantaneous map — a single time step, the full spatial domain — the routing store responds in 0.011 s, against 0.031 s for the monolithic NetCDF. That is consistent with its geometry: its compact spatial chunks (40×40) and unitary time chunk mean a single time slice only touches a fraction of the store.
For a ten-year time series at one waypoint, the gap is of a different order. The timeseries store — chunked precisely to hold a single point's entire history in one block — responds in 0.011 s at the Brest waypoint and 0.015 s at the Azores waypoint, against 1.33 s and 1.47 s for the monolithic NetCDF. The pattern holds and amplifies on a related workload: reading four waypoints at once (an isochrone-style access) takes 0.046 s on the timeseries store, against 4.91 s in NetCDF.
In both cases the common factor is the same: the chunk shape matches the query shape. A map reads one full time step; the routing store stores one time step per chunk. A time series reads one point across the full duration; the timeseries store stores one point per chunk. Nothing magical — a geometric alignment.
When the chunking does not match: Zarr slower than the NetCDF it was meant to replace
This is the point most Zarr demonstrations leave out. A Zarr store poorly chunked for a given scenario does not just underperform a well-chunked one — it can be slower than the monolithic NetCDF it started from.
For the time series at the Brest waypoint, the routing store — chunked time=1, one chunk per time step across ten years — responds in 4.70 s, against 1.33 s for NetCDF. Reading ten years of history at a single point means opening thousands of single-time-step chunks: the access overhead outweighs the format's advantage. The same effect shows up on the instantaneous map with the timeseries store — chunked the opposite way, one point per chunk: 2.66 s to read a single time step across the full domain, against 0.031 s in NetCDF. Every distinct spatial cell requires opening its own chunk.
The narrow routing corridor extraction (±1° band along the polyline, ten years) confirms the pattern: the timeseries store, this time well matched to the workload — access concentrated on few spatial points, full duration — responds in 0.50 s, against 1.79 s for NetCDF. But the routing store, chunked for the opposite workload, takes 8.14 s — well above reading the same corridor from NetCDF. On the wide bounding box covering the whole route (a bulk-read pattern, structurally unfavorable to fine chunking), NetCDF stays competitive at 3.59 s, the timeseries store edges slightly ahead at 2.00 s, but routing and balanced climb to 6.82 s and 5.49 s respectively.
The balanced compromise, and the zone where format barely matters
The balanced store (time=24, lat=20, lon=20) never wins the best time on any scenario, but it never posts the worst either, with one exception (the wide bounding box). At the Brest waypoint it responds in 0.45 s — clearly behind the timeseries store's 0.011 s, but clearly ahead of the routing store's 4.70 s. On the instantaneous map it responds in 0.091 s — behind routing's 0.011 s, but nowhere near the timeseries store's mismatched 2.66 s. That is the value of a balanced chunking: it never maximizes any single scenario, but it avoids the deep failures on scenarios it was not designed for.
One last scenario deserves mention for its honesty: a seven-day weather window over a restricted domain around the Azores. Here NetCDF (0.028 s) and Zarr routing (0.037 s) sit in the same order of magnitude, and the balanced store (0.031 s) does no better than NetCDF. Below a certain extraction size — few time steps, small domain — the storage format stops being the dominant factor. Rechunking only pays off where the access pattern makes NetCDF's native layout structurally unsuited to it; for a small, one-off extraction, the question barely arises.
The operational conclusion fits in one sentence: do not choose Zarr against NetCDF, choose a chunking for an access pattern. A Zarr store designed for maps should not serve time series, and vice versa — in both directions, the cost of the wrong layout is measured in seconds, not milliseconds. If your pipeline serves several access patterns from the same dataset, you will need either several rechunked stores in parallel, a deliberate balanced compromise, or — to settle which data to use in the first place, before the storage question even comes up — which ocean data for which need.
Sources and references
The metrics, comparisons and maps specific to this article are OceanData Consulting results and calculations; the links below document the datasets, standards and publications used.
Facing a similar modeling or metocean data challenge?
From physical model calibration to operational AI post-processing, we help turn marine observations into validated, decision-ready forecasts.
Frequently asked questions
Is Zarr always faster than NetCDF?
No. On the ERA5 benchmark (10 years, North Atlantic), a Zarr store poorly chunked for the tested scenario can be slower than the monolithic NetCDF — for example 4.70 s for a time series on the routing store, against 1.33 s in NetCDF for the same waypoint.
How do you choose a Zarr chunking for maritime routing?
Based on the dominant access pattern: chunks (time=1, lat=40, lon=40) for instantaneous maps or corridors, chunks (time=-1, lat=1, lon=1) for a waypoint time series, or a balanced compromise (time=24, lat=20, lon=20) if the pipeline serves several workloads.
Does rechunking help on every extraction?
No. On a small extraction (a 7-day weather window over a restricted domain), NetCDF (0.028 s) and Zarr (0.031 to 0.037 s depending on the store) stay in the same order of magnitude: below a certain extraction size, the storage format stops being the dominant factor.