Every layer of the stack got faster. Except infrastructure.

Application deployment got fast. CI pipelines got fast. Container orchestration got fast. Infrastructure provisioning did not. That's not an accident—it's architecture. Graph-based state with resource-level locking fixes it.

Parallel Plan/Apply Multi-State Transactions No Lock Contention 20K Resources in 3s
Request Access

The Infrastructure Velocity Problem

Every team hits these bottlenecks. They're not edge cases—they're architecture.

Lock Contention

terminal-1
$ terraform plan
Error: Error acquiring state lock
Lock held by: sarah@company
⏱ Waiting 4m 23s...

Global state locks block everyone while one person plans a single resource.

Full State Refresh

vpc-change
$ terraform plan
Refreshing state... [2847 resources]
aws_instance.web[0]: Refreshing...
aws_instance.web[1]: Refreshing...
⏱ 3m 12s elapsed... still refreshing

Every plan refreshes all resources even when changing just one.

Terragrunt Slowdown

run-all
$ terragrunt run-all plan
Module 1/127: networking...
Module 2/127: security-groups...
Module 3/127: databases...
⏱ 18m 45s elapsed... 124 modules remaining

External orchestration across 100+ modules creates 15x slowdown.

CI/CD Serialization

deploy-queue
✓ Team A: networking (completed)
⏸ Team B: api-gateway (queued)
⏸ Team C: cdn (queued)
⏸ Team D: monitoring (queued)
3 teams waiting for state lock...

Pipelines serialize deployments to avoid state conflicts.

The Speed Difference

Same infrastructure. Same change. Dramatically different wait time.

Traditional Backend
$ terraform plan
Refreshing state... [2847 resources]
! 3m 47s elapsed...
Still refreshing: aws_instance.web[142]
Stategraph Velocity
$ stategraph plan
Computing change cone... [12 resources]
Plan ready in 2.3s
Skipped 2835 unchanged resources

Performance at scale: 20,000 resources imported in 3 seconds. Queries complete in under 5 seconds even for pathological cases.

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. Multiple teams can work on the same codebase 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.

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.

How It Works

Traditional Backend

terraform.tfstate (JSON file)
GLOBAL LOCK
  • ❌ Load entire JSON file
  • ❌ Lock all resources globally
  • ❌ Refresh everything serially
  • ❌ One operation at a time

Stategraph Velocity

PostgreSQL Graph
LOCKED
FREE
  • ✅ 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.

Multi-State Transactions

One plan. One apply. All your states.

multi-state-plan
$ stategraph plan
Planning across 3 states...
State: prod/networking
~ 12 resources to update
State: prod/compute
~ 8 resources to update
State: prod/storage
+ 5 resources to create
Unified plan ready: 25 resources across 3 states
One apply will execute all changes atomically

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

State A
State B
State A
State B

4 operations
Sequential, incomplete visibility

Multi-State Transaction

State A
State B

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

Organize code however makes sense

Example: Change a VPC in state A that state B depends on. One unified plan shows the full impact across both states. One apply executes everything atomically.

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

2,847
Resources
3,982
Dependency Edges

Traditional Workaround

networking/
427 res
compute/
892 res
storage/
531 res
security/
284 res
...
+122
  • ❌ Split into 127 modules
  • ❌ External orchestration
  • ❌ Manual dependency wiring
  • ❌ 15x performance penalty

The Stategraph Solution

Your Terraform Code
resource "aws_vpc" "main" { ... }
No changes required →
Stategraph Backend
PostgreSQL Graph
Stores state as graph
Resource-Level Locks
Lock only what changes
Parallel Operations
Independent changes run simultaneously
SQL Queries
Query infrastructure like a database
Subgraph Execution
Process only affected resources
Multi-State Transactions
One plan across all states

Fast parallel plan/apply for Terraform. Schedule an activation call to get started.

Request Access View Pricing