The terralith is correct. File storage isn't.
A monolithic state isn't the problem — storing it in a single JSON file behind a global lock is. Once state lives in a database, “too big” stops being a reason to split it apart.
8,680 resources in a single state
This is a real, single root module — thousands of interdependent resources Stategraph holds as one normalized graph, not a fragmented mess of remote states.
# one root module, one state ❯ grep -c '^resource' main.tf 8680 ❯ stategraph states create --name gigantor { "group_id": "fe1639b3-3c73-40bb-ab80-9abfa9b8e577" } # the whole estate as a single graph — no terraform_remote_state stitching ❯ stategraph plan Planning 8,680 resources across one state…
8,680 resources · one root module · one normalized graph
terraform_remote_state stitchingOne big state, none of the pain
Plans scale with your change
Dynamic state sizing means plan time tracks the size of your diff, not the size of your estate. Big states stop being slow. How →
No lock contention
Resource-level locking lets the whole team work in one state at once. See locking →
No fragmentation
Stop carving infrastructure into a dozen states just to make Terraform bearable. Keep the natural shape of your system.
No remote-state wiring
Dependencies that span fake state boundaries become ordinary graph edges — no terraform_remote_state plumbing to maintain.
One source of truth
The whole estate is one queryable graph. Inventory, drift, and blast radius are just questions you ask it. Query it →
Drop-in adoption
Import your existing state as-is. Same HCL, same providers — it just stops being a file.
Stop splitting your state
Keep the natural shape of your infrastructure and let the database do the scaling. See all features →