Stategraph: Terraform state as a distributed systems problem • Hacker News Board

Re: Stategraph: Terraform state as a distributed systems problem

#31

Post by sausagefeet » Wed, Sep 17, 2025, 12:25 PM UTC

tuananh wrote: post #26

sausagefeet wrote: post #6

Earlier quoted context omitted.

Hello, Stategraph developer here, the answer is: probably not. That doesn't resolve the core issue of state being managed as a big blob.

but that big blob is a database. surely it's better than a json file right?

In terms of the semantics er care about, not really. You still have to lock the whole thing to some with it.

Re: Stategraph: Terraform state as a distributed systems problem

#32

Post by sgarland » Wed, Sep 17, 2025, 12:34 PM UTC

This is very cool. I love the idea of querying the state, and it opens up a ton of very easy reporting options.

Re: Stategraph: Terraform state as a distributed systems problem

#33

Post by lawnchair » Wed, Sep 17, 2025, 12:38 PM UTC

sgarland wrote: post #32

This is very cool. I love the idea of querying the state, and it opens up a ton of very easy reporting options.

Agreed. One of the frustrating things about using Terraform or OpenTofu is that all the data is sitting there in state but you can't really query or report on it. Making that information accessible is a big part of why we are building this.

Re: Stategraph: Terraform state as a distributed systems problem

#34

Post by angio » Wed, Sep 17, 2025, 12:45 PM UTC

cyberpunk wrote: post #18

angio wrote: post #16

How does this compare with Pulumi? AFAIK they also don't have a state file and relay on an external database to store state. Is your locking granularity better?

I mean take this with a grain of salt and purely anecdotal; but everywhere I've heard of who chose pulumi over tf are no long using pulumi. I'd love to hear some opposing experiences to that though!

I'm also in the camp that stopped using Pulumi, in part because despite the lack of state file it feels even more sluggish than tf.

Re: Stategraph: Terraform state as a distributed systems problem

#35

Post by curtisszmania » Wed, Sep 17, 2025, 1:07 PM UTC

[dead]

Re: Stategraph: Terraform state as a distributed systems problem

#36

Post by linuxftw » Wed, Sep 17, 2025, 1:14 PM UTC

If you're at the point of managing thousands of resources inside a single statefile, and that makes the most sense to your setup: you've outgrown terraform.

Re: Stategraph: Terraform state as a distributed systems problem

#37

Post by lawnchair » Wed, Sep 17, 2025, 1:24 PM UTC

linuxftw wrote: post #36

If you're at the point of managing thousands of resources inside a single statefile, and that makes the most sense to your setup: you've outgrown terraform.

From my experience the problem at scale isn't that Terraform stops being useful. The problem is how state gets managed. Every IaC approach still has to coordinate changes across shared resources and none of them escape that. Other tools just shift the trade offs around. In house systems usually end up rebuilding the same thing in another form.

At scale the choices are pretty simple. You split state and live with orchestration glue. You move to a controller model and take on the operational overhead (see Crossplane). Or you keep a cohesive graph and fix the state layer. Those are the real options (imo). It's not about outgrowing Terraform.

Re: Stategraph: Terraform state as a distributed systems problem

#38

Post by alance » Wed, Sep 17, 2025, 1:31 PM UTC

I'm wondering how access controls play into this.

Team A manages VPCs and Security groups, for example.

Team B manages autoscaling groups, EC2, etc.

It's great that now the two teams can look after their own things and not be too worried about resource contention with the other team. But if it's a centralized Postgres database (as you seem to be suggesting?) and both teams have write access to it...

How do we prevent teams from making changes to stuff that isn't "theirs" ?

And if the answer is "well this team only has IAM access to resources xyz", well then might it be a little tricky to represent the Stategraph DAG permission boundaries in IAM policy?

(ps: huge fan of terrateam's offerings -- Alex from tfstate.com)

Re: Stategraph: Terraform state as a distributed systems problem

#39

Post by lawnchair » Wed, Sep 17, 2025, 1:56 PM UTC

alance wrote: post #38

I'm wondering how access controls play into this. Team A manages VPCs and Security groups, for example. Team B manages autoscaling groups, EC2, etc. It's great that now the two teams can look after their own things and not be too worried about resource contention with the other team. But if it's a centralized Postgres database (as you seem to be suggesting?) and both teams have write access to it... How do we prevent…

Hi Alex. Great question and definitely something top of mind as we build Stategraph. The short answer is there is always a service layer in front of the database. Users and teams interact with that service, not the database directly. That is where access control and ownership boundaries live.

Re: Stategraph: Terraform state as a distributed systems problem

#40

Post by solatic » Wed, Sep 17, 2025, 2:02 PM UTC

Very cool. Biggest question I have is how users with large setups where Terraform state has already been split would migrate to this. Would existing state blobs be namespaced into the One True State Graph in PG? Would Stategraph know how to merge different state blobs that are pointing to the same real-life resources? Will Stategraph promote some kind of convention for how state should be named, so that new projects can on-board to using the same state? Should Terraform fit a monorepo or polyrepo model with this kind of backend?