Project OCI-based Helm chart registry storage needs as chart artifacts accumulate.
Since Helm 3.8, charts can be pushed to any OCI-compliant registry (`helm push`) as OCI artifacts made up of content-addressable layers, typically a small config layer plus one or more content layers holding the packaged chart. Because layers are addressed by content digest, identical layers shared across chart versions — common when only a few files change between releases — are stored once, so real-world storage is the raw layer total scaled down by however much cross-version content actually overlaps.
dedupedStorage = charts × versions × layersPerVersion × avgLayerSize × deduplicationRatio
A classic repo (index.yaml + .tgz files) stores every version as a fully independent blob with no sharing; an OCI registry stores content-addressable layers, so bytes identical across versions (e.g. an unchanged Chart.yaml or templates directory) are only stored once registry-wide.
Charts with frequent patch releases that only tweak a few values or one template tend to dedupe well since most layer content is unchanged; charts that regenerate large CRD bundles or vendored dependencies on every release dedupe poorly.
No — dedup effectiveness depends on the registry's blob storage backend and garbage collection behavior; some registries dedupe globally across all repositories, while others scope deduplication per-repository.