DEV Community

Sergey Shinder
Sergey Shinder

Posted on

Why we split one Terraform state into twenty

For a long time our entire infrastructure lived in one Terraform state file. Every environment, every service, every bucket and role and network — one terraform apply to rule them all. It felt clean until the day a plan touched 600 resources to change a single tag, and someone's apply got interrupted halfway, and the state lock jammed, and nobody could deploy anything for the rest of the afternoon.

A monolithic state has a blast radius problem. Any change plans the whole world, so a trivial edit makes you read a 600-resource diff to find the one line you meant. Applies get slow enough that people batch changes to avoid the wait, which makes each apply bigger and riskier — exactly the wrong incentive. And the single lock means one person applying blocks everyone, so the team quietly serializes around a shared bottleneck.

The worst part was fear. When one apply can touch production databases and a dev sandbox in the same run, people stop wanting to run apply at all. Infrastructure changes started queueing up because nobody wanted to be the one holding the giant plan when it went sideways.

So we split it. State per environment first — prod, staging, dev never share a file or a lock again. Then state per bounded component within an environment: networking, data stores, the compute for each major service. The rule we landed on: things that change together and are owned by the same people live together; everything else gets its own state and its own lock.

The tradeoff is real and worth naming. More states mean more wiring between them — you pass outputs across boundaries with remote state or a data source, and you have to think about dependency order yourself instead of letting one graph sort it out. That's genuine overhead. But a small plan you can actually read, an apply that finishes in a minute, and a lock that only blocks the three people touching the same component — those pay the overhead back every single day.

State layout is architecture, not bookkeeping. Draw the seams where ownership and change-frequency actually differ, and your applies get small, boring, and frequent. Draw one big circle around everything and you've built a bottleneck with a lock on it.

– Sergey Shinder

Top comments (0)