I had the exact same hesitation. The way I've started to see it is that the hesitation itself is the point of the model shift.
Under per-GB, "just send everything" often means you're sending and paying for a lot of data you'll never analyze. The per-span model makes that cost explicit at the moment of instrumentation, so you're forced to decide what's actually valuable for debugging versus what's just noise.
In our case, it didn't stop us from adding instrumentation. It just made us more deliberate about it. We might add a new span but set a high sampling rate on it initially, or only enable full verbosity on error paths. It's less about not adding and more about adding intelligently.
This. So much this.
That exact moment of hesitation you describe is where the mindset shift happens. Under per-GB, you just shrug and add the extra tag. Under per-span, you pause and ask "is this worth the unit cost for every single execution?"
A concrete thing it changed for us was high-cardinality user IDs. We used to add them to every span automatically. Now they only go on sampled traces, because the volume didn't justify the cost for data we'd only use in a tiny fraction of investigations. The noise-to-value ratio suddenly became quantifiable.
edge cases matter
Spot-on question. Frequency is the obvious starting point, but don't sleep on *span size*. A high-frequency span with 10 tags is one thing, same span with a 2MB JSON payload attached is a completely different beast.
Look for operations where someone got lazy and attached entire request/response bodies "for debugging". Those are the silent killers. Your vendor's bill probably has a breakdown by ingest source - start with the top 3 and inspect what they're actually sending.
And watch out for cardinality bombs, like tagging every span with a full user context object. Those add up fast.
NightOps
Switched last year and yes, the predictability is a game changer. The bill is now tied to transaction volume, which is far more stable for us than log volume.
It absolutely changed our instrumentation. We used to log full SQL queries on every database call "just in case." Under per-span, we realized we couldn't afford that for every single query. Now we only attach the full query text to spans that are part of a sampled trace. Made us trim a lot of fat.
Automate the boring stuff.
Predictability is better, but you trade one problem for another. You control cost, but now you're fighting to get the data you need.
It forces you to stop collecting debug data by default. Good for the bill, bad when you're trying to diagnose a rare edge case and realize you never enabled that span.
The real shift isn't in pricing, it's in your team's discipline. If you lack that now, per-span just makes the pain point more obvious.
Simplicity is the ultimate sophistication
Oh, absolutely. The predictability is real, but like others said, it comes with a new set of operational habits. For us, the biggest shift was around custom metrics and attributes.
We used to stuff spans with all sorts of extra tags "just for dashboards" under per-GB. Why not, right? Under per-span, each of those tags becomes a cost decision. We ended up moving a ton of that diagnostic data out of spans and into actual metric events or logs that we only emit on error, because the cost per unit is so much lower for those channels. It made our tracing data much leaner and more focused on actual request-flow debugging.
Honestly, it made us better engineers. We're not just throwing data at the wall anymore.
hugo
> layered tagging strategy
Exactly this. We ended up with three tiers after switching:
- Tier 1: span name, duration, error flag on everything.
- Tier 2: core context (user_id, request_id) on sampled traces only.
- Tier 3: full payloads only on explicit debug flags or high-error rate paths.
Forcing that taxonomy was the real win. We stopped guessing what we needed.
YAML all the things.