You flip a bundled database subchart off on a live Helm release. What happens to the objects it already deployed?

### What an upgrade actually removes Helm stores the rendered manifest of every revision in the release record. When you upgrade, it renders the new manifest and works out three sets: objects that are new, objects that exist in both, and objects present in the old manifest but absent from the new one. That third set is deleted. Nothing about that logic is special-cased for subcharts - a dependency whose condition flipped to false simply stops producing output, so every object it used to produce lands in the delete set. That is the correct behaviour and it is what makes a chart declarative, but it means "switch the bundled database off" and "delete the bundled database" are the same operation. If the subchart rendered a PersistentVolumeClaim, that claim is in the old manifest, and it goes. The complement is equally important: objects Helm never rendered are not in the manifest, so Helm never deletes them. A claim created by a controller on the chart's behalf rather than by a template is invisible to this diff and will be left behind, orphaned. Which of those two applies to your bundled datastore is a question about that specific chart's templates, and the only reliable way to answer it is to look at the manifest the release recorded. ### A worked cutover A billing platform runs twelve service charts that all depend on a shared library chart for their helper templates. One of them, the subscription-billing chart, bundles a database subchart so a developer gets a working stack from a single install. Production is moving to a managed database, so the switch has to be flipped on a release that has been running for months. Done carelessly - one upgrade that changes the external host and sets the condition false at the same time - the upgrade deletes the in-cluster database in the same operation that repoints the application at a host nobody has verified. Done carefully, it is three steps: 1. **See the blast radius.** Render the chart with the new values and diff it against what the release currently has. The output names every object that disappears. Read that list out loud before doing anything. 2. **Migrate and cut over first.** Point the workload at the external database, in its own revision, while the bundled one is still running and still holds the data. Verify the cron and the request path actually work against it. The cutover in our case cost 96 seconds of write pause, planned and announced. 3. **Disable in its own revision.** Only then flip the condition, with nothing else in the diff. A revision that changes exactly one thing is a revision you can reason about, and its predecessor is a coherent state to roll back to. ### Keeping something on purpose `helm.sh/resource-policy: keep` is the annotation that exempts a resource from deletion when a Helm operation would otherwise remove it. It has to be on the resource as the chart renders it - it is a property of the manifest, not something you can bolt on afterwards and expect Helm to notice. Kept resources survive, but they stop being managed: the release no longer tracks them, nothing reconciles them, and a later attempt to have the chart own that name again meets an object already sitting there without the release's ownership metadata. Helm refuses that adoption by default; `--take-ownership` exists to force it, and reaching for it should be a deliberate decision rather than a reflex. ### Rollback is not undelete Rolling back to the previous revision re-renders that revision's stored manifest and re-applies it, so the subchart's objects come back - empty. A rollback restores object definitions, never the contents of storage that was released with them. Treat the data as gone the moment the claim is deleted, and plan the backup accordingly. ### What does not change Disabling a dependency changes only rendering. The entry stays in `Chart.yaml`, the pin stays in `Chart.lock`, the archive stays under `charts/`, and the packaged chart still ships it - so re-enabling it later is a values change, not a repackage. That asymmetry is the feature: one chart, two shapes, and no fork to maintain across a fleet of services.