“I run a platform team at a mid-size B2B SaaS company and we're being asked to cut our cloud tool spend by 40 percent this quarter. Observability is our biggest line item. We send all telemetry via OpenTelemetry and I'm evaluating whether we can self-host a full-stack APM solution in Azure to replace our current vendor. My main concern is long-term data retention since we need at least 18 months of metrics and traces for incident retrospectives. Which self-hosted APM platforms handle long-term retention well and what should I know about storage costs before committing?”

For a mid-size B2B SaaS team already standardized on OpenTelemetry, the good news is you are looking at the right layer: you can replace many commercial APM vendors without changing instrumentation. The harder part is not dashboards or ingestion — it is retention economics. Keeping 18 months of traces is usually the cost driver, not the APM UI.

The short list I would evaluate:

PlatformBest fit18-month retention storyMain storage concernGrafana Tempo + Grafana Mimir + Grafana LokiTeams willing to assemble a stackExcellent for long retention because traces can live in object storageYou must operate multiple componentsSigNozTeams wanting a more integrated APM replacementGood if you tune ClickHouse retention and storage tiersClickHouse disk growth can surprise youElastic ObservabilityTeams already comfortable with ElasticsearchMature lifecycle controlsElasticsearch storage is expensive at long retentionUptraceSmaller teams wanting OTEL-native APMPossible with ClickHouse tuningSmaller ecosystem

Grafana Tempo is probably the strongest architectural match for your specific requirement because it was designed around storing traces cheaply. Tempo uses object storage for long-term trace data and supports Azure Blob Storage as a backend. Grafana Labs The pattern is typically: keep recent traces on fast storage, then age them into cheaper blob tiers.

SigNoz is attractive if you want a more “Datadog/New Relic-like” experience without assembling Grafana components. It is OpenTelemetry-native and uses ClickHouse as its telemetry store. SigNoz The catch is that ClickHouse is still a database you operate: replication, disks, merges, backups, and retention policies become your responsibility. SigNoz

Elastic Observability has very mature lifecycle tooling. Its index lifecycle management lets you automate rollover and deletion policies for APM data streams. elastic.co However, keeping high-cardinality traces for 18 months in Elasticsearch can become expensive because you are paying for indexed storage, not just compressed blobs. elastic.co

The retention trap: traces are not metrics

A common mistake is budgeting “18 months of telemetry” as one number.

A rough model:

Monthly storage = traces ingested/day + metrics samples/day + indexes/metadata overhead + replication factor + backups

In most SaaS environments:

• Metrics compress extremely well and are relatively cheap.

• Traces explode because every request creates spans.

• Logs often dominate everything if retained at full fidelity.

For example, if you ingest:

• 500 GB/day raw traces

• 30-day hot retention

• 18-month archive retention

You are not looking at a 500 GB problem. You are looking at:

• Hot tier: ~15 TB

• Archive tier: ~270 TB before compression/compaction

The architecture matters more than the software choice.

Azure cost model to think through

For Azure, I would separate storage into tiers:

1. Hot query tier (days/weeks)

Used for active debugging.

Examples:

• Managed disks for ClickHouse

• VM SSDs

• Elasticsearch data nodes

Keep this short.

Typical policy:

• 7–30 days traces

• 30–90 days metrics

2. Cheap retention tier (months/years)

Used for retrospectives.

Examples:

• Azure Blob Storage Cool/Archive tiers with Tempo

• Exported ClickHouse parts

• Parquet files

This is where 18-month retention becomes financially viable.

3. Sampling and aggregation

Before storage, reduce volume:

• Keep 100% of errors

• Keep 100% of slow traces

• Keep representative samples of healthy requests

• Preserve span attributes needed for retrospectives

A 10x reduction in trace volume is often realistic.

My evaluation order for your situation

Given:

• B2B SaaS

• Azure

• OpenTelemetry already deployed

• 18-month incident retrospective requirement

• 40% cost reduction target

I would run a proof of concept in this order:

Option 1 — Grafana stack (most likely winner)

Architecture:

Given your constraints, the key challenge is actually less about the APM UI and more about the storage architecture.

A modern APM stack is typically three layers:

1. OpenTelemetry collectors (which you already have)
2. Storage backends for traces, metrics, and logs
3. Query/UI layer

Because you're already standardized on OpenTelemetry, you can swap the backend without changing instrumentation, which gives you flexibility.

The first question: do you really want to retain all telemetry for 18 months?

Very few organizations keep every trace and high-resolution metric for that long because of cost.

A common pattern is:

• Full-resolution metrics: 30–90 days
• Downsampled metrics: 18–24 months
• Full traces: 7–30 days
• Indexed "important" traces: 6–18 months
• Logs: varies by compliance requirements

If your incident retrospectives genuinely require every trace for 18 months, storage costs will dominate regardless of vendor.

---

Platforms worth evaluating

Grafana LGTM Stack

Components:

• Grafana
• Mimir
• Tempo
• Loki

This is probably the most common self-hosted OpenTelemetry stack today.

Long-term retention

Very good.

Tempo and Mimir were designed around object storage rather than expensive local disks.

Typical deployment:

• Azure Blob Storage
• small SSD cache
• Kubernetes
• inexpensive object storage for historical data

Advantages:

• traces compress well
• object storage scales almost indefinitely
• retention policies are straightforward

Storage economics are among the best of any open-source stack.

---

Jaeger

Jaeger has excellent OpenTelemetry compatibility.

However, long-term retention depends entirely on the storage backend.

Historically people used:

• Elasticsearch
• Cassandra

Today object-storage backends are becoming more attractive, but Jaeger is primarily a tracing system rather than a full observability platform.

If you're replacing a commercial APM, Jaeger alone is usually insufficient.

---

SigNoz

One of the nicer all-in-one OpenTelemetry-native platforms.

Uses:

• ClickHouse
• OpenTelemetry Collector

Pros:

• easy deployment
• integrated dashboards
• good trace exploration

Retention:

Reasonably good, but ClickHouse storage grows quickly when retaining high-cardinality telemetry for long periods.

For 18 months of heavy production traffic, storage planning becomes important.

---

HyperDX

Uses ClickHouse.

Nice developer experience.

Good OpenTelemetry support.

Long retention is possible, but again you're primarily paying for ClickHouse storage rather than the application itself.

---

Apache SkyWalking

Very mature.

Good for:

• service maps
• JVM-heavy environments
• topology analysis

Supports several storage engines.

Can retain data for long periods but operational complexity is higher than LGTM.

---

Storage matters far more than the UI

For 18-month retention, your storage choice has more impact than the APM software.

Object storage approach (recommended)

Examples:

• Tempo → Azure Blob
• Mimir → Azure Blob

Benefits:

• inexpensive
• essentially unlimited retention
• easy lifecycle management
• replication handled by Azure

This is currently the dominant architecture for cloud-native observability.

---

ClickHouse

Advantages:

• extremely fast
• excellent compression
• SQL analytics

Disadvantages:

• disks continue growing
• cluster expansion required
• operational tuning
• compaction
• backups

Storage cost is lower than Elasticsearch but higher operational overhead than object-storage-first systems.

---

Elasticsearch/OpenSearch

Historically the default.

For long retention:

• expensive
• large SSD footprint
• indexing overhead
• many operators eventually move away because storage becomes the primary cost driver

For traces especially, this architecture is becoming less attractive.

---

Azure-specific considerations

If you're already committed to Azure:

Azure Blob Storage is likely your biggest cost lever.

Many teams use:

• Premium SSD only for active ingestion
• Blob Storage Hot for recent data
• Blob Storage Cool for older telemetry
• Blob Storage Archive only if data is rarely accessed (retrieval latency and costs make it unsuitable for interactive investigations)

Lifecycle policies can automatically transition older objects between tiers.

---

Metrics are usually the real expense

People often expect traces to be the largest cost.

In practice:

• High-cardinality metrics often consume the most long-term storage.
• Logs are usually second.
• Traces can actually compress surprisingly well in object storage.

The biggest driver isn't volume alone—it's cardinality. Metrics labeled with dimensions like customer ID, request path, container ID, or ephemeral pod names can multiply storage and indexing requirements.

---

Hidden infrastructure costs

When teams compare against a SaaS observability bill, they often focus only on storage. Don't overlook:

• Kubernetes worker nodes for ingestion and query services
• Persistent SSD volumes for caches and indexes
• Azure Blob Storage capacity
• Cross-region replication, if required
• Backup and disaster recovery
• Monitoring the observability platform itself
• Engineering time for upgrades, scaling, and on-call support

Many organizations find that infrastructure accounts for only part of the total cost; operating the platform becomes a significant ongoing investment.

Recommendation

For a mid-size B2B SaaS company already using OpenTelemetry and Azure, the strongest starting point would be the Grafana LGTM stack:

• Metrics: Mimir backed by Azure Blob Storage
• Traces: Tempo backed by Azure Blob Storage
• Logs: Loki if you also want log consolidation
• Visualization: Grafana

This architecture is specifically designed for long retention using low-cost object storage, scales well with OpenTelemetry, and is widely adopted for organizations looking to reduce SaaS observability spend.

One final point: if the goal is a 40% reduction in cloud tool spend, model your projected telemetry volume (GB/day, active series, spans/day, and query patterns) before committing. Whether a self-hosted platform is cheaper than a managed vendor depends heavily on those inputs. At moderate scale, self-hosting can produce substantial savings, but at very high scale or with small platform teams, operational costs can offset much of the licensing reduction. A retention and ingestion cost model based on your actual telemetry rates is usually the best way to determine the break-even point.