For a Series B company with ~60 engineers, already on OpenTelemetry, I would not start by rebuilding a “DIY Datadog” from primitives unless your team has spare SRE capacity. The biggest trap is replacing one expensive platform with five open-source systems you now have to operate.

Your shortlist should focus on OTel-native platforms that already correlate logs + metrics + traces:

PlatformBest fitWhy evaluateMain tradeoffSigNozClosest Datadog replacementSingle UI for logs, metrics, traces; built around OpenTelemetry; strong APM workflowYou operate ClickHouse/storage components yourselfGrafana + Loki + Tempo + MimirTeams with Kubernetes/SRE maturityExtremely flexible, huge ecosystem, cloud-nativeMore assembly and operational ownershipOpenObserveCost-sensitive log-heavy environmentsUnified logs/metrics/traces, designed around lower-cost storage patternsSmaller ecosystem and fewer enterprise integrationsUptraceEngineering teams wanting a lighter APM experienceOTel-first, simpler than a full Grafana stackSmaller community/ecosystem

SigNoz (+2 more citation)

My evaluation order for your situation

1. SigNoz — first POC

This is the closest match to your stated requirements:

• Keep existing OpenTelemetry instrumentation

• Unified logs, metrics, traces

• APM-style workflows (service latency, errors, trace drill-down)

• Fewer moving pieces than assembling Grafana components

SigNoz positions itself as an OpenTelemetry-native Datadog alternative and supports self-hosted deployment with logs, metrics, and traces in one application. SigNoz (+1 more citation)

For a 60-engineer startup, I would test:

• Can developers find a slow request in <2 minutes?

• Can you go from alert → service → trace → logs?

• Does ingestion cost stay predictable with your current cardinality?

• How painful are upgrades/backups?

A realistic GCP deployment might be:

Apps | OpenTelemetry SDKs | OpenTelemetry Collector | SigNoz | ClickHouse + object storage

---

2. Grafana stack — if you already have platform/SRE depth

The “classic” open stack:

OTel Collector | +--> Mimir (metrics) +--> Loki (logs) +--> Tempo (traces) +--> Grafana (UI)

This is probably the most future-proof architecture, but it is also the closest thing to building your own observability platform.

I would choose it if:

• You already run Kubernetes seriously

• You have someone comfortable operating Prometheus-style systems

• You want maximum customization

• You expect observability itself to become a platform capability

I would avoid it if your goal is simply “stop paying Datadog.”

---

3. OpenObserve — worth a cost-focused bakeoff

OpenObserve is interesting if your Datadog bill is being driven heavily by logs. It supports ingesting logs, metrics, and traces through OpenTelemetry Collector and other sources, with a unified interface. OpenObserve (+1 more citation)

Questions I would test:

• Query latency on your real production logs

• Retention cost vs Datadog

• Trace/log correlation quality

• Alerting maturity

---

What I would not do

❌ Replace Datadog with separate tools

Example:

• Pro

Given your constraints:

• ~60 engineers (large enough that developer experience matters)
• Rapid growth (you don't want to re-platform again in a year)
• Already standardized on OpenTelemetry (this is a major advantage)
• Self-hosting in GCP is acceptable
• You want logs + metrics + traces in one place, not three loosely connected UIs
• Primary motivation is reducing Datadog costs

I'd focus on platforms that treat OpenTelemetry as a first-class citizen rather than requiring proprietary agents.

1. Grafana (my top recommendation)

The "LGTM" stack combines:

• Grafana
• Loki
• Tempo
• Mimir

Why it fits

This has become the closest thing to the open-source Datadog ecosystem.

Strengths:

• Excellent OpenTelemetry support
• Unified UI
• Cross-linking between logs, metrics, and traces
• Massive community
• CNCF-friendly
• Very active development
• Mature Kubernetes support

Tempo is particularly attractive because trace storage is dramatically cheaper than many APM vendors since it indexes very little metadata.

Downsides

Running Mimir at scale is nontrivial.

If you're only collecting infrastructure metrics plus application metrics for a startup, it isn't terrible, but you'll want engineers comfortable operating distributed storage.

---

2. SigNoz

If someone asked for "open-source Datadog," this is probably the closest answer.

It includes:

• logs
• metrics
• traces
• dashboards
• alerts

built together.

Pros

• Built around OpenTelemetry
• Very easy migration
• Unified data model
• Good trace UX
• Easier to operate than assembling four different projects
• Lower operational overhead

Cons

Smaller ecosystem than Grafana.

Less mature in some enterprise capabilities, although it's improved significantly over the past couple years.

For a 60-engineer startup I'd absolutely evaluate it.

---

3. HyperDX

This has become increasingly interesting.

It's built around:

• OpenTelemetry
• ClickHouse
• unified observability

Strengths

Excellent developer experience.

Fast search.

Very modern UI.

Logs-first workflow with traces tightly integrated.

ClickHouse makes ad hoc exploration very fast.

Weaknesses

Smaller community than Grafana.

Still younger than Grafana's ecosystem.

---

4. OpenObserve

A newer entrant.

Everything stored in object storage.

Designed around cost efficiency.

Pros:

• simple architecture
• logs
• metrics
• traces
• SQL queries
• inexpensive storage

Worth testing if operational simplicity matters.

---

5. Elastic Observability

Includes

• logs
• metrics
• traces
• profiling
• dashboards

Pros

Very mature.

Excellent search.

Powerful querying.

Cons

Operational complexity.

Historically expensive if you buy commercial licenses.

The open-source story has become more complicated over time because of licensing changes.

I'd only choose it if your company already runs the Elastic stack.

---

6. Jaeger + Prometheus + Grafana + Loki

This used to be the standard open-source stack.

I wouldn't recommend starting here in 2026.

It's effectively a collection of separate systems rather than a unified observability platform.

---

Architecture I'd build today

Since you're already using OpenTelemetry:

Applications
      │
      ▼
OpenTelemetry SDKs
      │
      ▼
OpenTelemetry Collectors
      │
      ├── logs
      ├── metrics
      └── traces
              │
              ▼
Observability backend

Keep the collectors independent of the backend.

That gives you vendor portability forever.

If you switch platforms later, you mostly change collector exporters.

---

Cost characteristics

Approximate relative infrastructure cost (not licensing):

Platform	Storage efficiency	Operational complexity
Grafana LGTM	Excellent	High
SigNoz	Very good	Low–Medium
HyperDX	Very good	Medium
OpenObserve	Excellent	Low
Elastic	Good	High

For most startups, people underestimate the cost of operating observability infrastructure. Saving $100k/year in SaaS spend isn't a win if it requires half an SRE's time.

---

Scaling considerations

For roughly 60 engineers, I'd expect:

• hundreds of services
• billions of log lines/month
• tens of millions of spans/day
• Kubernetes
• autoscaling

All four of these can comfortably handle that scale:

• Grafana
• SigNoz
• HyperDX
• OpenObserve

The operational burden differs more than the raw scalability.

---

What I'd actually evaluate

If I were making this decision today, I'd narrow it to three options:

1. Grafana if you expect to build a mature platform engineering function and don't mind running multiple backend components. It has the broadest ecosystem and is likely the safest long-term choice.

2. SigNoz if your priority is a cohesive, Datadog-like experience with lower operational overhead while staying fully OpenTelemetry-native. It strikes a strong balance between capability and simplicity for a Series B engineering organization.

3. HyperDX if developer experience and fast exploratory debugging are top priorities, and you're comfortable adopting a newer platform.

One additional suggestion: regardless of which backend you choose, invest in an OpenTelemetry Collector layer that handles sampling, filtering, enrichment, and routing before data reaches storage. Dynamic sampling, dropping low-value logs, and controlling metric cardinality often reduce observability costs by an order of magnitude while preserving the signals engineers rely on. That architecture also keeps you decoupled from any single backend, making future migrations much less disruptive.