Terraform & OpenTofu without the
state file bottleneck

No code changes required. Your Terraform/OpenTofu configurations, modules, and providers remain exactly the same. You just use the Stategraph CLI (a drop-in replacement for the Terraform/OpenTofu CLI) and update your backend configuration to point to Stategraph.

Stategraph imports your existing .tfstate file on first run. Every resource, every attribute, every piece of metadata is preserved and migrated into the database. The import process is non-destructive, and you can always export back to standard .tfstate format if needed.

Yes. Stategraph supports multiple state files in the same database. Each state file becomes a separate graph that can be queried independently or together. You can manage hundreds of environments, modules, or workspaces in a single database instance while maintaining complete isolation and dependency tracking across them.

Stategraph builds a complete dependency graph of your resources and only parallelizes truly independent subgraphs. We enforce explicit barriers for dependencies and use transactional writes. If resources depend on each other, they run in order. If they don't, they run in parallel.

You need PostgreSQL 14+, but you have options: self-hosted on your infrastructure, managed services like RDS or Cloud SQL, or local PostgreSQL for development. The database requirements are minimal — any PostgreSQL instance can handle thousands of resources.

Your infrastructure state becomes queryable data. Find all EC2 instances in production, track resource changes over time, identify unused resources, or build custom dashboards. This is real SQL against normalized data, not parsing JSON blobs.

Terraform/OpenTofu's pg backend just stores the state file as a blob in PostgreSQL. Stategraph actually parses and normalizes the state into a proper database schema. Every resource becomes a queryable entity with relationships, history, and ownership. The pg backend stores a file in a database — Stategraph IS a database.

All state data is encrypted at rest (AES-256) and in transit (TLS 1.3). Provider credentials are never stored in state. Resource-level RBAC means teams only see what they need. Every access and modification is logged with full attribution.