When state is a file, every question is a grep.
Stategraph stores state as a normalized graph in Postgres. What you have, what a change touches, what it costs, and who changed it last are queries, not files you parse.
What you can see
Questions a flat file cannot answer
Query
Ask the state directly
A state file is JSON you grep. Stategraph keeps every resource, attribute, and dependency edge in Postgres tables, and you query them with SQL.
Inventory →Real output captured from a live Stategraph instance.
Blast radius
What a change touches
A plan lists what you changed, not what it breaks. Stategraph walks the dependency graph and lists every dependent by distance, remote-state consumers in other states included.
Blast radius →distance 0 = the changed resource · distance 1 = directly affected dependents
Cost
What it costs, in the plan
A plan shows the diff, not the bill. Every Stategraph plan carries current versus planned cost, per state and per resource, so the reviewer sees both together.
Cost →current → planned, with the delta in green.
History
What happened, and who did it
Terraform state is one overwritten snapshot with no record of who applied what. Stategraph writes every apply as an append-only transaction, attributed to a user and queryable in SQL.
Audit timeline →every apply · an immutable transaction · attributed to a user, queryable forever
Why the answers hold up
The data is the state
Not a copy
The tables you query are the ones plan and apply write to, so nothing is exported to a CMDB and nothing syncs on a schedule.
Every state at once
One SELECT covers every state and workspace, and JSONB filters reach any resource attribute.
What nobody remembers creating
Gap analysis compares your AWS or GCP account with your states and writes the import blocks and HCL for what no state manages.
See it against your own state
Bring a state file and look at your own resources, dependencies, costs, and change history as one graph you can query.