Your infrastructure, as a database
Terraform keeps your infrastructure in a file. Stategraph keeps it in PostgreSQL, as a graph. Plans read only what changed, changes that do not overlap apply at the same time, and every resource and every change is a row you can query.
Teams running Terraform on Stategraph
What changes when state is a database
Measured on real states
Plan time
A plan reads only your change
Terraform refreshes every resource on every plan. Stategraph walks the part of the graph your change reaches, so plan time follows the size of the change.
Faster plan & apply →No-op plan on a real 800 MB production state.
One benchmark. Results vary with the shape of the state. On a smaller state, a one-line change dropped the same plan from 1m13s to 2.0s.
Concurrency
Nobody waits on a lock
Nothing is arbitrated up front. Everyone plans at once, and overlap is settled at commit: changes to different resources land together, and a real overlap is rejected and re-planned.
Parallel applies →tx-a and tx-b touch different resources and commit. tx-c touched a resource tx-a changed, so it is rejected and re-planned.
Multi-state transactions
Producer and consumer in one plan
With a state file, you apply the producer first and hope. Stategraph plans the producer and the consumer together and commits both states in one transaction.
Multi-state transactions →Real output. Same terraform_remote_state HCL.
Query
Ask your infrastructure anything
Resources, dependencies, and history are rows in PostgreSQL. "What depends on this?" and "what changed last Tuesday?" are a query, not archaeology.
SQL inventory →Real output captured from a live Stategraph instance.
Blast radius
Every dependent, ranked, before you apply
A plan lists what you changed, not what it breaks. Stategraph walks the dependency graph and lists every dependent by distance, remote-state consumers included.
Blast radius →distance 0 = the changed resource · distance 1 = directly affected dependents
Cost
The price of a change, in the plan
Reviewers see the diff and the bill together. Every plan carries current versus planned cost, per state and per resource.
Cost →current → planned, with the delta in green.
Security
Security model
State lives in a database that we may host. This is what that does and does not mean.
The server never runs Terraform
Plans and applies run where you run the CLI, on your machine or your CI runner. The server stores state and never sees your cloud credentials.
Access scoped to part of the graph
A token can plan without apply, and can be limited to one state or to specific resources within it.
Your identity provider
Sign in over OIDC or with Google. Self-hosted, air-gapped, or BYOC when your policy requires it.
Findings on the change itself
With scanning enabled, each plan reports the findings a change adds and resolves, in the plan output.
Getting in, and getting out
Same HCL, one state at a time
Check the fit locally first. Import one root module. Export a standard state file whenever you want.
Gap analysis compares your AWS or GCP account with your states and generates the import blocks and HCL for what no state manages.
Deployment
Run it where your security team wants it
Stategraph Cloud
Managed by us, single-tenant with your own Postgres. The fastest way to start.
Self-hosted
In your own infrastructure, fully air-gapped if needed. See self-host options →
BYOC
We operate it inside your AWS, GCP, or Azure account. You own the data and the account.
Use it on its own under the CI you have, or with Stategraph Orchestration from the pull request.
Go deeper
Each capability, with a worked example
Faster plan & apply
Subgraph execution, resource-level locking, and multi-state transactions.
Insights
Blast radius, dependency search, and the graph explorer.
Inventory
Dashboards and SQL over everything you run.
Cost
Current versus planned in every plan, attribution, and actuals.
See it on your infrastructure
Bring a state file. In under 30 minutes you see your own infrastructure as a graph, with plans, locks, and SQL running against it.