Skip to content
Calcrivo

Terraform State Growth Calculator

Project monthly Terraform state file growth from new resources added and average state size per resource.

Inputs

resources/mo

Average resources added to this state per month.

KB

Average JSON-serialized state size contributed by one resource.

MB

Current size of the state file, for projecting forward.

months

How many months ahead to project state size.

State Growth per Month

0.059MB/mo

Projected State Size

3.70MB

State Growth per Month

60.0KB/mo

Step by step

  1. Growth/month: new resources × avg size

    15 × 4KB

    = 60.0KB

  2. Projected state size

    3MB + 0.059MB × 12

    = 3.70MB

How it works

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.

Formula

projected_size_MB = current_size_MB + (new_resources_per_month × avg_state_per_resource_KB / 1024) × projection_months

current_size_MB
Current state file size (MB)
new_resources_per_month
Resources added per month
avg_state_per_resource_KB
Average state contribution per resource (KB)
projection_months
Months to project forward

Frequently Asked Questions

At what state size should I worry about performance?

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.

Why do some resources contribute more to state size than others?

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.

Does state growth affect apply time?

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.

How do I reduce future state growth?

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.

You might also need