Splitting signals into separate storage backends is the industry default because it's easier to build. It's not easier to operate, or to pay for.

Nearly every observability stack we've replaced for a customer was three or four separate products stitched together: a metrics TSDB, a log store, a tracing backend, each billed, retained, and queried differently. It's the easier thing to build as a vendor. We think it's the wrong thing to buy as a customer, and the economics back that up more than the convenience argument does.

The hidden tax of split storage

Every signal boundary is a place data gets duplicated. Teams tag the same request with overlapping metadata in three places, pay three separate ingestion pipelines' overhead, and — the part that actually shows up on an invoice — retain each signal on a separate policy that nobody aligns, so you're often paying premium hot-storage rates for logs nobody has queried in months simply because the log retention setting was never revisited after the metrics retention was.

from ingest_usage
| summarize cost=sum(cost_usd) by signal, retention_tier
| order by cost desc
// a typical split-stack customer, pre-migration:
// logs / hot: $14,200/mo, queried past 7 days: 3% of it

What one store actually saves

Beyond storage, unified retention and a single ingestion path mean a customer we migrated last quarter cut their total observability spend 34% simply by aligning retention across signals to match actual query patterns — something that was operationally possible before, but nobody owned the cross-tool project to do it.

The honest limitation

A unified store is a harder engineering problem, and it means we can't always match a best-of-breed point solution's depth on day one for any single signal — our profiling took longer to reach parity with dedicated profilers for exactly this reason. We think that trade is worth it once, permanently, rather than customers paying the integration tax forever.

The metric that convinced our own finance team

Internally, the argument that finally settled this wasn't a customer story, it was our own vendor bill before we ate our own dog food fully: we were running four different tools for our own staging environment telemetry two years ago, paying separate minimum commitments to each, and consolidating onto our own single store cut our internal observability spend by a little over half before we'd optimized anything else about it. That number is what got skeptical engineers on the team to stop asking why we kept saying no to a dedicated logs product.

  • One ingestion path, one retention model, across metrics, logs, traces, and profiles
  • Median migrated customer: 34% total spend reduction from aligned retention alone
  • No duplicated metadata tagging across separate tools
  • Trade-off: slower to reach point-solution depth on any single signal at launch