Drop-in replacement for Terraform/OpenTofu

Plan in seconds, not minutes.

Stategraph Velocity accelerates Terraform plan and apply. Seconds, not hours. No code changes required.

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

See it in action

The Stategraph CLI — fast plans, blast radius analysis, SQL queries over infrastructure, and automated refactors.

stategraph

Want to see it on your infrastructure? Book a walkthrough

Real numbers. Real state file.

Benchmarked against an 800 MB Terraform state file with ~4,200 resources across 100 modules. Full methodology.

Terraform no-op
~3 hours
Refresh disabled
Stategraph no-op
97 seconds
Same state file

The difference is architectural. Terraform treats the entire state as the unit of work: global lock, full graph traversal, whole-state refresh on every operation. Stategraph narrows the unit of work to the minimal affected subgraph.

Get Started

How it actually works

Stategraph replaces the flat JSON state file with a PostgreSQL-backed dependency graph. Here is what changes under the hood.

Change Cone

Only touch what changed

When you run stategraph plan, a recursive SQL query walks the dependency graph to identify the minimal affected subgraph. Change an aws_vpc? Stategraph resolves only the VPC and its dependents, not the other 4,192 resources.

Two dependency graphs side by side. Left: whole-state execution with all nodes red. Right: subgraph execution with only 3 nodes highlighted, the rest dim. Two dependency graphs side by side. Left: whole-state execution with all nodes red. Right: subgraph execution with only 3 nodes highlighted, the rest dim.
change-cone
Traditional: Refresh all 4,200 resources → plan all → apply all
Stategraph:  Identify 8 affected resources → refresh 8 → plan 8 → apply 8
Resource Locking

Resource-level locking, not global state lock

Traditional backends lock the entire state file. One person changing an EC2 tag blocks everyone else from planning against 2,000 other resources. Stategraph locks individual resources. Two engineers touching non-overlapping resources run in parallel with zero contention.

Timeline diagram comparing Terraform (Team B waits while Team A holds global lock) vs Stategraph (both teams run simultaneously with row-level locks on non-overlapping resources). Timeline diagram comparing Terraform (Team B waits while Team A holds global lock) vs Stategraph (both teams run simultaneously with row-level locks on non-overlapping resources).
Drop-in Replacement

Your existing Terraform underneath

Stategraph delegates to the native terraform or tofu binary for provider execution. No custom providers, no HCL changes, no shims. Your .tf files, your modules, your providers, unchanged.

See the difference

Watch how Stategraph parallelizes your infrastructure operations

Traditional Backend

terraform apply 00:00
[VPC ] waiting
[Subnets ] waiting
[Security ] waiting
[RDS ] waiting
[ALB ] waiting
[ASG ] waiting
[Route53 ] waiting
[CloudFront ] waiting

Stategraph

stategraph apply 00:00
[VPC ] waiting
[Subnets ] waiting
[Security ] waiting
[RDS ] waiting
[ALB ] waiting
[ASG ] waiting
[Route53 ] waiting
[CloudFront ] waiting

Three commands to migrate

Import your existing state. Use the same plan/apply workflow. No code changes.

before
$ terraform plan -out=plan.json
$ terraform apply plan.json
after
$ stategraph plan -out plan.json
$ stategraph apply plan.json
migration (one-time)
# 1. Export existing state
$ terraform state pull > terraform.tfstate
# 2. Import into Stategraph
$ stategraph import tf terraform.tfstate
# 3. Run your first plan
$ stategraph plan -out plan.json
Computing change cone... [12 resources]
✓ Plan ready in 2.3s
Get Started

More than fast plans

Graph-based state unlocks capabilities that flat files cannot support.

Blast radius before you apply

See the full downstream impact of any change before running plan. Stategraph walks the dependency graph and returns every resource at each distance from the target.

$ stategraph blast-radius "aws_vpc.main"
RESOURCE TYPE DISTANCE
aws_subnet.publicaws_subnet1
aws_subnet.privateaws_subnet1
aws_instance.webaws_instance2
aws_eip.webaws_instance2
Global lock with all 11 resources locked vs resource-level locking with only 2 affected resources locked. Global lock with all 11 resources locked vs resource-level locking with only 2 affected resources locked.

Query infrastructure with SQL

Your infrastructure is in PostgreSQL. Query it directly with MQL, the built-in SQL interface, to audit resources, find drift, or answer ad-hoc questions across your entire fleet.

SELECT type, COUNT(*) as count
FROM resources
GROUP BY type ORDER BY count DESC
Stategraph UI showing dependency graph, SQL query panel with results, and transaction log. Stategraph UI showing dependency graph, SQL query panel with results, and transaction log.

Refactor without terraform state mv

$ stategraph refactor start
# rename resources, reorganize modules
$ stategraph refactor step
aws_instance.web → aws_instance.frontend
$ stategraph refactor complete
✓ Wrote moved blocks to moved.tf

Rename resources and reorganize modules. Stategraph detects the changes and generates moved blocks automatically.

Atomic multi-state transactions

$ stategraph mtx -out plan.json ./networking ./compute ./app
$ stategraph apply plan.json

Plan and apply across multiple state files in a single atomic transaction.

Explore the Docs

Prefer a walkthrough?

We'll set up Stategraph on your infrastructure and show you the speed difference firsthand. No commitment.

Can't find a time? Email us or use the contact form