DEV Community: CubeAPM

CubeAPM: Evaluating a New Relic Alternative for Cost, Control, and Scale

CubeAPM — Wed, 22 Apr 2026 04:37:33 +0000

*Originally published on cubeapm.com

As organizations adopt cloud-native architectures, Kubernetes, and microservices, systems have become more distributed and generate significantly higher volumes of telemetry than traditional monitoring models were built for.

This article is written for teams running production workloads at scale, especially Kubernetes-based SaaS platforms, who are reassessing whether their current observability setup still aligns with cost predictability, governance requirements, and long-term architectural needs.

New Relic is one of the earliest full-stack observability platforms and continues to offer strong capabilities. However, as systems scale, factors such as cost behavior, data control, and flexibility begin to influence platform decisions. This article explains when and why that re-evaluation happens, and how platforms like CubeAPM fit into the next phase.

How New Relic Shaped Modern Application Observability

New Relic is an observability platform that teams use to monitor their applications and systems. You can use it to track issues, such as slow APIs, errors, or user experience, and so on. It offers capabilities, such as application performance monitoring (APM), log monitoring, infrastructure monitoring, digital experience monitoring, and more. New Relic is one of the earliest observability tools.

When cloud adoption picked up and teams started moving to microservices, many existing monitoring tools fell short. They were host-focused, fragmented, and hard to connect back to real application behavior. New Relic introduced a compelling model:

A single SaaS platform
Unified visibility across metrics, logs, traces, and application performance
Minimal operational overhead
Fast onboarding for engineering teams

This approach fundamentally changed expectations. Engineers began to expect service maps, end-to-end tracing, and correlated signals instead of stitching together multiple tools. Many observability platforms today still follow this model because it solved real problems for growing teams.

For small teams or early-stage products prioritizing speed and simplicity, this SaaS-first approach can still be a strong fit.

Understanding New Relic’s Observability Model as Systems Grow

New Relic still works well for teams that want a SaaS-first experience and fast onboarding. But issues, such as high cost, become a problem when your telemetry volume, service count, and team size increase, although these are not unique to New Relic.

Predicting Cost Becomes Difficult as Telemetry Scales

New Relic’s pricing is usage-based across data ingestion and user access. It may feel simple at first, but multiple cost dimensions can compound quickly as your systems grow.

Data Ingestion Cost

As systems scale:

Telemetry volume increases with traffic and service count
Spikes during incidents or deployments become more common
Monthly usage becomes harder to forecast

Every New Relic account gets 100 GB of data ingest free per month. After that, additional telemetry data is billed at $0.40 per GB under the standard data pricing tier.

There is also an optional “Data Plus” pricing tier with higher per-GB rates ($0.60/GB).

Since logs, metrics, traces, and events all count in this usage pool, spikes in telemetry volume during incidents or deployments can cause the bill to rise higher and can be hard to predict.

User Access Costs

New Relic also charges for user roles:

Basic users (free)
Paid roles such as Core and Full Platform users

As engineering teams grow, user-based pricing introduces a second axis of spend that compounds alongside data ingestion.

Core users are priced at $49 per user per month, and Full Platform users are commonly priced at $99 per user per month in standard pricing and $349 per user per month in the Pro plan.

As teams grow and more engineers need observability access, this user cost adds a second axis of spend that is separate from data ingestion.

Computer Capacity Units (CCUs) Costs

New Relic has introduced a Compute-based pricing model built around Compute Capacity Units (CCUs). Instead of charging per user, costs are tied to the compute consumed by customer-initiated queries and analysis actions, aiming to align spend with actual platform usage.

Key characteristics:

All users get full platform access with no per-user fees
Costs scale with query and analysis activity, not just data ingest
Failed requests and select internal queries are excluded from billing
Compute budgets and alerts help teams monitor CCU usage

Multiple dimensions compounding

New Relic’s billing is not limited to just telemetry volume or hosts. You pay for:

How much data you ingest above the free tier, and
How many engineers need access to the platform

A team that suddenly enables more detailed tracing, increases log verbosity, or invites more users can see costs rise from several angles at once.

Also, small changes in telemetry volume could mean larger-than-expected bills because ingest and user costs both contribute to the total spend.

Here’s what medium-sized businesses may end up paying*:

Data ingestion ($0.40 x 45,000 GB) = $18,000
Full Users (20% of all engineers) = $349 x 10 = $3,490
Observability Cost = $21,490
Observability data out cost (charged by cloud provider) (45k x $0.10/GB) = $4,500

Total Observability Cost (mid-size team) = $25,990

_*All pricing comparisons are calculated using standardized Small/Medium/Large team profiles defined in our internal benchmarking sheet, based on fixed log, metrics, trace, and retention assumptions. Actual pricing may vary by usage, region, and plan structure. Please confirm current pricing with each vendor.
_

Why forecasting cost becomes harder:

Early on, free data credits and a small number of paid users make monthly costs feel predictable.

But once telemetry volume grows beyond the free 100 GB and user counts increase, finance and engineering teams often have to track multiple pricing levers instead of a single predictable cost line.

This makes it harder to align observability value with budget commitments when usage fluctuates monthly.

Why Cost Behavior Matters More Than Price

Early on, observability costs feel predictable. Free credits and limited usage make monthly spend easy to reason about.

As telemetry scales, however, costs begin to fluctuate based on:

Traffic patterns
Incident frequency
Instrumentation depth
Team size

At this stage, teams care less about headline pricing and more about how costs behave over time whether they grow linearly and predictably, or spike unexpectedly.

This distinction is central to why teams begin evaluating a New Relic alternative.

OpenTelemetry Support vs Vendor-Specific Workflows

An OpenTelemetry-compatible platform means it can ingest OTel data.
An OpenTelemetry-native platform means the entire observability pipeline, from data processing to querying and controls, is built around OpenTelemetry concepts.

New Relic fits the first category. It may work fine for some. But it may create issues for teams that are planning long-term portability and vendor-neutral workflows. Let’s understand this deeply.

New Relic supports OpenTelemetry (OTel). You can send metrics, logs, and traces using OTel SDKs and the Collector. This means you are not forced to use a proprietary agent just to get data in. Teams that standardize OpenTelemetry can easily adopt it without lock-ins.

Where things start to feel different is after the data lands. In daily work, most teams still rely heavily on New Relic’s own workflows. Dashboards are built using NRQL. Alerts are defined around New Relic entities. Troubleshooting usually happens inside New Relic’s UI using its views and concepts. Over time, that team became heavily reliant on them.

This creates an important distinction.

Although OpenTelemetry is there to keep you flexible at the collection layer, many operational workflows are still tied to the platform itself.
Moving raw telemetry somewhere else is possible. However, recreating years of dashboards, alerts, and runbooks is much harder.
That makes switching the tool difficult for teams.

SaaS-Only Platform

New Relic is a pure SaaS-based platform. Customers don’t have to run the infrastructure themselves. It’s easy to set up, so they can start monitoring systems right away. For many teams, this simplicity is a major advantage early on.

But when systems and requirements grow, trade-offs start becoming more visible:

Because the platform is SaaS-only, all telemetry data is stored and processed in New Relic’s managed infrastructure.
Data residency, access control, and retention are tied to platform defaults and plan tiers.
Meeting internal security, compliance, or regional data requirements can require extra coordination.
Organizations with strict security and compliance standards want more data control. So, they may start exploring options such as BYOC or self-hosted observability to regain control over data.

Complex Alerting

New Relic’s alerting is manageable when services, thresholds, and alerts are fewer. Alerts change per metric or service. So, the number of alerts grows when services add up, which increases maintenance, too.

Threshold-based alerts struggle: New Relic supports static thresholds and baseline alerts. In auto-scaling or high-traffic environments, alerts can be noisy or missed.

Root cause is not always clear during incidents: When multiple services trigger alerts at once, engineers must manually correlate signals to find the root cause. Downstream alerts often appear alongside the real issue, slowing investigation and increasing MTTR.

When dozens or hundreds of services emit alerts at the same time, it is difficult to tell what actually caused the problem versus what is just a symptom. This is often when teams start rethinking alerting strategy. Their interest shifts toward context-driven alerting that considers errors, latency, and service relationships together, with lower noise, without hiding incidents.

Retention Policies

Retention starts to matter once your team needs to look back in time. Day-to-day alerts are useful, but audits, year-over-year analysis, and deep investigations require older data. Retention policies really show their impact here.

With New Relic, retention varies by data type and plan level, and defaults are relatively short unless you extend them:

Most core data like APM, errors, and infrastructure signals are retained for about 8 days by default under standard settings.

Browser session and many telemetry types may also follow similar default retention unless changed in the Data retention UI.

Logs and other event data typically default to 30 days unless you configure extended retention.

With the Data Plus option, teams can extend retention for many data types up to around 90 days or more. Also, you can unlock higher compliance capabilities like longer query periods and export tools.

New Relic also offers live archives for logs. It can store logs for up to 7 years but at additional cost and with separate billing for archive storage and queries.

Because retention periods are tied to pricing tiers and add-ons, teams often face choices like:

Paying more to keep data longer
Keeping only a short history accessible
Or, exporting data elsewhere for compliance

Because of this, many teams may feel retention decisions are driven mostly by cost mechanics rather than engineering or business needs. So, they may begin looking for New Relic alternatives when long-term observability becomes a priority. They want predictable access to historical data without rising vendor costs.

The Inflection Points That Trigger a New Relic Re-Evaluation

Teams rarely replace observability platforms overnight. Re-evaluation usually happens when several signals appear together:

Observability spend starts requiring finance approval: What was once an engineering expense becomes a line item finance wants to forecast. Usage-based ingest, users, and feature tiers start moving together, and monthly costs become harder to explain or predict.
High Kubernetes and service count: Telemetry volume increases with higher Kubernetes and service counts. Dashboards and alerts become slower.
Alert noise: More signals don’t always mean more clarity. Teams notice they are spending more time triaging notifications than fixing the underlying issue, which directly affects MTTR.
Retention and audits: You may need data from months back for reviewing incidents, maintaining compliance, and analysing trends. When retention is based on the plan or available as an add-on, it can add to the cost.
Coupling: Over time, you may feel your dashboards, alerts, and queries have become highly reliant on the platform. When observability tooling starts influencing how services are designed or instrumented, teams pause and reassess long-term flexibility.

These inflection points appear gradually. When several show up together, teams start asking whether it still fits where their system is headed.

Why Teams Consider CubeAPM as a New Relic Alternative

CubeAPM is built on the belief that observability should be owned and controlled like your infrastructure, not metered like a SaaS bill. Here are reasons why many teams consider CubeAPM as a New Relic alternative.

Key differences include:

-** OTel-native architecture**: Teams want to instrument once and keep their options open. With tools that support OpenTelemetry, telemetry is portable across tools. This helps reduce vendor lock-ins.

Predictable pricing: Modern teams care less about the lowest starting price and more about how costs behave over time. Pricing models that scale linearly with usage and avoid compounding dimensions are easier to plan and defend.
Unified MELT: Metrics, events, logs, and traces need to work together. Teams want to quickly get to the root cause without referring to multiple tools or correlating data manually to understand the context.
Self-hosted/BYOC deployment: Runs in customer-controlled infrastructure, offering control over data location, access, and retention.
Unlimited retention: Retains logs, metrics, traces, and events without tier-based limits.
Context-aware, Smart Sampling: CubeAPM offers context-based Smart Sampling that preserves important signals, such as errors and suspicious requests, and drops routine data to reduce noise and storage overhead.
Access to Human support: Direct access to engineers via Slack or WhatsApp during critical situations.
Flexible setups: Teams want multiple setup options. Some teams may prefer SaaS for convenience. Others may need BYOC or self-hosted tools for compliance.
Data control: Observability data can be sensitive. Teams want complete clarity over data storage location, who can access the data, and the retention period.
Developer-friendly: Engineers want fast and reliable data for investigating incidents. They value tools that offer deep context with less noise.
800+ integrations: CubeAPM integrates with many services, languages, frameworks, and data sources. It can easily fit into your current tech stacks.
Zero egress costs: Since data stays within the customer’s cloud or on-prem infrastructure, there are no additional egress charges for moving data out.

If you want to explore feature-wise differences, check out our CubeAPM vs New Relic page.

Migration Strategies for Teams Evolving Beyond Traditional SaaS APM

Teams rarely migrate in one big step. Most successful transitions focus on reducing risk and evolving architecture gradually.

Incremental OTel adoption: Teams usually start by instrumenting new services with OpenTelemetry while leaving existing services unchanged. Teams can standardize instrumentation without full rewrites.
Parallel observability: Teams run multiple observability pipelines side by side. This makes it possible to compare data, validate coverage, and build confidence before committing fully.
Agent reuse: Many teams reuse their current agents or collectors when migrating to another tool. This reduces operational overhead and doesn’t disrupt production systems.
Moving alerts and workflows: Teams can move their alerts, dashboards, and runbooks gradually, instead of all at once. This way, you can keep your vital alerts intact and also keep testing and refining new workflows.

Case Study: Why a SaaS Team Began Evaluating a New Relic Alternative at Scale

Problem

A mid-scale B2B SaaS company running a cloud-native platform adopted New Relic early because it was quick to set up and gave unified visibility across the stack. That worked well in the beginning. Over time, the platform grew to hundreds of services running on Kubernetes and handling high-throughput production workloads. Telemetry volume rose steadily, costs became harder to forecast month to month, and alert noise increased as more services and dependencies were added.

Although New Relic supported OpenTelemetry ingestion, most day-to-day work still depended on New Relic-specific agents, dashboards, and alert definitions. This made it harder for the team to reason about long-term flexibility. At the same time, new enterprise customer requirements introduced stricter expectations around data retention, auditability, and data residency, areas where a SaaS-only deployment offered limited control.

Solution

Instead of replacing New Relic overnight, the team paused and treated observability as an architectural problem. OpenTelemetry became the default for all new services so instrumentation stayed vendor-neutral. They ran parallel observability pipelines in production, using New Relic alongside OpenTelemetry-native platforms. The evaluation focused on practical concerns: how predictable costs were at scale, how retention could be controlled, how flexible deployment options were, and whether alerting and correlation actually helped engineers reach root cause faster.

Results

Over time, more core services moved toward an infrastructure-aligned observability model with less dependence on platform-specific workflows. Observability costs became easier to reason about, alert fatigue dropped, and governance requirements were simpler to meet. The outcome was not about abandoning New Relic, but about aligning observability with long-term scale, control, and sustainability as the system continued to grow.

Conclusion

Observability is entering a more mature phase, where the focus is shifting from basic visibility to long-term sustainability. As systems scale, cost predictability, portability, and control over telemetry data are becoming first-class requirements rather than secondary concerns.

New Relic helped define modern, SaaS-driven observability and set expectations for what full-stack visibility should look like. Platforms like CubeAPM reflect how the next phase is being shaped, with greater emphasis on OpenTelemetry, infrastructure ownership, and observability that scales predictably with the business.

Book a demo to explore CubeAPM.

_Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve.
_

_Editorial Note: This analysis is based on CubeAPM’s experience working with SaaS and enterprise teams running large-scale, Kubernetes-based production systems and evaluating observability architectures over time.
_

FAQS

1. Is CubeAPM a New Relic alternative?

Yes. CubeAPM is commonly evaluated as an alternative when teams want more control over deployment, data retention, and pricing behavior. While both platforms provide full-stack observability, CubeAPM takes a self-hosted, OpenTelemetry-native approach, whereas New Relic operates as a SaaS platform.

2. Does CubeAPM support OpenTelemetry?

Yes. CubeAPM is OpenTelemetry-native and supports ingesting traces, metrics, and logs directly from OpenTelemetry SDKs and collectors. This makes it easier for teams standardizing on OpenTelemetry to avoid vendor-specific instrumentation.

3. Is CubeAPM self-hosted or SaaS?

CubeAPM is self-hosted or deployed in a customer-controlled VPC. The platform runs inside your own cloud environment, giving teams control over data location, access, and retention, while still being vendor-managed from an operational perspective.

4. How do teams migrate from New Relic?

Most teams migrate incrementally. They keep existing instrumentation running while introducing OpenTelemetry collectors or compatible agents that send data to CubeAPM in parallel. This allows validation of dashboards, traces, and alerts before fully switching traffic.

5. How does observability pricing differ?

Pricing models differ in how costs scale. SaaS platforms typically combine usage-based ingest with user or feature-based charges. CubeAPM uses predictable, ingestion-based pricing with unlimited retention, which simplifies forecasting as telemetry volume grows.

6. Does CubeAPM replace New Relic, or can they run together?

They can run together during evaluation or migration. Some teams use both temporarily to compare data quality and cost behavior. Over time, teams usually consolidate once they are confident CubeAPM meets their observability and operational requirements.

CubeAPM: A Modern Datadog Alternative for Cost, Control, and Scalable Observability

CubeAPM — Wed, 11 Mar 2026 18:51:44 +0000

_Disclaimer: This post was originally published on cubeapm.com
_
Organizations globally are quickly adopting cloud, microservices, and distributed systems. All of this generates huge data volumes, and monitoring it can be difficult for teams using legacy monitoring tools.

Some common issues are related to high cost, data residency, management complexity, and vendor lock-ins. For example, Datadog is a leader in observability, but it might not suit all teams as its pricing is high and it only supports SaaS deployment, with no self-hosting.

To make observability affordable and flexible, teams may start looking for Datadog alternatives, such as CubeAPM. Let’s understand this in detail.

How Datadog Became the Industry Default for Observability

Datadog is an observability platform that teams can use to monitor their applications’ health and performance. It brings together metrics, logs, traces, application performance monitoring (APM), real user monitoring (RUM), and synthetics in a single, SaaS-based product. For many teams, Datadog became the first tool they turned to when production systems started to grow beyond what traditional monitoring could handle.

When teams moved to the cloud and started using microservices, their systems became more complex and visibility was reduced. Teams needed a way to understand what was happening across services without stitching together multiple tools or managing their own monitoring infrastructure. Datadog offered a platform that made it easier for companies to visualize, monitor, and track those systems.

Over time, Datadog helped define what people now think of as full-stack observability. Teams want to be able to correlate their logs, metrics, and traces in one place. Engineers learned to move from a dashboard to the exact problem without switching tools. That set the standard for observability platforms. Datadog is still widely used because it solves real problems. Its 900+ integrations reduce friction during adoption, and many teams value its fast time-to-value.

Limitations of Datadog’s Current Observability Model

Datadog is still a capable and heavily used observability platform. However, it has certain limitations that you may start noticing once your application architecture's scale and observability requirements grow. That said, these challenges are not unique to Datadog. They reflect broader patterns seen across first-generation, SaaS-based observability platforms.

Datadog’s Cost Predictability Breaks Down at Scale

Datadog’s usage-based pricing can feel manageable at smaller scales. Teams pay per host, per gigabyte, or per event, and monthly costs appear predictable. The challenge emerges as systems grow and observability data starts scaling across multiple pricing dimensions. Using the cost model from the pricing sheet, the issue becomes clear.

APM: Datadog charges per host per month for APM. For a midsize business, Datadog’s APM Pro is billed at $35 per host, along with additional charges for profiled hosts ($40 per host) and profiled container hosts ($2 per host). Also, Datadog charges for indexed spans after the first included million. Indexing 500 million spans per month at $1.70 per million spans becomes a significant part of the bill. As traffic grows, span volume increases faster and cost estimation becomes difficult.
Infrastructure monitoring: Datadog charges $15 per host per month for infra monitoring, and container usage is $0.002 per-container-hour (after 5 containers/host). There’s a separate charge for custom metrics ($0.01 per metric after 100/host).
Log management: Logs are billed twice: once for ingestion and again for indexing. In the midsize scenario, ingesting logs per month at $0.10 per GB is only part of the cost. Indexing 3.5 billion log events at $1.70 per million events adds a separate, independent charge.

When you combine these components, the total observability cost grows across hosts, containers, spans, metrics, logs, and events, each with its own pricing unit. Here’s what the cost looks like for medium-sized businesses:

*All pricing comparisons are calculated using standardized Small/Medium/Large team profiles defined in our internal benchmarking sheet, based on fixed log, metrics, trace, and retention assumptions. Actual pricing may vary by usage, region, and plan structure. Please confirm current pricing with each vendor.

The key issue is that cost is distributed across many independent dimensions. A new service, additional trace sampling, higher log indexing, or increased metric cardinality can each increase the bill in ways that are difficult to anticipate upfront.

Platform Coupling and Long-Term Lock-In

Datadog supports modern instrumentation standards like OpenTelemetry. Teams can send OpenTelemetry metrics, traces, and logs using OTLP, either through the Datadog Agent or via the OpenTelemetry Collector with a Datadog exporter.

In day-to-day use, most teams still depend on the Datadog Agent and Datadog-specific workflows. The Agent enriches telemetry with host metadata, applies tagging conventions, and connects directly to dashboards, monitors, and alerts.

Teams may also develop Datdog-specific habits and knowledge. Moving away may need you to set up dashboards, retrain your team, and rewrite alert logic.
Datadog’s OpenTelemetry support is real and widely used, but it functions as a supported ingestion option rather than the platform’s native control plane.
Many advanced features work best when data flows through Datadog’s own collection and enrichment paths.

So, teams may start using a hybrid setup: OpenTelemetry instrumentation with workflows specific to Datadog.

Mostly a SaaS Platform

Datadog is mostly available as a managed SaaS platform, which is easier to adopt. It stores and processes telemetry data in Datadog-managed systems. For many teams, this works well at first. But when priorities change, or observability data directly influences reliability, security, and cost, teams want to know where that data lives and who controls it. If observability data leaves an organization’s infrastructure, meeting data residency and access controls requirements becomes harder.

At present, Datadog’s on-premises initiatives like CloudPrem are limited in scope. It currently focuses on specific use cases, such as self-hosted log management, rather than a fully self-hosted deployment of the entire platform. Core backend services, including metrics, traces, analytics, and the unified UI, are still SaaS-based and hosted by Datadog’s cloud infrastructure.

Limited Retention

Datadog has different retention periods according to the type of telemetry data you collect. If you need higher retention, it requires extra cost or configuration. Based on Datadog’s official documentation, retention periods vary:

Metrics: Stores metrics for up to 15 months.
*Traces *(APM): By default, it stores indexed spans for 15 days. Unindexed traces are available only in short-lived live views before they expire.
Real User Monitoring (RUM): Retains user sessions, actions, and errors for 30 days.

Default retention periods are useful for recent troubleshooting and visibility. It could feel limiting when you need to look further back. Once the retention period expires, you can no longer see patterns in performance regressions, reliability, or usage.

As systems mature, historical observability data becomes more valuable for capacity planning, long-term reliability analysis, and post-incident reviews. When retention is limited, teams must either export and archive data elsewhere or accept gaps in historical visibility.

Noisy Alerts at Scale

Datadog offers a flexible alerting system via monitors. It can trigger alerts based on metrics, logs, traces, and composite conditions. Monitors grow as your infrastructure grows. Even if there’s a small change in traffic patterns or thresholds, it can trigger too many alerts. Many of these may not require you to take action. But alert fatigue can happen due to excessive alerts.

When engineers receive too many low-value alerts, they might miss important signals or have trust issues with the alerting system. This is why you need to constantly tune and control alert noise, although Datadog provides tools for grouping, muting, and managing alerts.

Support Response Times Vary

Based on Datadog’s official support documentation, there are multiple support tiers and response times:

Standard Support: The support is via email and chat. For critical issues, response time is within 2 hours (24x7). For lower priority cases, it’s 12-48 hours (during business hours).
Premier Support: It’s a paid add-on and costs 8% of your monthly Datadog spend ($2,000 minimum). It includes 24x7 support via email, phone, and chat. It offers faster response targets: 30 minutes for critical and 4-12 hrs for lower priority issues.

So, if you’re on the Standard tier, you may face slower responses for non-critical issues outside business hours. But every team desires a faster and more responsive support team, as incidents may occur at any time.

What Does Modern Observability Teams Require Today?

Observability influences cost, reliability, security, and even how teams work. So, modern teams have become more conscious about what they want from an observability platform.

OpenTelemetry support: Teams want vendor-neutral instrumentation. They want to be able to easily adjust pipelines, backends, or architectures without rewriting code. OTel-first tools also make it easier to control sampling, filtering, and routing data before it reaches the backend of the observability tool.

Predictable pricing: Teams want pricing models that they can control. Cost should not spike unexpectedly because of hidden costs, add-ons, or aggressive log indexing and trace volume changes.
MELT correlation: Metrics, events, logs, and traces should work together effortlessly. Engineers want to quickly move from a symptom to a root cause, without jumping between tools or losing context.
Self-hosting: Organizations want control over data egress, retention, and residency. Options, such as self-hosting or BYOC deployments, are helpful here. It’s important for teams that want to meet security or compliance requirements, irrespective of their size.
Lower alert noise: Low-noise alerting, clear signals, and fast root-cause analysis are important. So, the goal is fewer alerts that actually mean something, and workflows that help engineers fix issues quickly instead of adding operational friction.

In our experience working with teams running high-throughput, distributed systems, observability failures rarely happen because a tool is missing features. They happen because cost controls, sampling decisions, or data movement constraints were not considered early. These issues typically surface only after scale, during incidents, or when finance starts questioning observability spend.

How CubeAPM Fits as a Modern Datadog Alternative

CubeAPM eases the difficulties that modern teams face now in terms of data control, flexibility, and cost predictability to teams as their requirements increase. Here is what makes CubeAPM an excellent Datadog alternative:

Native OpenTelemetry: CubeAPM supports OpenTelemetry natively, not just as a supporting feature. It’s the primary way to collect and process telemetry. Teams can standardize on one instrumentation method across services while retaining the freedom to add data pipelines or backends over time.
Predictable pricing: CubeAPM has a predictable, transparent, and affordable pricing of just $0.15/GB. It involves no per-host, per-user, or per-feature pricing. CubeAPM also doesn’t charge separately for data retention, support, or unnecessary add-ons. This way, you can save up to 60% in observability costs.

Smart, context-based sampling: CubeAPM uses smart sampling that preserves important context while reducing unnecessary data volume. It also compresses data by 95%, so teams can save big on data storage costs. Still, they don’t lose visibility into important data useful for debugging and root-cause analysis (RCA).
Unlimited data retention: CubeAPM supports unlimited retention, so teams can keep historical observability data for as long as they need. This is useful for analyzing long-term trends, incidents, and capacity planning.
Zero cloud egress costs: Because CubeAPM can run inside customer-managed environments, teams avoid unexpected cloud egress fees when moving observability data out of their infrastructure. Many enterprises usually pay cloud providers around $0.10/GB or 20-30% of the total observability bill as data out cost.
Faster turnaround times: CubeAPM offers support via Slack or WhatsApp with faster turnaround times (in minutes) involving core developers. For teams operating critical systems, timely support is a must, particularly during incidents.
800+ integrations: CubeAPM integrates with many cloud services, frameworks, and tools. This is helpful for teams and also saves them time on custom integrations or pipelines.
Self-hosted (BYOC/on-prem): CubeAPM supports deployment models where teams can run the platform in their own cloud (BYOD) or on-premise infrastructure. This way, organizations can control data residency for security and compliance purposes.
Vendor-managed: CubeAPM offers self-hosting with vendor-managed services. This eases operations for engineering teams. They can control data without running or maintaining the infrastructure.
Quick deployment: CubeAPM is easy to deploy for all teams, and its support team is available 24x7 to help you. Teams can quickly get started with OpenTelemetry-native pipelines and simpler cost controls. This means you don't have to spend weeks tuning agents or setting ingestion rules.

Taken together, CubeAPM fits teams that want solid observability with better visibility, cost, and control. It helps build a foundation that remains usable as systems and organizations mature.

Migration Strategies for Modern Teams

Moving observability from one platform to another may seem difficult. But CubeAPM is created with modern standards like OpenTelemetry. So, migrating from Datadog to CubeAPM gets easier. It is usually a gradual, controlled process where both systems can run alongside each other until you validate everything and are ready to switch. Here is a clear and practical way around this:

Reuse existing instrumentation where possible: CubeAPM can receive data directly from applications already instrumented with Datadog agents or other common agents. This means you often don’t have to switch instrumentation immediately.
Run in parallel with your current setup: During migration, you send telemetry to both Datadog and CubeAPM at the same time. This lets you compare views and alerts side by side without breaking anything in production.
Onboard services gradually: Try not to switch all applications at once. Migrate one service one by one, starting with a low-risk service. Next, verify dashboards and alerts in CubeAPM. Now, you can onboard more services to reduce risks.
Rebuild important dashboards: Not all dashboards or alerts are important. Rebuild only the important views to have cleaner, more focused dashboards and alerting logic.
Keep learning: Let telemetry flow to both systems. You can explore CubeAPM at your own pace. Over time, usage shifts naturally as you become more comfortable with the new tool.
Future visibility: Migration is about forward visibility. But many think it’s all about exporting historical data. Trying to move years of old data usually adds cost and complexity without much benefit. So, keep older data where it is and let CubeAPM start collecting fresh telemetry.

This is how you can make your migration smooth rather than a risky overhaul.

Case Study: A $65M Bill and What It Tells Us About Datadog’s Observability Costs at Scale

In 2023, Datadog’s earnings call included a remark that grabbed attention in the tech community. The company reported a large upfront bill, which analysts estimated to be around US$65 million for a single customer in one year. Many analysts connected the case to Coinbase, a cryptocurrency platform.

What were the Reasons Behind the Bill?

High growth: In 2021, Coinbase’s usage growth increased around its IPO. It focuses more on reliability and visibility than on optimising the cost.
High data usage and ingestion: Many observability platforms, including Datadog, charge based on hosts, custom metrics, indexed logs, and trace volume. When usage increases, the bill can grow faster.
Costly at scale: Public conversation and threads noted that bills of tens of thousands per month can feel manageable until they become hundreds of thousands or millions. This affects budgeting and forecasting for engineering and finance teams.

What teams learned from it?

Cost predictability matters: Teams want to predict observability cost accurately, and not to be surprised by enormous bills at year-end. In environments where telemetry grows fast, knowing how cost scales can influence architectural decisions.
Instrumentation influences cost: Pushing very high volumes of logs, traces, or high-cardinality metrics without sampling, filtering, or data governance can accelerate cost growth.
Teams consider alternatives when the spend crosses limits: Once costs exceed certain levels (often discussed by engineers when they hit $2–5 million per year), teams start looking for better alternatives.

Conclusion

As your systems and telemetry grow, the observability tool must offer clear insight into what’s happening, why it’s happening, and what it costs, without surprises.

Modern teams need an observability platform with predictable cost, control over data and deployment, and no vendor lock-ins, among others. CubeAPM’s support deep visibility with native OTel support, affordable cost, smart sampling, self-hosting, unlimited data retention, and faster, responsive support.

Book a demo with CubeAPM to experience this in real-time.

_Disclaimer: The information in this article reflects the latest details available at the time of publication and may change as technologies and products evolve.
_

FAQs

What are the best Datadog alternatives for modern observability?

The best Datadog alternatives depend on what you are optimizing for. Teams often look for platforms that offer OpenTelemetry-first instrumentation, predictable pricing, and flexible deployment options such as self-hosted or BYOC. Some alternatives focus on enterprise automation, others on open standards and cost control. The right choice depends on scale, compliance needs, and how much control teams want over telemetry data.

Why do teams look for alternatives to Datadog?

Teams typically explore Datadog alternatives due to cost predictability challenges at scale, concerns around vendor lock-in, and the desire for more control over telemetry pipelines. As environments grow, usage-based pricing and platform coupling can make forecasting and long-term planning harder, especially for organizations with strict governance or data residency requirements.

Are Datadog alternatives compatible with OpenTelemetry?

Most modern Datadog alternatives are built to support OpenTelemetry, either as a first-class design principle or as a core ingestion standard. This allows teams to use vendor-neutral instrumentation and reduces dependency on proprietary SDKs. OpenTelemetry compatibility has become a baseline requirement when evaluating observability platforms.

Can Datadog alternatives support large-scale or enterprise environments?

Yes. Many Datadog alternatives are designed specifically for large-scale, cloud-native, and enterprise environments. These platforms often emphasize unified metrics, logs, and traces correlation, cost governance features, and flexible deployment models to support growth without introducing operational or financial surprises.

How should teams evaluate Datadog alternatives?

Teams should evaluate Datadog alternatives based on pricing transparency, OpenTelemetry support, deployment flexibility, data control, and ease of migration. It is also important to consider how well the platform supports a long-term observability strategy, including cost management, portability, and alignment with evolving cloud architectures.