TL;DR

Your code doesn't slow Terraform and OpenTofu; it's down to state and the way work gets serialized.
Stategraph Velocity delivers faster plan and apply by treating infrastructure state as a dependency graph in Postgres instead of a flat file.
Velocity focuses work to the smallest affected subgraph, enables parallel execution, and reduces contention with more granular locking.

Stategraph Velocity is fast plan and apply for Terraform or OpenTofu, built by replacing the flat state file with a database-backed dependency graph. We're launching it because waiting on Terraform is an architectural problem, and one we can fix.

Stategraph Velocity is the result of hundreds of conversations with Terraform users.

We kept hearing the same story from teams doing real work. Plans that feel like they scale with the size of the environment, global locks that turn infrastructure into a queue, and workflows that end up shaped around avoiding contention instead of delivering changes.

That pattern isn't a tooling mistake. It's a systems design consequence.

Infrastructure is a graph with resources, dependencies, edges, and order. Terraform already builds that graph during planning, then we store the result as a flat state file and treat it like a single shared object. Lock the whole thing. Read the whole thing. Refresh a lot of things that didn't change. Repeat. The Stategraph Terraform HTTP Backend exists because state deserves better primitives like a database, real transactions, real concurrency control, and a first-class representation of the dependency graph.

Velocity is the next step. It takes that foundation and applies it to the moment that hurts the most for IaC users: plan and apply.

An introduction to Stategraph Velocity

Stategraph Velocity is a faster way to run Terraform and OpenTofu plan and apply.

Stategraph provides the foundation by moving state from a file we lock and reload to a structured dependency graph stored in Postgres. Velocity builds on that foundation with a different execution model:

Graph-aware planning – Work is scoped to the part of the graph your change can actually impact.
Targeted refresh – Refresh what's relevant, instead of treating refresh like an all-or-nothing tax.
Parallelism where it's safe – Independent subgraphs can be evaluated and executed at the same time.
Granular contention control – Locking can be scoped to what's being changed, instead of halting every workflow behind one lock.

The goal isn't a new workflow. The goal is the workflow you already use, just without the drag.

What Stategraph Velocity solves

Plans that scale with environment size, instead of change size

In a file-backed world, every plan tends to pay a fixed cost by loading the state, refreshing broadly, walking the graph, and serializing access. As environments grow, the fixed cost stops being fixed.

Velocity changes the cost model. If your change affects a small set of resources, planning focuses on that impacted subgraph instead of treating the whole world as equally relevant.

Lock contention and the infrastructure queue

Global locking is a blunt instrument. Two changes that don't overlap still block each other, simply because they touch the same state file.

Velocity is built around more granular control, so independent work can proceed without turning every change into a traffic jam.

Run order and cross-state dependencies

Splitting state helps until you need coordination across it. Then you're back to choreography: applying A, then B, then C, with scripts and conventions attempting to keep things honest.

Velocity is designed to make cross-state work less fragile by handling dependency-aware execution as a core capability, not a wrapper script.

Opaque state that's hard to understand, query, and reason about

Stategraph turns state into structured, queryable data in Postgres. When state is a blob, analysis becomes exporting JSON and writing ad-hoc tools.

When state is structured, you can ask real questions like what depends on this, what changed, what's drifting, what will this touch, and why.

Velocity benefits from that same underlying structure.

Why we built Stategraph Velocity

The problems people blame Terraform for are often related to the storage and coordination layer.

A flat state file with a global lock causes:

Unrelated work to collide
Execution to be serialized by default
Performance to degrade as state grows
Workflows that get shaped around avoidance strategies instead of engineering intent

We built Stategraph on a simple premise: if you give IaC the right primitives – a database, transactions, structured state, and a real dependency model – you get better outcomes across the board.

Velocity is that exact premise applied to execution speed and throughput. It's how you get faster feedback loops without relying on fragile workarounds.

How you can get started with Stategraph Velocity

Stategraph is available today, and Velocity builds on top of it.

Here's how you can get started:

Kick things off with Stategraph – The free tier is the foundation. Use the Stategraph CLI – a drop-in replacement for the Terraform/OpenTofu CLI – and point your backend configuration to Stategraph. You'll get the core benefits of database-backed state, history, and graph visibility.
Choose the right deployment model – Stategraph is designed to run in your environment. For teams that want a dedicated single-tenant option, there are private deployment options as well.
Add Velocity when it fits – Velocity is an additional capability that sits on top of the same Stategraph foundation. Depending on where it is in the rollout.

For the most current tiers and what's included in each, check out our pricing page.

Everything else that is available on Stategraph

Velocity is part of a broader platform that turns infrastructure state into something you can actually use, not just store. Here are the other products you can use with Stategraph:

Stategraph Insights

Insights provides database-backed state stored as a dependency graph in Postgres, change history, graph exploration, blast radius analysis, and the primitives that make the rest possible. You use the Stategraph CLI to execute graph-aware operations directly against the database.

Stategraph Inventory

Inventory is your infrastructure catalog, turning state into something searchable and explorable through resource views, filters, exports, and queries that help you understand what you have and what it depends on.

Stategraph Orchestration

Orchestration brings Terraform into a controlled workflow with PR-based planning, gated applies, policy hooks, and the operational guardrails teams need when infrastructure becomes a shared system.

Stategraph Velocity is the acceleration layer, but the bigger story is that infrastructure stops being a black box. It becomes structured, observable, and faster to change.

Try Stategraph Velocity today

Stategraph Velocity exists for one simple reason: infrastructure work shouldn't queue behind a file lock.

If your change touches a small part of your environment, your plan and apply should behave like it. Velocity brings that reality to Terraform and OpenTofu by treating state as what it actually is, a dependency graph, and using database primitives to unlock faster, more concurrent execution.

Start with Stategraph today, and add Velocity as you're ready. Less waiting. More shipping.

Learn

Connect

Posts tagged "velocity"

Announcing Stategraph Velocity: Terraform plans in seconds, not minutes