Stategraph, from Terrateam co-founder Josh Pollara, is positioning itself as a Terraform alternative that addresses state file bottlenecks by storing infrastructure as a PostgreSQL dependency graph rather than flat JSON.
The product implements Terraform's HTTP backend protocol, requiring an API endpoint and authentication. Setup involves creating API keys through the web interface and obtaining a group_id (similar to HCP Terraform workspace identifiers) via their CLI tool. The documentation could front-load the API key requirement more clearly: users who skip ahead hit configuration walls.
For AWS deployments, most organizations default to S3 backends with DynamoDB for state locking (pre-Terraform 1.10). Stategraph's graph-based approach aims to enable parallel plans through their upcoming Velocity feature by identifying non-overlapping resources. The core thesis: "Infrastructure is a graph. Store it as a graph."
The web interface shows promise for resource visibility across multiple state files. Early impressions suggest better state metadata tracking than standard S3 backends, though production readiness remains to be tested at scale.
What matters here: Terraform commands 34% of the configuration management market. State management remains a pain point for multi-team AWS deployments. Traditional remote state strategies using S3/DynamoDB work but create bottlenecks during concurrent operations. Any tool that genuinely speeds up plans while maintaining consistency deserves attention.
The trade-offs: PostgreSQL adds operational complexity versus S3's simplicity. Graph-based storage is conceptually cleaner but unproven at enterprise scale. Resource-level locking sounds good until you hit edge cases with tightly coupled resources.
Worth watching: how the Velocity feature performs on large AWS estates and whether the graph model holds up under production concurrency patterns. The industry has more "better Terraform" promises than actual improvements.