Engineering Log: Importing state into a queryable graph

First time showing this to anyone outside the team

We've been grinding on Stategraph for months. Database schema for Terraform state, import functionality, query interfaces, graph visualization. All of it built in relative isolation, validating assumptions against our own intuitions and the conversations we've had with infrastructure teams. This demo was the first time we put it in front of a room full of people and said, here's what we've built, here's where we're going, what do you think?

Here's the recording.

The questions confirmed we're solving real problems

The most valuable part of the demo was the Q&A, and what made it valuable was the consistency. Everyone asked about the same things, and those things tell you exactly what's broken in the current tooling landscape.

Self-hosting came up immediately. Can I run this myself? Where does the data live? This isn't paranoia. Terraform state contains secrets, database passwords, API keys, whatever sensitive values your providers need. People don't want that in someone else's cloud, and they shouldn't have to. Stategraph is designed from the beginning to be self-hostable.

Scale came up next. How many resources can it handle? How long do queries take? People are hitting real performance walls with their current setups, and they want to know that this thing won't fall over the same way. In testing we've imported 20,000 resources in about three seconds, and queries run in under five seconds even for pathological cases. PostgreSQL does the heavy lifting.

Then Terragrunt. Does it work with Terragrunt? Yes, as a drop-in replacement. But the larger point is that you shouldn't need Terragrunt. The reason people use it is that Terraform falls over once your root modules get too big, so you split everything into smaller pieces and wire them back together with dependency orchestration. That's a workaround for a limitation that shouldn't exist. Stategraph lets you put everything in a single root module and manage access control at the resource level.

These questions confirmed what we believed going in. The industry is stuck on the same problems, and people have been solving them with workarounds for years. Split your root modules, use Terragrunt, accept that plans take forever, accept that state is an opaque blob. Stategraph is the alternative.

Where we're going

By end of year, we're shipping asset management (queryable state with history, so you can see what's in your infrastructure and track changes over time) and a state backend (the HTTP backend that lets you use Stategraph as your Terraform backend, automatically getting all the structured data plus metadata like who made the change and which PR it came from). In Q1 2026, we ship parallel plan and apply. Because we understand the graph structure, we can identify independent subgraphs and run operations concurrently. If you have three changes that don't overlap, they should all run at the same time. This is the big unlock. And in Q2, we're looking at control plane functionality, the pull-based reconciliation model that tools like Crossplane provide, but without requiring you to migrate everything to Kubernetes.

What comes next

This was demo day one. December will be demo day two, and we'll have more to show. If you're running Terraform at scale and want to be involved earlier in the process, we're looking for design partners.