Your state is already a database
Every resource, attribute, and edge of the dependency graph lives in normalized Postgres tables. You don't export it to a CMDB or grep through tfstate JSON — you just query the state itself, live.
❯ stategraph sql schema resources(type,name,provider,module,…) instances(address,attributes,dependencies,…) states(name,workspace,created_at,…) dependencies cost_snapshots ❯ stategraph query "SELECT type, COUNT(*) FROM resources GROUP BY type ORDER BY COUNT(*) DESC LIMIT 8" type count kubernetes_role_binding 586 kubernetes_manifest 382 null_resource 317 kubernetes_service 175 google_kms_key_ring 166 google_kms_crypto_key 166 google_kms_secret 163 kubernetes_namespace 159 ❯ stategraph query "SELECT COUNT(*) FROM instances" count 7190
Real output captured from a live Stategraph backend — not a mockup.
One query beats a CMDB
The classic approach scatters your inventory across copies that drift out of sync. With Stategraph, the answer is one SQL query against the state itself.
What you get
Query across states
One SELECT spans every state and workspace at once. No more stitching together a dozen tfstate files to answer a single question.
JSONB attribute filters
Every resource attribute is queryable. Find every box of a size with WHERE attributes->>'instance_type' = 't3.micro'.
Drift as a query
Drift isn't a separate tool with its own copy — it's a query against live state. Ask what changed, get an answer in milliseconds.
Build dashboards
Point Grafana, Metabase, or any SQL client straight at it. Inventory, cost, and ownership dashboards with zero glue code.
No export pipeline
There's nothing to sync, schedule, or babysit. The data is the state, so it's always current by definition.
Standard SQL
No bespoke query language to learn. GROUP BY, JOIN, and aggregates work exactly like you'd expect against the dependency graph.
Query your infrastructure
Stop exporting your state to a system that's stale the moment it lands. Bring your states to Stategraph and ask anything in plain SQL. All features.