Every comparison of these two tools eventually admits they solve overlapping problems and then picks a winner anyway. That is the wrong shape of answer. We ran both across the same estate for several years, and the interesting question was never which one wins. It was which job each one is actually good at.
The line we drew
Terraform kept the foundations: landing zones, account and project structure, network topology, DNS, the base of each cluster. Crossplane took everything a product team should be able to request without us in the room: namespaces, databases, queues, buckets, IAM roles scoped to a service, the pipeline and dashboards that come with it.
Stated as a rule, it was roughly this. If a human should read a plan before it applies, it belongs in Terraform. If the request is routine enough that reading the plan is theatre, it belongs in a composition.
Why the foundations stayed in Terraform
Landing zones change rarely and catastrophically. Nobody provisions a new account structure on a Tuesday afternoon, and when they do you want the change reviewed by someone who understands the blast radius. Terraform is very good at exactly this: a plan you can read, an apply you can gate, and a state file that is the record of what happened.
There is also a boring but decisive reason. The people who own that layer already knew Terraform well. Moving foundational infrastructure into a less familiar tool, in order to gain self-service that nobody was asking for at that layer, would have been change for its own sake.
Why self-service went to Crossplane
The property that matters is not that Crossplane is Kubernetes-native, or that compositions are elegant. It is continuous reconciliation.
A developer request and a drift correction become the same operation.
With Terraform, self-service means running an apply on someone else's behalf, usually from a pipeline, and then hoping nothing changes underneath it until the next run. Drift is discovered on the next plan, which might be weeks away. With a control plane reconciling desired state, drift is corrected by the same mechanism that created the resource in the first place.
That is what makes self-service safe rather than merely fast. When you hand a product team a button, you are accepting that they will press it more often than you would, and that some of what they create will be forgotten. Reconciliation means forgotten things stay correct instead of quietly rotting.
What the split cost us
Two things, and both are worth knowing before you copy the pattern.
- You are now operating a control plane. Its availability is your availability, its upgrades are your upgrades, and its failure modes are yours to learn. That is real operational load, not a footnote.
- You have two mental models in the estate. An engineer debugging a resource needs to know which system owns it before they can reason about it, so the boundary has to be documented and obvious rather than tribal knowledge.
We reduced the second cost by making the boundary follow ownership rather than technology. Anything a platform team owns is Terraform. Anything a product team requests is a composition. That is a question anyone can answer without knowing the internals.
When we would not reach for Crossplane
If you have one team, a handful of services and no ambition to offer self-service, the control plane is overhead with no payoff. Terraform modules and a decent pipeline will serve you well past the point most teams assume they need something heavier.
The threshold is not cluster count or headcount. It is whether infrastructure requests have become a queue that a person works through. Until they have, you are solving a problem you do not have yet.
The version we would give in one sentence
Terraform for the things you change deliberately, Crossplane for the things you want other people to change safely, and a boundary drawn on ownership so nobody has to guess which is which.
