Terraform State Is a Graph, Not a File

Terraform’s file-based state model imposes a global lock and whole-file reads for small, localized changes, causing contention and slow refreshes at scale. Stategraph treats state as a graph and applies established distributed systems techniques—MVCC, subgraph isolation, and ordered locking—to enable parallelism and scope refreshes to affected subgraphs. Implemented on PostgreSQL and compatible with Terraform’s remote backend, it eliminates lock bottlenecks and makes state queryable and auditable.

Key Points

• Terraform’s file-based state with a global lock creates systemic contention and scalability issues because operations typically touch only a small subgraph of resources.
• Splitting state files is not a real fix; it multiplies coordination problems and introduces distributed transaction complexity across states.
• Representing state as a graph enables subgraph isolation, precise row/edge-level locking, and MVCC, allowing safe parallelism and non-blocking reads.
• Graph-aware refresh limits work to the affected change cone instead of traversing the entire state, yielding significant performance gains.
• Stategraph implements this model using PostgreSQL (resources, dependencies, transactions) while remaining protocol-compatible with Terraform/OpenTofu and requiring no config changes.

Sentiment

Generally positive and constructive. The community acknowledges the problem is real for large-scale infrastructure teams, and the Stategraph developers' active engagement earns goodwill. However, significant skepticism exists about whether most organizations actually face these scaling challenges, with many commenters suggesting the problem can be avoided through better practices or architectural choices.

In Agreement

• The graph representation naturally maps to infrastructure dependencies and enables better visualization, querying, and reporting of state
• Splitting state files is a hacky workaround that creates cross-state dependency and orchestration problems
• Shared resources like VPCs, IAM, and databases always create contention regardless of how you split state
• A drop-in solution that fixes performance without requiring code changes would be valuable for teams at scale
• Terraform Cloud doesn't actually solve the problem since it still uses the same global lock model on a single blob

Opposed

• The simplicity and transparency of flat state files is a genuine strength — they're easy to read, manipulate, and troubleshoot
• The scaling problem is an antipattern: scope should be smaller, with tens or hundreds of resources per state, not thousands
• State files are a cache, not a source of truth — treating them otherwise is the real mistake
• If you need thousands of resources in one state, you've outgrown Terraform and should move to controller-based approaches
• Relying on non-authoritative state for querying and reporting can be unreliable