Project how Terraform state file size will grow as infrastructure scales.
Formula: growth_per_month = new_resources_per_month × avg_state_size_per_resource. Terraform state grows with resource count, not directly with infrastructure activity — a resource with many computed attributes (e.g. a large `aws_instance` with nested blocks) contributes more state bytes than a simple one. Projecting this forward helps anticipate when state size might start affecting plan/apply performance or backend limits.
projected_size_MB = current_size_MB + (new_resources_per_month × avg_state_per_resource_KB / 1024) × projection_months
Most teams don't notice issues until state reaches tens of MB with thousands of resources — at that point plan/refresh times and IDE tooling (e.g. state inspection) start to feel sluggish, which is a good trigger to consider splitting state.
Resources with large computed attributes, extensive nested blocks, or big `for_each`/`count`-generated attribute maps (e.g. IAM policy documents, security group rule lists) serialize to much more JSON than a simple resource like a single S3 bucket.
Indirectly — a larger state means more JSON to parse/write on every operation and typically correlates with more resources to refresh and plan against, compounding with the effects modeled in the refresh duration calculator.
Split large configurations into smaller root modules per logical boundary (network, compute, data) so growth in one area doesn't bloat a single shared state file.