Engineering Log: Stategraph Velocity launch day

What launched with Velocity

Stategraph Velocity improves execution speed and throughput, with parallel plan and apply when changes don’t overlap and cross-state transactions that pull dependent states into the same operation, meaning you can see the full impact and apply them together.

It’s built on the simple belief that you should not have to wait for Terraform to plan or apply every resource in your state file when you are only changing a few of them.

What we demonstrated in the launch day session represents the most fundamental shift yet in how you can operate on Terraform state at scale. We demoed Velocity live across distinct scenarios, demonstrating how Stategraph knows the connection between every resource in your state, stores that graph in a database, and operates only on the subgraph of resources that are actually affected by a given change.

Terraform serializes your infrastructure graph into a flat file and then reads the whole thing every time you do anything. Stategraph stores that graph as rows in a Postgres database, which means it can read only the rows relevant to a given operation.

How Stategraph stores your infrastructure graph is what makes plans faster, makes parallel applies possible, and enables cross-state transactions. For small changes in large infrastructure, the difference is not incremental; it’s an order of magnitude.

Parallel plan and apply stops being a queue

In the demo, we started by running a single root module with three distinct islands of resources: a set belonging to team A, a set belonging to team B, and a deliberately slow resource that simulates something like a data source with a 60-second delay. The point was to isolate the variable and show, cleanly, what Stategraph's subgraph approach actually does in practice.

In standard Terraform, a no-op plan on this module, with the slow resource present, takes around 60 seconds. Terraform has to evaluate every resource in the file, including the sleeping data source. Stategraph ran the same initial apply in a comparable time because, on first load, it has to process everything and populate the database. But once the state is in Stategraph, the behavior changes entirely.

After we modified a resource belonging to team A with no connections to the slow island, Stategraph planned only the subgraph relevant to that change. The plan completed in around 15 seconds. The slow resource was not touched, because Stategraph knew it was not part of the subgraph for this operation.

Both plans existed, and both targeted the same state file. In Terraform, one of them would have to lose: a state lock would be acquired by whichever apply ran first, and the other would fail outright. There’s no mechanism in Terraform for two concurrent applies to coexist, even when the changes are completely independent of each other. In Stategraph, both applies run at the same time.

What about overlapping changes? The same logic is followed: plans can always run in parallel. When two applies touch overlapping resources, the second transaction to arrive detects the conflict and tells you clearly that you need to re-plan and re-apply. No silent failures, no corrupted state, just an explicit signal from the database.

And what about infrastructure changes that occur outside of Terraform entirely? The answer is the force parameter, which lets you specify a pattern of resources to refresh regardless of whether Stategraph thinks anything has changed, and scheduled refreshes, which let you set a cadence on which given resources are always checked.

Stategraph hasn’t just found tricks to speed up Terraform's existing process, it understands your state well enough to skip the parts of that process that are irrelevant to what you’re actually doing.

Cross-state transactions make the blast radius real

Imagine changing a proxy port without realizing it has a downstream consumer that configures firewall rules. The port changes, the firewall rules do not and traffic gets blocked. It might take a while to understand why.

With Stategraph, that scenario doesn’t happen because the plan shows you the complete blast radius before you apply anything.

We showed two root modules with a dependency between them: a producer state that exposes an HTTP proxy port as an output and a consumer state that reads that output via a terraform_remote_state data source to configure firewall rules with a min and max port range.

Running this in two separate steps works as you would expect: apply the producer, see the port value, then plan and apply the consumer. Stategraph Velocity shows you clearly in the plan output which state each resource belongs to, labeling them with whatever name you decide for each in the plan legend.

When we made a change to the producer's port value and planned it, Stategraph detected the relationship between the two state files through the terraform_remote_state reference, followed that dependency, and included the consumer's resources in the plan automatically – even though we hadn’t touched the consumer at all.

Stategraph manages your infrastructure as one unit. The boundary between two state files in Terraform is a hard filesystem boundary: two separate JSON blobs with no inherent understanding of their relationship. In Stategraph, that boundary is a row boundary in a database. Stategraph can follow the Terraform code's declared relationships across that boundary and plan the full scope of a change, wherever it propagates.

Do you split large infrastructure across multiple state files to make it more manageable? Good practice, but you create a hidden cost: manual tracking and orchestrating of the dependencies between those files. Stategraph reads those relationships from your existing Terraform code and handles the orchestration. You don’t have to rewrite anything or add new tools to define the relationships, as they are already there in your code. Stategraph just follows them.

Feel the speed

Stategraph, on a laptop, in under two minutes. Terraform, on a beefy cloud server, in nearly three hours.

A design partner provided a real Terraform root module. The Terraform file alone is around 100MB. The state file it produces is around 800MB.

It took six minutes to load this into Stategraph's database – roughly what you would expect for 800MB of state. We made a small change and planned it. The plan took 71 seconds. We made another change, undoing the first, and planned again. That took 97 seconds, with variance due to it running on a laptop not a server.

Then we ran the same no-op on vanilla Terraform. Not on a laptop: on a large, powerful cloud machine purpose-built for this kind of workload. It took almost three hours.

The difference is not a better implementation of the same algorithm. It is a fundamentally different approach: operating on the subgraph of what changed rather than processing the entire state on every operation.

The logic that makes Stategraph fast on a 100MB HCL file is the same logic that makes it faster on a 10MB file or a 1MB file. The subgraph approach compounds. As your infrastructure grows, the gap between operating on everything and only on what changed grows with it. Terraform's performance characteristics are roughly linear with state size. Stategraph's are not, because the subgraph for a given change stays small even as the total state grows.

Try Stategraph Velocity free

Launch day is the moment a promise becomes a product, but it is not the end of the work. Velocity’s demo showed the core primitives working: subgraph-scoped planning, parallel execution when changes are independent, and cross-state transactions that make blast radius visible and actionable in one operation.

It also revealed how we’re thinking about security, policy, cost estimation, and governance. For example, Stategraph Velocity is available self-hosted, given users more control over their data. Also every operation goes through the Stategraph server, which means there’s a single, centralized place to enforce policy. Currently, that means plan and apply require an API key.

Now we want to hear from you. Request access to Stategraph today and let us know what we can improve.