Solution

Stop waiting on
Terraform & OpenTofu plans

Stategraph transforms Terraform/OpenTofu planning from a full-state operation to an intelligent, incremental process. Only refresh what changed. Only plan what matters.

Subgraph Execution Incremental Updates
Incremental
Planning
Minimal
Resources Refreshed
0
Unnecessary API Calls

Real-time Planning Comparison

Traditional Backend

$ terraform plan
Refreshing state... [2847 resources]
3m 47s elapsed...
Still refreshing: aws_instance.web[142]

Stategraph

$ stategraph plan
Computing change cone... [12 resources]
✓ Plan ready in 2.3s
Skipped 2835 unchanged resources

How It Works

1

Graph-Based State

Terraform/OpenTofu state stored as a directed acyclic graph in PostgreSQL. Resources and dependencies become queryable entities with row-level locking instead of a monolithic file.

2

Subgraph Isolation

Changes compute the minimal affected subgraph through dependency traversal. Refresh and plan operations only touch resources in the change cone, not the entire state.

3

Granular Locking

Lock acquisition follows the dependency graph with topological ordering. Teams can modify independent subgraphs simultaneously without blocking each other.

4

MVCC Transactions

PostgreSQL's multi-version concurrency control enables consistent reads without blocking writes. Multiple operations proceed in parallel on non-overlapping resource sets.

performance-comparison.sh
$ # Example: Large infrastructure, single resource change
 
$ terraform plan -target=aws_security_group.app
Refreshing Terraform state in-memory prior to plan...
... (refreshing all resources)
Plan: 0 to add, 1 to change, 0 to destroy.
 
$ stategraph plan aws_security_group.app
→ Computing dependency cone for aws_security_group.app
→ Identified subgraph: 8 resources
→ Executing plan on subgraph
Plan: 0 to add, 1 to change, 0 to destroy.
 
Only processed affected resources, not entire state

The Algorithmic Advantage

Traditional backends: O(n) where n = total resources

Stategraph: O(k) where k = resources in change cone

Most infrastructure changes affect a small subgraph. By traversing only the dependency cone instead of the entire state, operations complete proportionally faster.

This isn't parallel orchestration or smarter locking—it's fundamental graph evaluation at the storage layer. Even single-user CI pipelines see dramatic speedups because we only process the changed subgraph.

Stop coordinating. Start shipping.

Resource-level locking. Graph-based state. SQL queries on your infra.
Teams work in parallel. No more lock contention.

Get Updates Become a Design Partner

// Zero spam. Just progress updates as we build Stategraph.