The global state lock is the wrong primitive
In Terraform, one engineer touching one resource blocks everyone else on that state — even on completely unrelated resources. The lock is on the file, not on what you're actually changing.
Two applies, same state, same moment
An illustrative scenario: two engineers apply against the same state at the same time. Because their changes touch different resources, Stategraph locks each subgraph independently — neither waits on the other.
❯ stategraph apply # editing aws_instance.web Locking aws_instance.web… Apply complete ✓
❯ stategraph apply # editing aws_security_group.app Locking aws_security_group.app… Apply complete ✓
Same state, same moment. Different resources → no waiting.
A lock that fits the change, not the file
What you get
Subgraph locks
Stategraph locks the exact resources your change touches — not the whole state file. The blast radius of a lock is the blast radius of your change.
Parallel disjoint applies
When two changes touch different resources, they run at the same time. No queue, no waiting your turn behind an unrelated apply.
Conflict only on overlap (409)
You only hit a conflict when two changes genuinely touch the same resource. Stategraph returns an HTTP 409 so you can re-plan and retry.
MVCC snapshots
Reads work against a consistent snapshot, so reading state never blocks a writer and a writer never blocks a reader.
Scales with team size
More engineers on one state doesn't mean more time spent in the lock queue. Contention tracks real overlap, not headcount.
No state splitting needed
Stop carving state into tiny files just to dodge the global lock. Keep one coherent state and run changes in parallel.
Stop queueing behind each other
Keep one state for the whole team and let disjoint changes run in parallel. Real overlap is the only thing that ever has to wait.
See more in all features · parallel execution →