If your main goal is eliminating per-GB ingestion pricing while keeping logs and distributed traces together, then you're really evaluating storage architecture and operational burden more than feature lists.

For an environment with ~150 microservices, the strongest self-hosted options are:

Platform	Logs	Traces	Metrics	Unlimited retention?	Operational overhead
Grafana LGTM Stack	✅	✅	✅	Yes (depends on storage)	Medium
SigNoz	✅	✅	✅	Yes	Low–Medium
OpenObserve	✅	✅	✅	Yes	Low
Elastic Stack	✅	✅	✅	Yes	High
OpenSearch	✅	✅	✅	Yes	High
Jaeger + Loki	Partial	✅	No	Yes	Medium–High
HyperDX	✅	✅	Limited	Yes	Medium

The key point is that none of these impose a per-GB software licensing limit. Retention is constrained only by your storage capacity and infrastructure budget.

1. Grafana LGTM Stack

This consists of:

• Loki (logs)
• Tempo (traces)
• Mimir (metrics)
• Grafana (UI)

Pros:

• Designed around inexpensive object storage
• Excellent OpenTelemetry support
• Very mature ecosystem
• Trace ↔ log correlation works well
• Horizontal scaling is well understood
• Object storage makes long retention relatively inexpensive

Cons:

• Multiple components
• More Kubernetes objects
• Requires tuning compaction, object storage, cache layers
• Operational complexity grows with scale

Operational overhead:

Medium

At your size (~150 services), many organizations comfortably run LGTM, but someone needs to own upgrades, storage lifecycle, and scaling.

---

2. SigNoz

Probably the closest experience to commercial SaaS observability.

Pros:

• Unified UI
• Logs + traces + metrics
• Native OpenTelemetry
• Good service maps
• Simpler deployment than LGTM
• Built specifically as an observability platform rather than assembling separate projects

Historically it used ClickHouse as its storage engine, which performs very well for observability workloads. ClickHouse underpins much of its query performance.

Operational overhead:

Low to Medium

Compared to LGTM:

• fewer moving pieces
• easier upgrades
• less configuration

For a mid-sized engineering team this is often one of the easiest self-hosted choices.

---

3. OpenObserve

A newer design that stores observability data in object storage while minimizing infrastructure.

Pros:

• Single binary deployment available
• Logs
• Metrics
• Traces
• SQL querying
• Fast ingestion
• Lower infrastructure footprint

Operational overhead:

Low

Potential downside:

• Smaller ecosystem
• Fewer production case studies than Grafana or Elastic
• Community is younger

If minimizing operational work is your highest priority, this is worth serious evaluation.

---

4. Elastic Stack

The traditional choice.

Pros:

• Extremely mature
• Powerful search
• Excellent log analysis
• Strong tracing support
• Rich dashboards

Cons:

• Cluster management
• JVM tuning
• Index lifecycle management
• Storage can become expensive
• Scaling Elasticsearch clusters requires expertise

Operational overhead:

High

Many organizations eventually dedicate engineers specifically to maintaining Elastic clusters.

---

5. OpenSearch

A fork of Elasticsearch.

Pros:

• Familiar if you know ELK
• Strong observability plugins
• Self-hosted
• Large ecosystem

Cons:

• Similar operational complexity
• Storage-heavy
• Heap tuning
• Index management

Operational overhead:

High

---

6. Jaeger + Loki

This is more of a "build your own stack."

Pros:

• Mature tracing
• Mature logging
• Flexible

Cons:

• No truly unified backend
• Multiple operational domains
• More integration work

Operational overhead:

Medium–High

---

7. HyperDX

Focused on developer experience.

Pros:

• Unified observability
• OpenTelemetry
• Modern UI
• Good trace/log correlation

Cons:

• Smaller ecosystem
• Younger project
• Less battle-tested at very large scale

Operational overhead:

Medium

---

Retention considerations

Technically every one of these platforms can retain data indefinitely.

The real limit is storage.

Typical architectures:

• SSD for recent hot data
• Object storage for warm/cold data
• Retention policies managed by lifecycle rules

For example:

• 30 days on NVMe
• 1 year on object storage
• 5 years archived

You are paying for disks or object storage—not for ingestion volume.

---

Operational burden comparison

Approximate ranking from least to most operational effort:

1. OpenObserve ⭐
2. SigNoz
3. Grafana LGTM
4. HyperDX
5. Jaeger + Loki
6. OpenSearch
7. Elastic

---

For an organization with ~150 microservices

Assuming:

• Kubernetes
• OpenTelemetry already deployed or planned
• High log volume
• Heavy distributed tracing
• Cost pressure from SaaS ingestion pricing

I'd narrow the evaluation to three options:

• SigNoz if you want the closest "single product" replacement for a SaaS observability platform with relatively low operational burden.
• Grafana LGTM Stack if you prioritize ecosystem maturity, flexibility, and long-term scalability, and you're comfortable operating several components.
• OpenObserve if minimizing infrastructure and operational complexity is the highest priority and you're comfortable adopting a newer project.

One important caveat: self-hosted does not make retention "free." It removes vendor per-GB licensing, but you'll still need to budget for storage, backups, replication, and the engineering effort to operate the platform. For organizations ingesting multiple terabytes of logs and traces per day, storage architecture (especially the use of object storage with lifecycle policies) often has a bigger impact on total cost than the observability software itself.

For a 150-microservice e-commerce platform, I would separate two concepts:

• “Unlimited retention” in self-hosted systems usually means the software does not charge you per GB or enforce a retention limit. You still pay in disks, object storage, compute, indexing, and operational complexity.

• The best architectures at your scale generally avoid a single monolithic database and use horizontally scalable stores with cheap object storage.

The strongest candidates today are:

PlatformLogsTracesMetricsRetention modelOps overheadFit for ~150 servicesGrafana LGTM StackLokiTempoMimirUnlimited (you control storage lifecycle)Medium–High⭐⭐⭐⭐⭐SigNozYesYesYesUnlimited if self-hostedMedium⭐⭐⭐⭐⭐OpenSearch + JaegerOpenSearchJaeger/OpenTelemetry tracesLimited/native alternativesUnlimited if you manage indexesHigh⭐⭐⭐Elastic ObservabilityElasticsearchAPM tracesMetricsUnlimited if self-managedHigh⭐⭐⭐⭐

1. Grafana LGTM Stack — probably the default choice for your situation

Grafana LGTM Stack combines:

• Grafana Loki → logs

• Grafana Tempo → traces

• Grafana Mimir → metrics

• Grafana → UI/correlation

The stack is designed around separate scalable backends rather than one giant indexed store. Grafana Labs Community Forums (+1 more citation)

Retention model

• No SaaS ingestion meter.

• Retention is your storage policy:

S3-compatible object storage (AWS S3, MinIO, Ceph, etc.)

• lifecycle policies

• compaction

• tiering

So “keep 3 years of traces/logs” becomes a storage architecture question, not a vendor bill.

Operational overhead

Medium–high:

• Kubernetes deployment recommended.

• You operate:

collectors

• Loki

• Tempo

• Mimir

• object storage

• Grafana

• upgrades/backups/scaling

For your size, the operational model is reasonable if your SRE team already runs Kubernetes.

Main downside

The stack is powerful but not a single product. Correlation works well, but you own the integration.

---

2. SigNoz — lower operational burden, more “Datadog replacement” feel

SigNoz is closer to a unified observability product:

• logs

• metrics

• traces

• dashboards

• alerts

• OpenTelemetry-native ingestion

It positions itself as an OpenTelemetry-native platform combining logs, metrics, and traces. SigNoz

Architecture:

• OpenTelemetry Collector

• ClickHouse storage

• SigNoz services/UI

Retention model

Self-hosted SigNoz does not impose SaaS-style GB ingestion billing; retention is controlled by your infrastructure sizing and ClickHouse retention policies. (The hosted offering does still use usage-based pricing.) SigNoz

Operational overhead

Lower than LGTM:

• fewer independent components

• one primary query/storage backend

• easier onboarding for developers