Welcome from weekly.tf. Thanks for clicking through — here’s the benchmark we’re running on.
Same Terraform. No HCL changes.

Your terraform plan shouldn’t get slower as your infra grows.

But it does. The state file is one lock, one blob, one plan over everything you own. We replaced it with a PostgreSQL-backed dependency graph. Plans run on the affected subgraph.

14-day free trial · No credit card · Drop-in for Terraform & OpenTofu

Benchmark No-op plan · 800 MB state · 4,200 resources
terraform
~3 hours
stategraph
97s

The unit of work is your change, not your environment.

The problem

Why terraform plans get slow at scale

The flat state file is one document over everything you own. Doubling your infra doubles your plan time — even when your change touches three resources.

One lock

One operation at a time

The state lock is global. Two engineers changing unrelated resources still wait in line. Long applies block every other apply.

One blob

800 MB of JSON, parsed every plan

The file grows linearly with your infra. Every plan deserializes it, every apply rewrites it. Network and disk dominate before refresh even starts.

One plan

Refresh over everything you own

Terraform refreshes every resource to detect drift. A three-resource change still walks all 4,200. Plan time is a function of infra size, not change size.

The fix

Plans run on the affected subgraph

Underneath your HCL, the flat state file becomes a Postgres-backed dependency graph. The planner walks the graph from your change outward and refreshes only the resources that can be affected.

The change cone

Every plan starts by computing which resources your change can reach. For most diffs that’s a handful of resources, not your whole environment. Refresh that subset. Plan. Apply.

  • Plans become O(change size), not O(infra size).
  • Resource-level locks — disjoint changes don’t block each other.
  • Same providers, same modules, same .tf files.
stategraph plan
$ stategraph plan
Computing change cone…
12 of 4,218 resources affected
Refreshing 12 resources…
Plan ready in 2.3s
Concurrent

Two engineers, one state, no waiting. Resource-level locks replace the global state lock.

Queryable

Ask in SQL. “How many public S3 buckets do I have?” is a query, not a grep over 140 state files.

Governable

One audit log. CLI, CI, and AI agents hit the same graph with the same policies.

Adoption

Keep your Terraform. Get a database underneath it.

Stategraph delegates to the native terraform or tofu binary. Your .tf files, your modules, your providers, your CI — unchanged.

Before
$ terraform plan
$ terraform apply
After
$ stategraph plan
$ stategraph apply

One-time import: stategraph import tf terraform.tfstate. Then plan and apply as usual.

Stategraph Cloud

Single-tenant SaaS. We run the Postgres.

Sign up, import a state file, run your first subgraph plan in minutes. No database to provision, no infra to maintain.

Onboarding

From tfstate to graph in minutes

stategraph import tf terraform.tfstate brings in your state, builds the graph, and lets you plan against it immediately.

Managed

Single-tenant Postgres, fully managed

Your state lives in its own isolated database. Backups, upgrades, and scaling — handled.

Insights

Ask your infra questions in SQL

Search resources, explore the dependency graph, compute blast radius. Built on the same Postgres that runs your plans.

Try it on your state.

14-day free trial. No credit card. Import an existing tfstate and run your first subgraph plan.

Also available: self-hosted and BYOC on Enterprise. See Enterprise →