The Infrastructure Velocity Problem
Every team hits these bottlenecks. They're not edge cases—they're architecture.
Lock Contention
Global state locks block everyone while one person plans a single resource.
Full State Refresh
Every plan refreshes all resources even when changing just one.
Terragrunt Slowdown
External orchestration across 100+ modules creates 15x slowdown.
CI/CD Serialization
Pipelines serialize deployments to avoid state conflicts.
The Speed Difference
Same infrastructure. Same change. Dramatically different wait time.
Measured on a real production state
An 800 MB state file from a partner's production environment. A no-op plan — the worst case, where Terraform has to walk the entire graph just to conclude nothing changed.
The work is proportional to the size of your change, not the size of your infrastructure. Plans stay fast as your state grows, because the state isn't what's being walked — your change is.
Single benchmark; results vary with state shape. Import scales too: 20,000 resources ingested in 3 seconds. How Stategraph handles terralith-size states →
What Makes Velocity Fast
Subgraph Execution
Only process resources affected by your change. The dependency graph tells us exactly which resources need to be evaluated—skip the rest.
Parallel Operations
When changes don't overlap, run them simultaneously—even inside the same root module. Multiple teams ship without waiting in a queue.
Resource-Level Locking
Lock only what you need. No more global state locks that block everyone while one person runs a plan on a single resource.
Incremental Refresh
Refresh only changed resources, not the entire state. For large deployments, this means seconds instead of minutes.
Efficient Remote State
Downstream states fetch just the outputs they reference—not entire upstream state files. Tiered setups stop paying to download hundreds of megabytes per plan.
Refactoring Built In
Rename resources or move them into modules—including for_each moves that moved blocks can't express. A refactor session records the rewrites; no three-step temp-name dance.
Cost in the Plan
Every plan can print a current-versus-planned cost delta inline, so reviewers see the diff and the price together. See Stategraph Cost.
SQL-Queryable State
Your infrastructure state lives in PostgreSQL. Query it directly, build dashboards, integrate with your existing tools.
Drop-in CLI
Replace `terraform` with `stategraph`. Same commands, same workflow, dramatically faster execution. Or point vanilla Terraform/OpenTofu at Stategraph's HTTP backend while you migrate.
How It Works
Traditional Backend
- ❌ Load entire JSON file
- ❌ Lock all resources globally
- ❌ Refresh everything serially
- ❌ One operation at a time
Stategraph Velocity
- ✅ Query only affected subgraph
- ✅ Lock only changed resources
- ✅ Refresh incrementally
- ✅ Parallel operations on independent resources
The key insight: When you run a plan, Stategraph computes the minimal "change cone"—only the resources affected by your changes. Independent subgraphs can execute in parallel, with resource-level locks that don't block unrelated work.
Two applies. One root module. Zero waiting.
Two engineers—or two pull requests—touching different resources in the same root module don't queue behind each other. Both plan, both apply, at the same time.
You're serialized on overlap, not on root modules. Stategraph locks the subgraph each change actually touches. If two changes do collide, the second is rejected at commit with the conflicting transaction IDs—instead of silently clobbering state or waiting on a file lock. How resource-level locking works →
Multi-State Transactions
One plan. One apply. All your states.
Most teams split infrastructure across multiple states for organization. But changes that cross state boundaries require multiple rounds of plan and apply. Nobody likes waiting through sequential orchestration.
Sequential Orchestration
4 operations
Sequential, incomplete visibility
Multi-State Transaction
txn_abc123
1 operation
Atomic, complete visibility
Why It Matters
True Blast Radius
See actual impact across all states in one plan
No Orchestration
No multi-step workflows or sequential waits
Keep Your Structure
State boundaries become code organization, not a correctness constraint
Example: Change an output in state A that state B consumes via remote state. With plain Terraform you apply A, then re-plan B to discover the fallout. Stategraph shows B's changes in A's plan—one unified plan, downstream impact included, before anything is applied. One apply then executes everything atomically. How cross-state plans work →
Large Infrastructure Is Natural. File Storage Isn't.
A VPC with thousands of resources and dependency edges isn't poor design—it's reality. Infrastructure is interconnected. The problem isn't the size. It's storing it as a flat file.
Interconnected Infrastructure
Traditional Workaround
- ❌ Split into 127 modules
- ❌ External orchestration
- ❌ Manual dependency wiring
- ❌ 15x performance penalty
The Stategraph Solution
Fast parallel plan/apply for Terraform. Start free today.